The PHP project released security updates on 21 October 2026 for CVE-2026-109618 and CVE-2026-109619. The critical vulnerabilities can enable unauthenticated attackers to execute arbitrary code remotely in vulnerable PHP web runtimes. Successful exploitation could allow an attacker to compromise affected web applications and servers, access data available to the PHP process, disrupt application availability, and potentially use the compromised system as a foothold for further attacks.

For SAP solutions, the principal exposure is PHP software deployed alongside, connected to, or hosted within SAP environments. This includes custom PHP applications on SAP Business Technology Platform (BTP), custom PHP runtimes on SAP HANA XS Advanced, and external PHP applications integrated with SAP. Organizations should update affected PHP installations immediately.

Key Points

• Prioritize internet-facing PHP services, followed by internal applications with sensitive data or privileged SAP connections.
• Assess the PHP interpreter actually serving requests, including copies embedded in buildpacks and container images.
• Rebuild and redeploy affected applications with corrected runtimes; changing a buildpack catalog alone does not establish that running applications are patched.
• Review SAP credentials, service bindings, and network access available to affected applications.

Background

CVE-2026-109618 and CVE-2026-109619 affect memory handling within the PHP runtime and can allow invalid or previously released request data to be accessed during processing. The vulnerabilities are present at the runtime layer, meaning potentially affected systems cannot be identified solely by the framework, CMS, or application running on PHP.

Apache mod_php deployments present a particularly significant attack surface because exploitation may occur before application code is executed. PHP-FPM and other PHP web runtimes may also be exposed depending on their configuration. Consequently, application-level authentication does not provide reliable protection against exploitation of the underlying vulnerable PHP runtime.

Impact

Successful exploitation can enable an unauthenticated attacker to execute arbitrary code with the permissions of the affected PHP web worker. While exploitation does not directly provide administrative access to the underlying host or compromise connected SAP systems, it can expose the resources, credentials, and interfaces available to the affected PHP application.

• Where the application is integrated with SAP systems, potential impacts include:
• Exposure of SAP data stored or processed by the application, or accessible through connected databases and APIs.
• Theft of database credentials, OAuth tokens, service-binding secrets, and other integration credentials accessible to the PHP process.
• Unauthorized business operations through OData, REST, SOAP, or RFC interfaces where the compromised application has sufficient permissions.
• Disruption of portals, integrations, and business processes that depend on the affected PHP application.
• Further compromise of connected or reachable systems through stolen credentials or exploitation of additional vulnerabilities.

The extent of the impact depends on the privileges, credentials, and network connectivity available to the compromised application. Containerization and workload isolation can restrict an attacker’s reach, but they do not prevent access to resources that the application is legitimately authorized to use. Consequently, a vulnerable PHP application with privileged access to production SAP systems can represent a significant security and business risk even when the connected SAP systems are fully patched.

Scope

The following matrix is an exposure assessment, not an SAP product-wide affected-version declaration.

PHP applications deployed through Cloud Foundry or SAP HANA XS Advanced buildpacks can introduce exposure to these vulnerabilities within SAP environments. However, the presence of a PHP buildpack alone does not indicate that a system is vulnerable. Exposure depends on whether the deployed application uses an affected PHP runtime.

Remediation

Identify and prioritize affected applications

Inventory production, development, test, disaster recovery, and stopped applications that could be restarted. Record the application owner, externally reachable routes, PHP version and package provenance, web runtime, buildpack or image version, and SAP connections. Check the serving runtime; the host’s command-line PHP installation may be different.

Treat an internet-facing PHP application with privileged SAP access as an urgent remediation priority. Internal applications also require attention when reachable from partner networks, compromised endpoints, or other applications.

Install corrected runtimes and redeploy

The PHP advisories identify the following patched upstream releases for supported production branches:

Use these releases or a later supported release containing the fixes. For distribution packages, verify the vendor’s package revision and backport status instead of relying only on the upstream version number. PHP 8.1 and older no longer receive normal upstream updates; PHP has supplied limited source backports for 7.4, 8.0, and 8.1, but these do not restore lifecycle support. Prefer migration to a supported branch or a vendor-maintained package with confirmed fixes.

Cloud Foundry PHP buildpack v5.1.4 includes the corrected PHP releases. Check whether the appropriate buildpack is available and compatible in the target SAP landscape; upstream availability does not prove SAP rollout. Update runtime pins and custom buildpack dependencies as necessary.

Restage or redeploy Cloud Foundry applications so a new droplet contains the corrected interpreter. A normal restart reuses the existing compiled droplet. Rebuild XS Advanced custom runtimes and Kyma images, then replace all affected instances. Verify the runtime in the deployed artifact and active workers, and prevent rollback to unpatched artifacts.

Reduce exposure while patching

Restrict unnecessary public routes and direct backend access. Where practical, place an independent access control in front of the PHP application, constrain outbound connectivity, and reduce integration privileges. Remove or isolate an exposed service if adequate temporary protection cannot be established quickly.

PHP’s configuration measures are partial safeguards. Disabling session upload progress before request parsing and restarting every worker blocks confirmed session paths, but does not cover all variants. PHP 8.5 also has a separate fatal-error-backtrace safeguard. Apply the complete, current vendor guidance rather than treating one setting or a WAF rule as a fix.

PHP also describes temporarily removing its per-request memory limit while enforcing external resource and request limits. This changes availability risk and is not a blanket recommendation for shared SAP hosts or BTP applications. Assess it with the runtime owner; underlying allocation failures remain possible.

Monitor for compromise

Correlate web, application, container or host, and SAP-side telemetry. Investigate unexpected worker crashes, repeated memory errors, unusual request bursts, new executable files, unexpected child processes, and unfamiliar outbound connections. Review abnormal SAP API/RFC activity and use of technical identities associated with the PHP application. These are investigative leads, not unique signatures for these CVEs.

If compromise is suspected, preserve evidence, isolate the application, and rebuild from a trusted artifact. Revoke or rotate exposed credentials and review downstream activity. Patching alone does not remove persistence or invalidate stolen secrets.

Cybersecurity Extension for SAP

The Cybersecurity Extension for SAP can identify SAP BTP applications running in Cloud Foundry that use vulnerable PHP runtime versions, enabling organizations to quickly determine their exposure to CVE-2026-109618 and CVE-2026-109619 and prioritize affected applications for remediation.

Frequently Asked Questions

Are SAP systems directly affected by PHP2Shell?

CVE-2026-109618 and CVE-2026-109619 affect vulnerable PHP runtimes rather than SAP S/4HANA, ECC, NetWeaver, SAP HANA, SAP GUI, ICM, or SAP Web Dispatcher directly. However, PHP applications deployed alongside or integrated with SAP systems may be exposed and could provide attackers with access to SAP data, credentials, or interfaces available to the compromised application.

Can SAP BTP applications be affected by CVE-2026-109618 and CVE-2026-109619?

Yes. Customer-developed applications running in SAP BTP, Cloud Foundry may be exposed when their deployed application contains an affected PHP runtime. The presence of a PHP buildpack alone does not confirm exposure. Organizations should verify the PHP interpreter contained in the deployed application.

How can organizations identify vulnerable PHP applications in SAP BTP?

The Cybersecurity Extension for SAP can identify SAP BTP applications running in Cloud Foundry that use vulnerable PHP runtime versions. This enables security teams to identify applications potentially exposed to CVE-2026-109618 and CVE-2026-109619 and prioritize them for remediation.

Does updating the Cloud Foundry PHP buildpack automatically patch existing applications?

Not necessarily. Existing applications may continue running artifacts created with an earlier PHP runtime. Affected applications should be rebuilt or restaged using a corrected runtime and the PHP version in the resulting deployed artifact should be verified.

Which PHP versions should organizations upgrade to?

For the supported branches identified in your article, the first corrected upstream releases are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. For vendor-supplied PHP packages, organizations should verify whether the vendor has backported the security fixes rather than relying solely on the upstream PHP version number.

Can application authentication protect against PHP2Shell?

Application authentication should not be considered sufficient protection against these vulnerabilities. Because the vulnerabilities affect the PHP runtime, exploitation may occur below the application layer, depending on the runtime and deployment configuration.

What could happen if an SAP-integrated PHP application is compromised?

An attacker executes code with the privileges available to the affected PHP worker. Depending on the application’s permissions and connectivity, this could expose SAP data, service-binding secrets, OAuth tokens or other credentials, enable misuse of authorized SAP interfaces, disrupt integrations and business processes, or provide a foothold for attacks against other reachable systems.

Does PHP2Shell automatically give an attacker control of SAP?

No. Compromising a PHP application does not automatically compromise an SAP backend or provide SAP administrative privileges. The downstream risk depends on the credentials, permissions, data, interfaces, and network connectivity available to the affected application.

Are containerized PHP applications protected from these vulnerabilities?

Containerization can limit the scope of a compromise, but it does not prevent an attacker from using resources that the compromised application is legitimately authorized to access. PHP applications running in containers should therefore still be assessed for vulnerable runtimes and excessive access to SAP resources.

What should organizations prioritize?

Internet-facing PHP applications should receive immediate attention, particularly applications with access to production SAP systems, sensitive SAP data, technical-user credentials, or privileged APIs. Internal PHP applications should also be assessed where they have sensitive SAP connectivity or can be reached from other potentially compromised systems.

How can the Cybersecurity Extension for SAP help?

The Cybersecurity Extension for SAP provides visibility into SAP BTP Cloud Foundry applications using vulnerable PHP runtime versions, helping organizations identify exposure, locate affected applications, and prioritize remediation for CVE-2026-109618 and CVE-2026-109619.

The post PHP2Shell: Securing PHP Applications in SAP Environments appeared first on Layer Seven Security.

SAP Security Note 3805589 addresses a critical ABAP code injection vulnerability (CVE-2026-89107, CVSS 9.9) affecting the Manage Substitution/Validation Rules functionality in SAP S/4HANA. An authenticated attacker with the required business privileges could submit specially crafted rule definitions that are processed as executable ABAP code, potentially allowing arbitrary code execution and complete compromise of the SAP system. Exploitation could have a severe impact on the confidentiality, integrity, and availability of business data and system services. SAP has introduced additional validation to prevent malicious code from being processed and provides a temporary workaround that disables the affected OData service. SAP recommends implementing the permanent correction instructions or applicable Support Packages as a priority.

SAP Security Note 3798788 addresses a critical missing authorization check vulnerability (CVE-2026-89108, CVSS 9.1) in SAP Manufacturing Integration and Intelligence (MII) Configuration Service. An authenticated attacker with SAP XMII Admin privileges and network access to the affected endpoints could exploit insufficient authorization controls to create an account with elevated privileges on the underlying Java application server, potentially gaining administrative control beyond the MII application itself. Successful exploitation could have a high impact on the confidentiality, integrity, and availability of the affected system. SAP has corrected the vulnerability by strengthening authorization checks and preventing SAP XMII Admin users from creating accounts with the SAP_J2EE_Engine_Admin role. As no workaround is available, SAP recommends implementing the Support Packages and patches referenced in the security note as a priority.

SAP Security Note 3797111 resolves a critical broken access control vulnerability (CVE-2026-89110, CVSS 9.9) affecting SAP NetWeaver Visual Composer. Due to a security configuration that was not enabled by default, a low-privileged attacker could access internal functionality capable of executing operations against a preconfigured remote system. Depending on how the remote connection is configured, exploitation could ultimately provide control over the connected backend system, creating severe risks to its confidentiality, integrity, and availability. SAP has addressed the weakness by changing the default configuration to enforce the relevant security protection. Customers may enable Secure Mode as an interim mitigation, but this is not considered a permanent fix. Given the potential for compromise of connected SAP systems, customers should prioritize deployment of the Support Packages and patches specified in the security note.

SAP Security Note 3626303 resolves a high-severity missing authorization check vulnerability (CVE-2026-89120, CVSS 7.1) in the SAP ABAP Platform caused by a regression introduced through an API change. The flaw allows a low-privileged attacker to use specially crafted requests to bypass restrictions associated with the session manager and gain unintended access to the SAP Easy Access Menu, including scenarios involving single transaction mode and the Fiori Launchpad (FLP). Exploitation could enable unauthorized actions with a high impact on system integrity and a limited impact on confidentiality, although availability is not affected. SAP has remedied the regression by blocking unintended access to the Easy Access Menu and provides the correction through updated SAP Kernel patches.

SAP Security Note 3765424 addresses a high-severity memory corruption vulnerability (CVE-2026-58249) affecting the Internet Communication Manager (ICM) in SAP NetWeaver and SAP Web Dispatcher. A flaw in the HTTP/2 implementation allows an unauthenticated attacker to send specially crafted requests that trigger a memory-handling error and crash the affected process, potentially disrupting access to SAP applications and causing a significant impact on availability, while confidentiality and integrity are not affected. Systems are vulnerable only when HTTP/2 is enabled, which is the default for SAP NetWeaver/ABAP Platform and SAP Web Dispatcher with kernel 7.73 and higher. SAP has corrected the underlying program error through updated kernel and product patches. As an interim safeguard, HTTP/2 can be disabled using the icm/HTTP/support_http2 parameter, although SAP advises applying the relevant corrections as the permanent solution.

SAP Security Note 3800517 addresses a high-priority SQL injection vulnerability (CVE-2026-89113) in SAP Commerce Cloud that could allow an authenticated user to manipulate insufficiently validated input supplied to affected APIs and inject arbitrary SQL commands into database queries. Exploitation could expose sensitive application data and, depending on the underlying database engine, potentially allow data to be modified or deleted, creating a severe impact on confidentiality, integrity, and availability. SAP has eliminated the vulnerability by strengthening the validation and sanitization of affected input parameters and provides the correction in SAP Commerce Cloud 2211-jdk21.18 and later patches. As an interim measure, customers can disable the vulnerable input parameter, although this also removes the associated sorting functionality. Given the potential for unauthorized access and manipulation of application data, affected environments should be upgraded to the corrected SAP Commerce Cloud release as a priority.

The post SAP Security Notes, October 2026 appeared first on Layer Seven Security.

There have been several important developments since the original disclosure of the vulnerability. Security researchers have identified an additional attack route through WebSocket-based RFC and proof-of-concept material has been released in a publicly available exploitation toolkit.

Researchers investigating the EPP flaw demonstrated pre-authentication attack paths through HTTP(S), RFC and WebSocket-based Next Generation RFC (NGRFC). The NGRFC attack path enables attackers to deliver an RFC login envelope to a dialog work process through an HTTPS endpoint, routed through the SAP Web Dispatcher. Restricting traditional RFC ports alone therefore does not address every RFC-related route. Researchers also identified SAP GUI (DIAG) as a reachable protocol path. The public advisory withholds the full exploit construction details.

Another change is the release of SAPMAP on September 16, a public SAP discovery and exploitation toolkit. Security researchers report that OVERPASS proof-of-concept material was present in the repository history for OVERPASS even though the toolkit’s maintainers initially indicated that the related exploits were withheld. The researchers advise defenders to assume that copies of this material are publicly available.

Given the recent developments in the OVERPASS vulnerability, customers should urgently patch affected systems. Inventory ABAP and Java application servers and standalone and embedded Web Dispatchers. Review the Kernel release and patch levels for each system and component against the required levels detailed in SAP Security Note 3747649. Where immediate patching is not possible, review the prerequisites and scope of the temporary HTTP(S) workaround in Note 3756304 and the FAQ in Note 3776034.

In addition, the compensating controls below can be considered while patches are being deployed.

Filter SAP-Passport at the Web Layer

For incoming HTTP(S) traffic routed through SAP Web Dispatcher, administrators can use an HTTP modification action to remove the SAP-Passport header before forwarding the request. This include the following profile parameter setting:

icm/HTTP/mod_0 = PREFIX=/,FILE=$(DIR_GLOBAL)/security/data/icm_filter_rules.txt

The referenced file in the parameter value should contain:

RemoveHeader SAP-Passport

An available icm/HTTP/mod_<xx> slot may be used instead of _0. PREFIX=/ applies the rule across the HTTP URL namespace. HTTP header names are case-insensitive. Further details on Web Dispatcher header-modification mechanisms are available in the SAP Help Portal.

For HTTPS requests, Web Dispatcher must terminate TLS to inspect and remove the header. Verify that clients cannot bypass the Web Dispatcher and reach application-server ICM ports directly. Test the rule against important applications and integrations: removing SAP Extended Passport data can affect distributed tracing, request correlation, diagnostics and performance analysis. Log attempted submissions from untrusted sources before the removal point where possible.

This filter addresses the specified HTTP header route only. It does not remove EPP data carried in SAP GUI, classic RFC or WebSocket RFC protocol structures, and it must not be presented as complete protection against OVERPASS. Where NGRFC is unnecessary, consider blocking WebSocket upgrades to RFC endpoints at the perimeter.

Limit SAP GUI, RFC and Network Access

For SAP GUI (DIAG), restrict access to managed user networks, authorized VPNs, and controlled jump hosts. Configure an SAP GUI access control list on each relevant application server instance and set rdisp/acl_file to its file path to limit which client hosts can connect. Confirm the actual dispatcher listeners, including instance-dependent ports commonly numbered 32<NN> and any alternate routes, and apply network restrictions to all of them. EPP cannot be stripped from DIAG using an HTTP header rule. SNC, where configured and enforced for the relevant clients, can strengthen connection authentication and protection, but it does not replace patching or source restrictions.

For RFC, restrict gateway and related SAP service access to known SAP systems and authorized integration servers. Configure a network-based gateway ACL and set gw/acl_file in each relevant gateway instance profile to permit connections only from approved client IP addresses. Review the actual dispatcher 32<NN>, gateway 33<NN>, and message-server 36<NN> ports as applicable; 34<NN> is commonly associated with a secure gateway configuration and should not be treated as the sole RFC port. Enforce SNC where supported and operationally appropriate, and review trusted RFC destinations and gateway reginfo and secinfo rules. An HTTP RemoveHeader action does not sanitize RFC payloads.

Limit inbound access to SAP Web Dispatcher and ICM HTTP(S) listeners through firewalls, network ACLs, and cloud security groups. For each relevant icm/server_port_<xx> listener, use the ACLFILE option to restrict client IP addresses or ranges, and the HOST option to bind the port to the intended network interface. These options apply to both Web Dispatcher and ICM listeners. Where traffic arrives through a reverse proxy, account for the proxy’s source address in the listener ACL.

Route external traffic through an approved reverse proxy, block direct access to backend application-server ICM listeners, and allow only the required proxy-to-backend addresses and ports. On Internet-facing installations, restrict source IPs where feasible. Use wdisp/permission_table to publish only required URL paths through Web Dispatcher, or icm/HTTP/auth_<xx> where request-level URL and client restrictions are needed. Keep administrative and diagnostic endpoints off the public Internet. Apply the same segmentation review to development, test, and recovery systems that have connections or credentials providing a route into production.

Monitor for Attempted Exploitation Activity

Monitor Web Dispatcher and ICM access, security, error and trace logs centrally, together with SAP process, operating-system and network telemetry. Review repeated malformed requests, unusually large or abnormal EPP-related data, parsing errors, abnormal connection closures, and unexpected ICM or work-process crashes. Baseline ordinary HTTP, SAP GUI and RFC traffic so repeated attempts from one source, probing of multiple SAP systems and traffic from untrusted networks stand out. Note that removing a header before it reaches a backend may also remove backend evidence of the attempted request. Configure logging or detection at the entry point.

Investigate suspected attempts by correlating request timing with SAP traces, host audit events and outbound connections. Look for OS commands run by SAP service accounts such as <SID>adm, access to the SAP secure store, new or altered files, changes to binaries or profiles, and unusual connections to other SAP systems. Block suspect sources where appropriate and isolate an affected host if evidence indicates compromise. Preserve logs and process evidence for the investigation. A crash or malformed header is an indicator to investigate, not proof of successful code execution.

Prioritize Patching

Prioritize the deployment of SAP corrections for systems exposed to untrusted networks, including Internet-facing SAP Web Dispatcher and SAP NetWeaver environments. Once externally accessible systems have been secured, remediate internally accessible production systems, integration platforms, and non-production environments in order of business criticality and exposure. Verify that SAP Kernel, SAP Web Dispatcher, and other affected components have been updated to the corrected versions specified in the latest SAP Security Notes and confirm successful implementation through post-deployment validation.

Until remediation is fully completed across the landscape, implement compensating controls to reduce the attack surface and limit the likelihood of successful exploitation. These controls may include network segmentation, access restrictions, Web Application Firewall (WAF) protections, strengthened monitoring and alerting, and enhanced logging of HTTP(S) requests targeting SAP services. Organizations should maintain heightened monitoring during and after the rollout to detect potential indicators of compromise and verify the effectiveness of remediation activities.

This vulnerability should be treated as a high-priority security issue due to the potential for unauthenticated remote exploitation of affected SAP systems.

Cybersecurity Extension for SAP

The Cybersecurity Extension for SAP identifies affected SAP solutions, validates compensating controls, and detects indicators of attempted exploitation for OVERPASS. The SAP-certified add-on supports the following to help protect SAP systems from the vulnerability:

• Discovery of affected systems and components, including ABAP, Java, SAP Kernel, and standalone or embedded SAP Web Dispatcher installations.
• Identification of vulnerable Kernel and Web Dispatcher versions requiring remediation, prioritizing systems exposed to untrusted networks or interconnected through trusted SAP communications.
• Review of profile parameters associated with compensating controls for OVERPASS, including HTTP header filtering, network access restrictions, protocol restrictions, and other recommended mitigations.
• Assessment of protocol access controls for HTTP(S), DIAG, RFC, and other potentially exposed communication paths, ensuring access is restricted to authorized users, systems, and networks.
• Analysis of secure communication configurations, including Secure Network Communications (SNC) settings for RFC traffic and TLS/SSL configurations for HTTP(S), SAP Web Dispatcher, and ICM services, to identify weak encryption, missing protections, or insecure trust configurations.
• Discovery and mapping of trusted RFC connections across the SAP landscape, including trusted RFC destinations, stored credentials, and cross-system trust relationships that could enable lateral movement or privilege escalation following compromise of a vulnerable system.
• Analysis of security configurations for Gateway ACLs, secinfo, reginfo, SAP GUI ACLs, Web Dispatcher permission tables, ICM listener ACLs, SNC settings, and RFC destination security controls.
• Detection of suspicious or malformed HTTP requests, abnormal SAP-Passport usage, protocol parsing errors, unusual WebSocket activity, and other indicators of attempted OVERPASS exploitation.
• Monitoring of Web Dispatcher, ICM, audit, system, and operating system logs for indicators of attempted exploitation, unauthorized access attempts, and anomalous communications between SAP systems.
• Identification of suspicious operating system activity, including command execution by SAP service accounts, unauthorized file changes, and access to sensitive SAP resources.
• Detection of insecure exposure of SAP services to untrusted networks, including externally accessible application servers, message servers, gateways, RFC services, and Web Dispatcher instances.
• Support for attack path analysis and remediation prioritization by correlating vulnerable systems, trusted RFC relationships, SNC/TLS configurations, and network exposure to identify the highest-risk paths an attacker could use to traverse the SAP landscape.

The Cybersecurity Extension for SAP provides organizations with the capability to identify vulnerable SAP assets, validate mitigation measures, detect indicators of compromise, and accelerate the response to emerging SAP threats such as OVERPASS.

The post SAP OVERPASS Update: New Attack Paths Identified and Public Exploit Toolkit Released appeared first on Layer Seven Security.

SAP issued an urgent security update this week to address the critical vulnerability CVE-2026-44756, commonly known as OVERPASS. The vulnerability has the highest possible severity rating, with a CVSS score of 10.0, and affects a wide range of SAP solutions.

OVERPASS could enable threat actors to disrupt SAP services, access sensitive information, change system data, or assume control of SAP servers through specific requests that trigger a buffer overflow in the SAP Kernel’s processing of Extended Passport (EPP) data.

The vulnerability is addressed by SAP Security Note 3747649. Organizations should immediately identify affected SAP systems, apply the required updates, restrict unnecessary network access, and monitor for signs of attempted exploitation.

Key Points

• OVERPASS is a critical SAP vulnerability with a CVSS score of 10.0.
• Attackers do not require valid SAP accounts to exploit the vulnerability.
• The vulnerability affects the SAP Kernel and therefore  impacts several SAP services and components, including the Internet Communication Manager (ICM), RFC communications, SAP GUI, and SAP Web Dispatcher.
• Internet-facing systems are at the greatest immediate risk, but internal SAP systems may also be exposed.
• Applying SAP Security Note 3747649 is the recommended remediation.
• Network restrictions, monitoring controls, and security hardening can reduce risk while patches are being tested and deployed.
• Organizations should assess the entire SAP landscape, including production, development, test, disaster recovery, and standalone Web Dispatcher systems.

Background

OVERPASS is a security vulnerability in the SAP Kernel, which provides core functions used by many SAP applications and services.

The root cause of the vulnerability is a buffer overflow in the SAP Kernel’s deserializing or processing of Extended Passport (EPP) data. The Extended Passport is a tracing structure attached to SAP communications that tracks requests across connected systems. Attackers can send deliberately malformed requests that trigger a buffer overflow and write operations outside allocated memory areas. This corrupts the memory of SAP processes, enabling attackers to execute arbitrary operating-system commands with administrative privileges.

The requests are processed by the Kernel before the sender is authenticated. Consequently, attackers do not require valid SAP credentials to exploit OVERPASS. Standard protections such as SAP authentication and authorization controls therefore do not prevent successful exploitation.

Impact

Successful exploitation could allow attackers to run operating system commands using the credentials of SAP service accounts.

This could provide threat actors with significant control over SAP servers and applications. Potential consequences include:

• Access to sensitive business information
• Theft of credentials or security configuration data
• Unauthorized changes to SAP data or settings
• Disruption of business-critical SAP applications
• Installation of malicious software or unauthorized tools
• Creation of persistent access to the SAP environment
• Movement from one SAP system to other connected systems
• Compromise of trusted RFC connections and technical interfaces

Scope

Since Extended Passport requests are processed by the SAP Kernel, OVERPASS impacts communication channels and protocols that are served by the Kernel. This includes HTTP/HTTPS through the Internet Communication Manager (ICM) or Web Dispatcher, SAP GUI through the SAP Dispatcher, and Remote Function Call (RFC) communications between systems.

The ICM manages web-based communication for SAP applications. It supports services such as SAP Fiori, WebGUI, web services, APIs, and other HTTP or HTTPS connections.

The Web Dispatcher is often used as a reverse proxy to filter Web-based traffic to SAP solutions. It includes the ICM and SAP Kernel networking code.

SAP application servers accept connections from SAP GUI clients. Systems that are not accessible from the Internet may still be reachable from employee networks, administrative networks, remote-access services, partner connections, or unmanaged devices. A compromised internal device could therefore be used to target a vulnerable SAP system.

RFC connections allow SAP systems and external applications to exchange information and run functions remotely. RFC connections often link production systems with development systems, middleware, reporting tools, third-party applications, and other SAP environments. Such connections increase the potential reach of an attacker after an initial system is compromised.

Although Internet-facing systems require the most urgent attention, internal SAP systems should not be considered safe based only on their network location.

An attacker may reach an internal SAP system through a compromised user device, VPN connection, partner network, administrative workstation, integration server, or another SAP system. Development and test environments can also provide indirect paths into production.

Non-production systems may contain copies of production data, technical credentials, trusted RFC connections, or configuration information that could help an attacker move deeper into the SAP landscape.

Organizations should therefore assess systems based on their software versions, enabled services, connections, and network reachability rather than simply classifying them as external or internal.

Remediation

OVERPASS affects multiple SAP Kernel release lines including older 7.x kernel versions and newer 8.x and 9.x versions. For the Web Dispatcher, it impacts versions 9.16, 9.18, 9.19 and 9.20.

The relevant support package patches for each release should be applied to address the vulnerability. The patches for each release are detailed in note 3747649. The Kernels should be updated to the required patch level specified in the note. The corrections will enable SAP Kernels to validate externally supplied input in Extended Passport requests before processing, preventing memory corruption and therefore exploitation of the vulnerability.  

Where practical, organizations should:

• Restrict access to impacted SAP ports and services using network access control lists
• Remove unnecessary Internet-facing services
• Limit SAP GUI access to managed user networks
• Require administrators to connect through controlled jump hosts
• Separate SAP servers from general employee networks
• Restrict RFC services to known systems and integration points
• Review firewall rules for outdated or overly broad access
• Block direct access to SAP application servers when traffic should pass through an application gateway or another controlled entry point

Security teams should also monitor the SAP application, Web Dispatcher, operating system, and network layers for possible signs of exploitation.

Relevant warning signs may include:

• Unexpected SAP process terminations or restarts
• Unusual requests sent to SAP web services
• Connections from unknown or unapproved IP addresses
• Unexpected operating system commands started by SAP service accounts
• New files or executables appearing on SAP servers
• Unusual RFC calls or connections
• Changes to SAP profiles, services, or configuration files
• Abnormal activity involving privileged technical users
• Unexpected outbound connections from SAP hosts
• Repeated failures involving SAP ICM or Web Dispatcher services

Monitoring should continue after patching to help identify any activity that may have occurred before the correction was applied.

Cybersecurity Extension for SAP

The Cybersecurity Extension for SAP enables organizations to identify, manage, and monitor exposure to OVERPASS through:

• Automatic detection of impacted SAP systems and components
• Identification of vulnerable SAP Kernel and Web Dispatcher versions and patch levels
• Tracking for the implementation status of SAP Security Note 3747649
• Prioritization of vulnerable systems based on business importance and exposure
• Virtual patch guidance when the SAP Kernel patches cannot be applied or implemented swiftly
• Network controls that restrict access to SAP ICM, Web Dispatcher, SAP Dispatcher, and RFC services
• Monitoring controls for suspicious activity involving affected SAP communication channels
• Security hardening for SAP ICM and Web Dispatcher services
• Review of exposed web services, administrative interfaces, access-control rules, and logging settings
• Hardening of RFC connections, RFC destinations, gateway controls, and trusted relationships
• Detection of suspicious operating system command execution at the SAP application and host level
• Monitoring of SAP logs, Web Dispatcher logs, operating system logs, and security events
• Detection of unusual RFC activity and connections from unapproved sources
• Integration of relevant alerts with SIEM platforms such as Sentinel, Splunk, and QRadar
• Centralized investigation, documentation, ownership, and tracking of remediation activities
• Continued monitoring during patch testing, deployment, and post-remediation validation

Conclusion

OVERPASS demonstrates why SAP security must cover more than user accounts and authorizations. A vulnerability in the SAP Kernel can affect several communication channels and may be reached before normal authentication and authorization checks occur.

Organizations should apply a coordinated security approach that includes vulnerability detection, patch management, network restrictions, secure configuration, system monitoring, and threat detection at the application and host level.

It is also important to monitor the complete SAP technology stack. An attack may begin with a request to an SAP service but lead to operating system commands running on the underlying host. Monitoring only SAP activity may not provide sufficient visibility to detect and investigate potential attacks.

Frequently Asked Questions

What is SAP OVERPASS?

OVERPASS is the commonly used name for CVE-2026-44756, a critical vulnerability affecting Extended Passport processing in the SAP Kernel.

How serious is the vulnerability?

CVE-2026-44756 has a CVSS score of 10.0, the highest possible severity rating. Organizations should treat it as an urgent patching and risk-reduction priority.

Does an attacker need an SAP account?

No. The vulnerability may be exploited without a valid SAP username or password.

Are systems safe if they are not connected to the Internet?

Not necessarily. Internal systems may still be reachable through SAP GUI connections, RFC communications, VPN access, partner connections, administrative networks, or compromised internal devices.

Can SAP roles and authorizations prevent an attack?

No. SAP roles and authorizations remain essential security controls, but they may not prevent exploitation because the vulnerable processing can occur before normal authentication and authorization checks.

Can a firewall completely protect the system?

Firewall rules and access control lists can reduce exposure by limiting which sources can reach SAP services. However, they do not correct the vulnerable SAP Kernel code. Applying SAP Security Note 3747649 remains the recommended remediation.

Should development and test systems be patched?

Yes. Non-production systems may contain sensitive data, technical credentials, trusted connections, and information about the production environment. They may also provide an attacker with a path to other systems.

How can organizations detect possible exploitation?

Organizations should monitor SAP and host-level activity for unexpected operating system commands, abnormal SAP process termination, suspicious network requests, unusual RFC communication, unauthorized configuration changes, and unexpected activity by SAP service accounts.

How does the Cybersecurity Extension for SAP help?

The Cybersecurity Extension for SAP automatically identifies vulnerable systems, supports virtual patch and network controls, assesses ICM, Web Dispatcher, and RFC security, detects suspicious operating system commands at the SAP and host levels, and tracks patching remediation across the SAP landscape.

The post SAP OVERPASS Vulnerability: Protecting SAP Systems from CVE-2026-44756 appeared first on Layer Seven Security.

SAP Security Note 3747649 addresses CVE-2026-44756, a critical vulnerability known as OVERPASS, affecting SAP Extended Passport (EPP) Processing within the SAP kernel. Extended Passport is a tracing mechanism used by SAP applications and infrastructure components to track requests across distributed SAP landscapes. The vulnerability arises from insufficient boundary validation during the processing of EPP data, allowing an unauthenticated attacker to send a specially crafted network request that can trigger memory corruption within the SAP kernel. According to SAP and security researchers, successful exploitation may result in arbitrary operating system command execution with SAP administrative privileges, leading to complete compromise of affected SAP systems, including unauthorized access to business data, credentials, active user sessions, system configurations, and SAP executables. OVERPASS is particularly dangerous because the vulnerable code is executed during session establishment, before authentication and authorization controls are evaluated, rendering traditional SAP security controls such as user locks, roles, authorization objects, and logon policies ineffective against the attack.

SAP has assigned the vulnerability the maximum possible severity rating of CVSS 10.0 due to its remote, unauthenticated nature and the potential for full system compromise. The flaw affects a broad range of SAP products that rely on the vulnerable kernel code, including SAP S/4HANA, SAP ERP, SAP Business Suite, SAP NetWeaver AS ABAP, SAP NetWeaver AS Java, SAP BW/4HANA, SAP Enterprise Portal, SAP PI/PO, SAP Solution Manager, and SAP Web Dispatcher. The vulnerability can be reached through multiple communication channels, including HTTP(S), SAP GUI, and RFC connections, significantly increasing the potential attack surface.

SAP has released updated kernel and SAP Web Dispatcher patches that fully remediate the vulnerability and strongly recommends immediate implementation of the corrections provided in Security Note 3747649. Although a temporary workaround is available for certain HTTP(S)-based scenarios using SAP Web Dispatcher, neither SAP nor the reporting researchers consider it a complete mitigation because OVERPASS can also be exploited through SAP GUI and RFC communication paths. Organizations should therefore prioritize the deployment of the corrective patches, restrict access to SAP services from untrusted networks wherever possible, and closely monitor SAP systems for signs of abnormal kernel behavior, process crashes, or suspicious activity. Given its severity, broad impact, and potential for unauthenticated remote code execution, Security Note 3747649 should be treated as an emergency patching requirement for all affected SAP landscapes.

SAP Security Note 3759472 addresses a critical security vulnerability (CVSS 9.8) in the SAP NetWeaver Message Server that could allow an attacker with network access to connect an unauthorized server component to an SAP environment without authentication. Once connected, the attacker could potentially gain unauthorized access to system functions and impact the security and availability of the affected SAP landscape. SAP has corrected the issue by strengthening the verification process used when server components connect to the Message Server. Because the vulnerability can be exploited remotely, requires no authentication, and has no available workaround, SAP recommends that affected customers apply the required kernel patches as soon as possible and treat this note as a high-priority security update.

SAP Security Note 3798315 addresses a critical vulnerability (CVSS 9.4) in certain multi-tenant applications built with the SAP Cloud Application Programming Model (CAP). SAP identified a weakness that could allow an attacker to gain access to sensitive credentials used by affected applications and potentially use those credentials to modify, delete, or disrupt customer data. The issue affects CAP applications that use vulnerable versions of the @sap/cds-mtxs library and have extensibility features enabled. SAP has released updated versions of the affected software components and recommends that customers upgrade immediately and redeploy their applications. For customers running on SAP BTP Cloud Foundry, SAP has already taken additional steps to block the affected application endpoints until they are patched. Due to the potential impact on customer data and application availability, organizations using multitenant CAP applications should review this note promptly and apply the recommended updates as a high priority.

SAP Security Note 3781729 addresses a critical vulnerability (CVSS 9.0) in SAP GUI for Java that could allow a user with limited access to an SAP system to exploit a weakness in how trust settings are enforced. Under certain conditions, the vulnerability could be used to run unauthorized commands on a user’s workstation when interacting with an untrusted SAP system, potentially leading to compromise of the affected device and its data. SAP has released a patch that improves the way SAP GUI for Java validates trusted and untrusted systems before allowing certain actions. Because there is no workaround available, customers using SAP GUI for Java 8.10 should apply the recommended patch as soon as possible. For most organizations, the primary risk is to end-user workstations that connect to untrusted or potentially compromised SAP systems.

The post SAP Security Notes, September 2026 appeared first on Layer Seven Security.

This article examines the challenges of access governance in SAP S/4HANA, the role of solutions such as SAP GRC Access Control in automating risk analysis, and the limitations organizations often face when interpreting and remediating access risks. It also explores how the Cybersecurity Extension for SAP (CES) enhances access risk management through more than 750 authorization-level security checks, detailed risk context, root-cause analysis, remediation guidance, advanced reporting, and exception management. By integrating access governance with broader cybersecurity capabilities such as vulnerability management, threat detection, compliance monitoring, and custom code security, CES enables organizations to proactively reduce risk across both SAP S/4HANA and SAP ECC environments.

Protecting SAP S/4HANA with Effective Access Control and Segregation of Duties

Access control and Segregation of Duties (SoD) are fundamental components of security for SAP since they protect critical business processes, sensitive data, and mission-critical systems from malicious actions and privilege misuse.

Access control ensures that users can only access the SAP transactions, applications, data, and administrative functions required for their roles and responsibilities. SAP systems typically contain highly sensitive information related to finance, payroll, procurement, manufacturing, customer data, and intellectual property. If users are granted excessive permissions, they may be able to view confidential information, perform unauthorized changes, alter configurations, or execute transactions that fall outside their business responsibilities. Effective access control reduces the attack surface of SAP systems and helps enforce the principle of least privilege.

Segregation of Duties (SoD) prevents a single user from having end-to-end control over critical business processes. In SAP environments, security risks often arise when users possess combinations of permissions that enable them to initiate, approve, and conceal transactions. For example, a user who can create a vendor and also approve vendor payments could potentially create fraudulent payments without independent oversight. SoD controls reduce the likelihood of fraud, abuse, and unauthorized activities by ensuring that critical tasks are distributed among multiple users.

Access control and SoD also help limit the impact of compromised accounts. If an attacker gains access to a user account, access controls can restrict what the attacker can do. Likewise, effective SoD prevents a single compromised account from being used to execute an entire fraudulent business process or make significant unauthorized changes without involving additional users or controls.

Internal control frameworks such as COSO and SOX emphasize the importance of control activities that mitigate risks to business operations and financial reporting. SAP access controls support these objectives by enforcing accountability, limiting privileged access, and ensuring that high-risk activities are subject to independent review and approval. When organizations can demonstrate that sensitive SAP transactions, critical authorizations, and privileged roles are monitored and reviewed regularly, they strengthen the overall control environment and improve audit readiness.

The Challenges of Access Risk Governance for SAP S/4HANA

SAP S/4HANA is the digital core of modern enterprises, supporting critical business processes such as financial reporting, procurement, payroll, manufacturing, and customer fulfillment. As a result, access-related weaknesses within S/4HANA can have far-reaching consequences, including fraud, financial misstatements, data breaches, regulatory violations, and operational disruption.

Managing these risks is increasingly difficult due to the scale and complexity of modern SAP environments. Large organizations often maintain thousands of users across multiple SAP systems and clients, each requiring a unique combination of transactions, authorization objects, roles, profiles, and business permissions. Over time, mergers, organizational changes, emergency access assignments, and evolving business requirements can create excessive privileges, Segregation of Duties (SoD) conflicts, and unauthorized access that are difficult to identify through manual reviews.

The challenge is compounded by the complexity of SAP’s authorization model. A single business role may contain hundreds of transactions and thousands of authorization values, making it difficult for security teams and business stakeholders to fully understand the risks associated with a user’s access. Even seemingly minor authorization assignments can introduce significant security and compliance exposures when combined with other privileges.

Because S/4HANA processes highly sensitive financial, operational, and personal data, user access controls are a primary focus of internal audit, external audit, and regulatory compliance reviews. Organizations are expected to demonstrate effective governance over privileged access, SoD conflicts, sensitive transactions, and critical authorizations, often across thousands of users and roles.

Without continuous monitoring and automated risk analysis, organizations may struggle to maintain visibility into their SAP access landscape, increasing the likelihood of undetected risks, audit findings, compliance issues, and security incidents.

Managing Access Risks with Continuous Automated Monitoring

Solutions such as SAP GRC Access Control enable organizations to address these challenges by automating the identification and analysis of critical access risks, excessive privileges, and SoD conflicts. Using predefined and customizable rule sets, organizations can continuously assess user access and detect permission combinations that may enable unauthorized activities or fraud.

SAP GRC Access Control supports access reviews, role governance, and privileged access management, helping organizations enforce least-privilege principles and maintain stronger control over sensitive SAP activities. By providing continuous monitoring, risk reporting, and evidence of access reviews and remediation activities, the solution helps organizations strengthen their security posture while supporting compliance with regulatory requirements and internal control frameworks such as SOX.

While solutions such as SAP GRC Access Control provide valuable capabilities for managing access risks and SoD conflicts, organizations often encounter challenges when attempting to operationalize and scale access governance programs. One common limitation is that access risk analysis can generate large volumes of findings without providing sufficient context to understand the underlying root causes. Security and compliance teams may be able to identify that a user has a critical authorization or SoD conflict, but determining exactly why the risk exists, which role assignments created the exposure, how the risk impacts specific business processes, and what remediation actions should be taken frequently requires additional manual analysis.

Another challenge is that traditional access governance solutions often focus primarily on detecting violations rather than helping organizations effectively manage and remediate them. Access reviews, risk analysis results, role data, and SoD findings are frequently presented through technical reports that assume significant SAP security expertise. As a result, business users, auditors, and managers may struggle to interpret findings, understand their business impact, or prioritize remediation efforts. Organizations are therefore often left with the difficult task of translating technical authorization data into meaningful risk insights that support decision-making and compliance objectives.

The complexity of SAP S/4HANA environments further amplifies these challenges. Modern SAP landscapes include Fiori applications, business roles, OData services, backend authorization objects, and cloud integrations that introduce additional layers of access governance complexity. Security teams require deeper visibility into access risks, better correlation across access layers, and more actionable reporting that explains not only what risks exist but also how those risks can be efficiently remediated to reduce security and compliance exposure.

As organizations mature their access governance programs, there is an increasing demand for solutions that provide richer business context, improved reporting, automated remediation guidance, and greater visibility into the root causes of critical access and SoD risks. These capabilities help transform access governance from a compliance-driven activity into a strategic security function that enables organizations to proactively reduce risk across their SAP S/4HANA environments.

Advancing Access Risk Management with the Cybersecurity Extension for SAP

The Cybersecurity Extension for SAP (CES) enables organizations to move beyond simply identifying critical access and Segregation of Duties conflicts in SAP S/4HANA. CES performs more than 750 authorization-level access risk checks across business processes such as Finance, Procurement, Materials Management, Order to Cash, Human Resources, Payroll, Manufacturing, and Supply Chain. Each finding includes a detailed risk statement explaining the nature of the exposure and its potential business impact, giving security teams, administrators, business owners, and auditors the context required to understand why the issue matters.

CES also provides greater insight into the root causes of access risks by identifying the affected SAP users, clients, user groups, roles, profiles, authorizations, and permission combinations associated with each finding. This allows organizations to determine not only that a critical access or SoD issue exists, but also which access assignments created the exposure. Actionable remediation guidance helps teams translate technical findings into corrective measures, reducing the manual investigation traditionally required to interpret authorization data and determine an appropriate response. Advanced dashboards, risk analytics, trend reporting, executive summaries, and detailed technical reports provide visibility into access risks and remediation status across the SAP landscape.

CES also includes flexible exclusion and exception-management capabilities that allow organizations to fine-tune access risk analysis based on business requirements. Authorized users, roles, and access scenarios can be excluded or whitelisted either broadly or specifically, while maintaining visibility and auditability. This helps reduce unnecessary noise without removing legitimate exceptions from governance oversight, enabling security teams to focus on unresolved and actionable risks.

Most importantly, CES takes a broader approach to securing S/4HANA than SAP GRC Access Control.  Access risk management is one component of the security coverage provided by CES. In addition to critical access and SoD analysis, the solution provides capabilities for vulnerability management, SAP security note and patch management, custom code security, threat detection and response, anomaly detection, incident response, and compliance management. This integrated approach allows organizations to manage access risks alongside configuration weaknesses, unpatched vulnerabilities, insecure custom code, suspicious activity, and compliance gaps. CES unifies access governance with comprehensive cybersecurity capabilities as part of an integrated approach to security for S/4HANA.

Although this article focuses on managing critical access and Segregation of Duties risks within SAP S/4HANA, the Cybersecurity Extension for SAP also provides comprehensive coverage for SAP ECC environments. Organizations that continue to operate ECC systems face many of the same access governance challenges, including excessive privileges, critical authorization risks, privileged access concerns, and SoD conflicts across business processes. CES applies the same authorization-level analysis, risk detection, reporting, root-cause analysis, and remediation guidance capabilities to SAP ECC, enabling organizations to maintain consistent access governance and security oversight across both ECC and S/4HANA landscapes. This allows organizations to strengthen security, support compliance initiatives, and reduce access-related risks regardless of where they are in their SAP transformation journey.

Frequently Asked Questions (FAQ)

What is access control in SAP S/4HANA?

Access control is the process of ensuring that users can only access the SAP transactions, applications, data, services, and administrative functions required for their job responsibilities. Effective access control enforces the principle of least privilege, reduces the attack surface of SAP systems, and helps prevent unauthorized actions that could impact business operations, data confidentiality, or system integrity.

What is Segregation of Duties (SoD)?

Segregation of Duties (SoD) is a security and internal control principle that prevents a single user from having excessive control over critical business processes. SoD conflicts occur when a user possesses combinations of permissions that allow them to initiate, approve, and conceal transactions, creating opportunities for fraud, errors, or abuse.

Why are access control and SoD important for SAP S/4HANA?

SAP S/4HANA supports critical business functions such as finance, procurement, payroll, manufacturing, and supply chain operations. Weak access controls or unresolved SoD conflicts can lead to unauthorized transactions, financial misstatements, data breaches, compliance violations, and operational disruption. Effective access governance helps organizations reduce these risks while supporting audit and regulatory requirements.

What challenges do organizations face when managing SAP access risks?

Organizations often manage thousands of users, roles, authorization objects, and business permissions across multiple SAP systems. The complexity of SAP’s authorization model makes it difficult to identify excessive privileges, critical authorizations, and SoD conflicts through manual reviews. Organizational changes, mergers, emergency access assignments, and evolving business requirements further increase the complexity of access governance.

How does SAP GRC Access Control help manage access risks?

SAP GRC Access Control automates the identification and analysis of critical access risks and SoD conflicts. The solution provides risk analysis, role governance, access reviews, and privileged access management capabilities that help organizations continuously monitor user access and support compliance initiatives such as SOX.

What are some limitations of traditional access governance solutions?

Traditional access governance solutions often identify risks without providing sufficient context regarding their root causes, business impact, or remediation options. Organizations may receive large numbers of technical findings that require significant manual analysis to determine which users, roles, authorizations, or access assignments created the exposure and how the risks should be addressed.

What is the Cybersecurity Extension for SAP (CES)?

The Cybersecurity Extension for SAP (CES) is an integrated SAP cybersecurity platform that helps organizations identify, analyze, and manage access risks, critical authorizations, and SoD conflicts. CES provides detailed risk context, root-cause analysis, remediation guidance, dashboards, analytics, and executive reporting to help organizations understand and reduce access-related risks.

How does CES improve access risk analysis?

CES performs more than 750 authorization-level access risk checks across key business processes. Unlike traditional access governance solutions, CES provides detailed risk explanations, identifies the specific users, roles, profiles, and authorizations responsible for findings, and delivers actionable remediation guidance that helps organizations resolve risks more efficiently.

How does CES support exception and exclusion management?

CES includes flexible whitelisting and exception-management capabilities that allow organizations to exclude authorized users, roles, or business scenarios from analysis while preserving visibility and auditability. This helps reduce unnecessary noise and enables security teams to focus on unresolved and actionable risks.

Does CES provide capabilities beyond access governance?

Yes. Access risk management is only one component of the broader coverage provided by CES. The solution also includes vulnerability management, SAP Security Note and patch management, custom code security, threat detection and response, anomaly detection, incident response, compliance management, and cybersecurity reporting. This allows organizations to manage access-related risks as part of a comprehensive cybersecurity strategy.

Does CES support SAP ECC as well as SAP S/4HANA?

Yes. Although this article focuses on SAP S/4HANA, CES also provides comprehensive access risk analysis and SoD monitoring for SAP ECC environments. Organizations can use CES to identify critical authorizations, excessive privileges, privileged access risks, and SoD conflicts across both ECC and S/4HANA systems, enabling a consistent approach to access governance and compliance across hybrid SAP landscapes.

How does effective access governance improve audit readiness?

Continuous monitoring of critical authorizations, privileged access, and SoD conflicts helps organizations demonstrate the effectiveness of internal controls during audits. Detailed reporting, risk analysis, remediation tracking, and documented review activities provide evidence that access-related risks are being actively managed in support of frameworks such as SOX and COSO.

The post Managing Critical Access and Segregation of Duties Risks in SAP S/4HANA appeared first on Layer Seven Security.

SAP Security Note 3714806 patches a critical memory corruption vulnerability in SAP NetWeaver Application Server ABAP and ABAP Platform, tracked as CVE-2026-34265 with a CVSS score of 9.8. An unauthenticated remote attacker can exploit improper boundary validation in DIAG protocol parsing to corrupt memory, potentially disclose sensitive information, affect system integrity, or cause system crashes. SAP has corrected the issue by introducing proper boundary checks in the affected kernel components. Customers should install the applicable kernel patch level or latest compatible SP Stack Kernel.

SAP Security Note 765948 addresses a critical code injection vulnerability in SAP Manufacturing Integration and Intelligence (MII), tracked as CVE-2026-44772 with a CVSS score of 9.9. A low-privileged remote attacker can exploit an SSRF flaw in XSL transformations to make the application process attacker-controlled external content, potentially enabling arbitrary command execution on the underlying host. Successful exploitation could severely impact confidentiality, integrity, and availability. SAP has introduced new Secure Transformer and Allowed Hosts system properties to restrict XSL sources. Customers should apply the referenced patches and configure these properties as instructed.

SAP Security Note 3758900 fixes a critical code injection vulnerability in SAP Manufacturing Integration and Intelligence (MII), tracked as CVE-2026-44758 with a CVSS score of 9.1. A highly privileged attacker with access to the XMII_IllumXSLTServlet action can submit crafted input to the vulnerable XSL transformation servlet and potentially execute arbitrary operating system commands. Successful exploitation could severely impact confidentiality, integrity, and availability. The note removes the vulnerable IllumXSLTServlet component and recommends using the XSL Transformation action block instead. Customers should apply the referenced patches and remove XMII_IllumXSLTServlet access from all roles as a temporary mitigation.

SAP Security Note 3771065 relates to a critical improper authorization vulnerability in SAP Commerce Cloud Data Hub Adapter, tracked as CVE-2026-58231 with a maximum CVSS score of 10.0. An unauthenticated attacker can abuse a default authentication client and insufficient authorization controls to submit malicious input, potentially achieving remote code execution and compromising internal components. Successful exploitation could severely impact confidentiality, integrity, and availability. The issue affects systems with the Data Hub Adapter extension enabled. Customers should upgrade to SAP Commerce Cloud 2211.55, 2211-jdk21.17, or later releases. As a temporary mitigation, access to /datahubadapter/import/** should be restricted to trusted DataHub server IP addresses using an IP Filter Set.

SAP Security Note 3772411 patches a high-severity privilege escalation vulnerability in SAP ABAP Developer Tools, tracked as CVE-2026-58243 with a CVSS score of 8.8. A low-privileged attacker can exploit insufficient authorization checks in the SQL Console to perform unauthorized database operations against SAP NetWeaver AS ABAP, potentially reading sensitive data, modifying application data, or disrupting access for legitimate users. The issue stems from the improper use of host expressions in SQL statements. SAP has restricted this functionality and recommends applying the referenced patches. As a temporary mitigation, customers should remove S_TABU_NAM and S_TABU_DIS from users that do not require the authorizations.

SAP Security Note 3773304 fixes a high-severity remote code execution vulnerability in the Enhanced Change and Transport System (CTS+) Attach Tool (ctsattach), tracked as CVE-2026-58233 with a CVSS score of 7.6. An authenticated attacker can provide a malicious archive file that exploits insecure deserialization in a third-party library when processed by a victim, potentially enabling remote code execution, disclosure of sensitive information, and control of affected system processes. All versions of ctsattach are vulnerable and no fixed version is available. SAP has discontinued the tool and instructs customers to immediately stop using it and remove all installed copies, using alternative transport methods documented by SAP.

The post SAP Security Notes, August 2026 appeared first on Layer Seven Security.

Operating-system security is a critical component of protecting SAP S/4HANA and SAP HANA environments, particularly where workloads run on SUSE Linux Enterprise Server. Weak permissions, unnecessary services, insecure remote access, missing patches, exposed ports, and inadequate logging can allow attackers to bypass application-level controls and compromise critical SAP resources. These weaknesses can also increase exposure to ransomware, which may exploit operating-system vulnerabilities, gain elevated privileges, modify services, access network shares, and encrypt or delete business-critical files. Organizations should therefore apply a layered security strategy that protects sensitive SAP profiles, secure stores, certificates, HANA configuration files, administrative accounts, system binaries, and audit records at the OS level.

This includes enforcing least privilege, restricting network access through allowlist-based firewall rules, disabling obsolete services, strengthening SSH and password controls, enabling AppArmor and file-integrity monitoring, and maintaining a supported and fully patched operating system. The Linux Audit Framework provides an additional layer of visibility by recording privileged activity, configuration changes, failed access attempts, account administration, kernel events, and modifications to security-sensitive files.

The Cybersecurity Extension for SAP supports these requirements through integrated SLES security capabilities, including sensitive-file permission checks, vulnerable port and service detection, audit-log monitoring, actionable alerts, and SIEM integration. Its monitoring of external connections, malicious program execution, root access, code injection, systemd changes, file-system mounts, and unauthorized file activity can help identify ransomware attack patterns at an early stage. By extending security monitoring across the SAP application, HANA database, and SLES operating-system layers, organizations can reduce the attack surface, strengthen ransomware protection, improve compliance, and enhance the resilience of business-critical SAP systems.

Why Operating-System Security Matters for SAP

Operating-system security is a critical but often overlooked component of SAP cybersecurity. SAP applications depend on the underlying operating system to manage processes, files, user accounts, services, network connections, and access to sensitive business data. Weaknesses at the OS layer can undermine even well-secured SAP applications and databases.

Ransomware, for example, can exploit OS vulnerabilities to compromise SAP solutions and circumvent application-level security controls. Protecting SAP systems therefore requires more than application-level controls. It requires hardening and monitoring of the underlying operating-system layer.

The Role of SLES in Modern SAP Environments

Linux is the leading operating system for modern SAP environments, particularly for SAP HANA and SAP S/4HANA deployments. Among supported Linux distributions, SUSE Linux Enterprise Server is the most widely used, reflecting its longstanding co-engineering partnership with SAP, performance optimization, high-availability capabilities, and enterprise-level support.

For organizations running SAP workloads on SLES, operating-system security should include managing system services, removing unnecessary packages, restricting network exposure, and enforcing strong authentication and least-privilege access for administrative accounts. Timely vulnerability and patch management is equally important, including updates for the kernel, libraries, and third-party components that could expose SAP systems to attack.

Organizations should also protect critical SAP files and directories, monitor changes to configurations and permissions, and collect security-relevant logs for analysis.

Protecting Security-Sensitive SAP and HANA Files

Critical security-sensitive files for SAP S/4HANA and SAP HANA include SAP system profiles, cryptographic key and certificate files, secure storage files, HANA configuration files, SAP and HANA executables, and Linux security configuration files.

These files control authentication, encryption, network communications, service startup, privileged access, and database behaviour, making them attractive targets for attackers seeking to weaken controls or establish persistence.

Organizations should therefore restrict access, enforce appropriate ownership and permissions, monitor unauthorized changes, and maintain reliable backups. Particular attention should be given to SAP profiles, PSE files, ABAP and HANA secure stores, HANA INI files, service-account SSH keys, sudo configurations, and startup definitions. Monitoring should also account for legitimate changes introduced by patching, maintenance, and certificate renewal.

Restricting Network Ports and Services

Apply a Default-Deny Network Model

Network services on SUSE Linux Enterprise Server should follow a default-deny model. Only ports required for documented SAP communications and approved administrative functions should be open, and access should be limited to specific source systems and network zones.

SAP maintains a centralized reference of required TCP/IP ports used by its products and recommends using this information to plan and configure network infrastructure. Because SAP ports frequently incorporate the instance number, firewall rules should be defined for the actual instances deployed rather than opening broad port ranges.

Allow Only Required SAP Communications

For an SAP S/4HANA application server, required ports may include the dispatcher on 32<NN>, the gateway on 33<NN>, the message server on 36<NN>, and HTTP or HTTPS ports configured for the Internet Communication Manager.

SAP HANA uses additional instance-dependent ports for SQL access, internal communication, system replication, administration, and monitoring. These ports should only be reachable by authorized application servers, administrators, monitoring tools, and other approved components.

Internet-facing access should normally be routed through controlled entry points such as reverse proxies, SAP Web Dispatcher, application gateways, or dedicated load balancers rather than exposing SAP application or database services directly.

Disable Unnecessary and Legacy Services

Organizations should review each SLES host for unnecessary or prohibited services. Legacy and insecure services—including Telnet, FTP, TFTP, rlogin, rsh, rexec, finger, echo, chargen, daytime, and unencrypted mail or file-transfer protocols—should generally be disabled.

Ports associated with unrelated databases, remote-access tools, peer-to-peer software, development services, container interfaces, message brokers, and commonly abused backdoors should also remain closed unless there is a documented business requirement.

Validate Legitimate Exceptions

A blacklist should not be applied without considering the services required for the relevant SAP solutions. Several ports are often required for legitimate infrastructure or SAP operations.

Port 22 may be required for restricted SSH administration, 53 for DNS, 123 for time synchronization, 389 for LDAP, and 80 or 443 for approved web communications. Similarly, ports 50013 and 50014 can be associated with SAP HANA services, depending on the HANA instance number and deployment model.

These ports should not be closed solely because they appear on a generic blacklist. Administrators should validate each listening process, confirm that it is required, restrict it to trusted interfaces and source addresses, and use encrypted alternatives wherever possible.

Enforce Firewall Governance

Firewall controls should be enforced both at the network layer and through the SLES host firewall. Administrators should regularly compare listening ports against the approved SAP architecture, investigate unexpected services, and remove or disable software that is not required.

Changes should be documented and monitored so that unauthorized services, accidental exposure, or ports opened temporarily for maintenance do not remain available. This allowlist-based approach reduces the attack surface while preserving the communications required for secure and reliable SAP operations.

General SLES Security Hardening for SAP

Use a Supported and Fully Patched Operating System

Organizations should use a vendor-supported SLES release certified for the deployed SAP products, install security patches promptly, verify package signatures through zypper, and remove obsolete packages, development tools, and services that are not required for SAP operations.

Operating-system changes should be tested before production deployment because SAP HANA supports additional hardening only where the changes do not conflict with SAP requirements or known compatibility restrictions.

Secure Remote Administration

Remote administration is a particularly important area. Unencrypted and legacy services such as Telnet should be removed, while SSH access should be restricted to authorized administrators and trusted management networks.

Recommended controls include:

• Prohibiting empty passwords and direct root login
• Disabling host-based authentication and unnecessary X11 forwarding
• Enforcing strict file-permission checks
• Limiting permitted users and groups
• Configuring session timeouts
• Using approved encryption ciphers and message-authentication algorithms

SSH private keys and configuration files should have restrictive ownership and permissions. Administrative activity should use named accounts with controlled privilege escalation rather than shared root access. OpenSSH encrypts authentication and session traffic, helping protect administrative connections against interception and hijacking.

Strengthen User and Privileged Access Management

User and privilege management should follow least-privilege principles. Every administrator should have a unique account, only the root account should use UID 0, and system or service accounts that do not require interactive access should have login shells disabled.

Password controls should establish appropriate minimum length and complexity, prevent excessive reuse, use secure hashing, enforce minimum and maximum lifetimes where required, and lock or delay accounts following repeated failed logon attempts.

Sudo access should be limited to approved users, require authentication and periodic re-authentication, and avoid unrestricted NOPASSWD rules. Multifactor authentication or smart-card authentication can provide additional protection for high-risk administrative access.

Protect Files and File Systems

File-system protections should prevent unauthorized modification of operating-system and SAP resources. Organizations should verify the ownership and permissions of system binaries, libraries, log files, home directories, SSH keys, password files, SAP profiles, HANA configuration files, and secure stores.

Default umask settings should prevent newly created files from being broadly accessible. Shared directories that must be world-writable should have the sticky bit enabled to prevent users from deleting or renaming files owned by others. Unnecessary world-write permissions should be removed.

Where compatible with SAP requirements, nosuid and noexec options should be considered for removable media and remote file systems. Separate partitions for /var, /var/log/audit, and other high-growth areas can also reduce the risk that logging or temporary-file activity consumes space required by critical SAP services.

Harden Network and Kernel Settings

SLES network settings should be hardened by disabling IP forwarding unless explicitly required, rejecting source-routed packets and unnecessary ICMP redirects, enabling TCP SYN-cookie protection, and disabling unused wireless interfaces.

The host firewall should be enabled and configured using an allowlist of required SAP and infrastructure communications. On SLES 15, firewalld is the default host firewall and replaces the older SuSEfirewall2 framework.

Enable AppArmor, Boot Protection, and Secure Cryptography

AppArmor should be installed, enabled, and configured to restrict the files, capabilities, and system resources available to supported processes.

Boot security should also be considered by protecting GRUB or UEFI configuration against unauthorized modification and restricting access to the system console.

Where regulatory requirements apply, organizations can evaluate SLES FIPS mode and approved cryptographic algorithms. These settings should be tested carefully because enabling FIPS restrictions can affect interoperability with older SAP components, integrations, or administrative tools.

Enable Auditing and File-Integrity Monitoring

Comprehensive auditing and file-integrity monitoring are essential for detecting changes that could affect SAP security.

The Linux Audit Framework should record:

• Modifications to user and group databases
• Execution of privileged commands
• Changes to access permissions
• Kernel-module activity
• Unsuccessful attempts to access protected files
• Alterations to logon records

Audit logs should have restrictive permissions, sufficient dedicated storage, defined actions for low-space and disk-full conditions, and preferably be forwarded to a protected remote logging or SIEM platform.

AIDE or an equivalent file-integrity monitoring capability should periodically verify critical operating-system, SAP, and HANA files, including ownership, permissions, access control lists, extended attributes, and cryptographic checksums.

High-priority targets include audit tools, SSH configuration, system binaries, startup definitions, SAP profiles, HANA INI files, PSE certificates, and secure-store files. Alerts should distinguish unauthorized changes from approved maintenance, patching, kernel upgrades, and certificate renewals.

Support Operational Resilience

Operational resilience controls should complement preventive hardening. Accurate time synchronization is necessary to correlate SAP, HANA, operating-system, and SIEM events, so the approved NTP or chrony service should be configured with trusted time sources and suitable polling intervals.

Root system mail should be forwarded to a monitored administrative account, and kdump should be configured where required to preserve diagnostic information following kernel failures.

Systems should also be rebooted when necessary to activate security-relevant kernel or library updates. Together, these measures establish a hardened, monitored, and supportable SLES platform for business-critical SAP workloads.

Enabling Audit Logging on SLES

The Linux Audit Framework provides detailed records of security-relevant activity on SUSE Linux Enterprise Server, including administrative actions, authentication events, file access, configuration changes, and the execution of privileged commands.

For SAP environments, audit logging can help identify unauthorized activity affecting the operating system, SAP service accounts, application files, HANA configuration, and other sensitive resources. Audit records are normally written to /var/log/audit/audit.log and can be forwarded to a SIEM or centralized logging platform for monitoring and correlation.

Step 1: Check the Audit Packages

Confirm that the audit and audit-libs packages are installed:

sudo rpm -q audit audit-libs

Alternatively, use Zypper to review the installed package status:

sudo zypper search –installed-only audit audit-libs

If either package is missing, install it using:

sudo zypper install audit audit-libs

The audit package provides the audit daemon and administration utilities, while audit-libs provides the libraries required by the Linux Audit Framework.

Step 2: Start the auditd Service

Start the audit daemon so that the system can begin processing and recording audit events:

sudo systemctl start auditd

Verify that the service is running successfully:

sudo systemctl status auditd

The service should report an active (running) state. Any startup errors should be investigated before audit rules are deployed.

Step 3: Enable auditd at Boot

Configure the audit daemon to start automatically whenever the SLES server is restarted:

sudo systemctl enable auditd

Confirm the boot-time configuration with:

sudo systemctl is-enabled auditd

The expected result is:

enabled

Enabling the service at boot helps ensure that security events are recorded consistently following planned maintenance, operating-system patching, or an unexpected system restart.

Step 4: Restart the auditd Service

After modifying /etc/audit/auditd.conf, adding rules under /etc/audit/rules.d/, or making other audit-related configuration changes, restart the service:

sudo systemctl restart auditd

Verify the service status after the restart:

sudo systemctl status auditd

Restarting auditd ensures that the updated configuration and audit rules are loaded.

Configure SAP-Relevant Audit Rules

Once the service is operational, organizations should define audit rules that reflect the risks within their SAP environment.

These can include monitoring changes to:

• SAP profiles
• HANA INI files
• Secure stores
• User and group databases
• SSH configuration
• Sudo policies
• Privileged executables
• Kernel modules
• File permissions
• Audit configuration

Audit storage limits, log rotation, disk-full actions, remote forwarding, and alerting should also be configured to prevent audit records from being lost or altered.

How the Cybersecurity Extension for SAP Supports SLES Security

The Cybersecurity Extension for SAP provides integrated SLES hardening and monitoring capabilities that help organizations identify vulnerabilities, detect suspicious events, and protect critical SAP resources through a unified, cross-stack security platform.

Monitoring Sensitive Files and Directories

The SAP-certified solution reviews permissions and ownership for sensitive SAP and operating-system files and directories, including:

• SAP system profiles
• Secure Storage in the File System
• Gateway and message server resources
• HANA security directories
• /etc/ssh
• /etc/sudoers
• /etc/sudoers.d
• /etc/passwd
• /etc/shadow

This helps identify excessive permissions, incorrect ownership, and unauthorized access paths that could expose credentials, certificates, security configurations, or privileged SAP components.

Detecting Exposed Ports and Services

The Cybersecurity Extension for SAP detects open ports and services that may unnecessarily increase the attack surface of SLES hosts.

Its coverage includes:

• Legacy protocols
• Remote-access services
• Unrelated database ports
• File-sharing services
• Administrative interfaces
• Peer-to-peer services
• Container interfaces
• Message brokers
• Ports commonly associated with malware or backdoors

Findings can include exposed Telnet, FTP, RPC, SMB, VNC, database, container, message-broker, web-management, and other network services.

Because some ports—including SSH, DNS, NTP, LDAP, HTTPS, and certain SAP HANA ports—may be required for legitimate operations, results should be evaluated against the approved SAP architecture. This enables organizations to distinguish necessary connectivity from unauthorized or unnecessary exposure and apply a controlled, allowlist-based firewall policy.

Assessing SLES Hardening Controls

Comprehensive SLES hardening checks help organizations assess security across SSH, authentication, account management, privileged access, file permissions, networking, logging, boot security, cryptography, and endpoint protection.

The Cybersecurity Extension for SAP can identify weaknesses such as:

• Direct SSH root access
• Empty passwords
• Unapproved ciphers and MAC algorithms
• Unrestricted X11 forwarding
• Insecure session settings
• Missing warning banners
• Insufficient password controls
• Excessive sudo privileges
• Inactive AppArmor protection
• Unsupported operating-system versions
• Missing software patches
• Disabled host firewalls
• Insecure remote mount options
• World-writable directories
• Weak kernel security settings
• Inadequate audit storage
• Missing AIDE deployment
• Disabled package-signature validation
• Unnecessary services such as Telnet

Assessing the Linux Audit Framework

Hardening coverage extends to the Linux Audit Framework. The solution can assess whether the required audit packages and plugins are installed, whether auditd is enabled and running, and whether sufficient audit rules are configured.

Relevant areas include:

• Privileged commands
• User and group changes
• Unsuccessful file access
• Kernel modules
• Discretionary access controls
• System administration activity
• Logon records
• Removable media

The solution can also identify weaknesses in audit-log storage, disk-space actions, remote forwarding, file permissions, and failure handling that could result in important evidence being lost during an attack.

Monitoring Security-Relevant SLES Events

Once SLES audit logging is enabled, the Cybersecurity Extension for SAP can monitor the audit trail for security-relevant operating-system events and generate actionable alerts.

These include changes to:

• Audit configuration
• SSH
• PAM
• Sudo
• Login settings
• Systemd
• Crontab
• Kernel configuration
• Network configuration
• SAP profiles

The solution can also detect:

• Failed file access
• Unauthorized permission changes
• File creation or modification attempts
• File-system mounts
• Software installation
• Kernel-module activity
• Privilege abuse
• Root command execution
• User and group administration
• Password changes
• Account locking and unlocking
• Suspicious scripts
• Malicious programs
• Code-injection indicators
• Replay attacks
• Changes to system-level security objects

Integrating SLES Alerts with SIEM Platforms

Alerts can be forwarded to SIEM platforms for correlation and investigation by the security operations centre.

This allows SLES activity to be analysed alongside:

• SAP application events
• SAP HANA database activity
• Authentication events
• Network events
• Endpoint telemetry
• Infrastructure activity

For example, a failed SAP host login can be correlated with SSH configuration changes, sudo activity, access to a secure-store directory, and subsequent execution of a privileged command.

This cross-layer visibility helps analysts identify attack sequences that may not be apparent when operating-system and SAP logs are reviewed separately.

Detecting and Responding to Ransomware

The Cybersecurity Extension for SAP can help detect ransomware activity on SLES by monitoring operating-system events associated with initial access, malware execution, privilege escalation, persistence, and file manipulation.

Relevant alerts include:

• Unexpected external connections
• Failed file access
• Unsuccessful file creation or modification
• Unexpected file-system mounts
• Malicious program execution
• OS code injection
• Root access
• Systemd changes
• Files being modified, renamed, or deleted

These events can reveal suspicious behaviour before SAP services or data are significantly affected.

While individual events may result from legitimate administration, their value increases when correlated chronologically. For example, an external connection followed by root access, malicious program execution, systemd modification, and widespread file changes would present a strong indication of potentially malicious activity.

Forwarding these alerts to a SIEM allows security teams to correlate SLES activity with SAP, HANA, identity, endpoint, and network events, supporting earlier ransomware detection and faster incident response.

Conclusion

By combining configuration assessment, sensitive-file protection, port and service detection, security hardening, audit-log monitoring, ransomware protection, and SIEM integration, the Cybersecurity Extension for SAP helps organizations manage SLES security as an integral part of SAP cybersecurity.

It provides the continuous visibility required to reduce operating-system exposure, detect unauthorized activity, support compliance, and protect the underlying platform on which critical SAP business processes depend.

Frequently Asked Questions

1. Why is operating-system security important for SAP systems?

SAP applications rely on the operating system to manage processes, files, user accounts, network connections, services, and access to sensitive data. Weaknesses at the OS layer can allow attackers to bypass application-level controls, disrupt SAP services, steal credentials, or compromise critical business information.

2. Why is SUSE Linux Enterprise Server widely used for SAP workloads?

SUSE Linux Enterprise Server is widely used for SAP HANA and SAP S/4HANA because of its longstanding alignment with SAP technologies, performance optimization, high-availability capabilities, enterprise support, and availability of an SAP-specific distribution.

3. Which SAP and HANA files require the strongest protection?

Sensitive resources include SAP system profiles, PSE certificate files, ABAP and HANA secure stores, HANA INI configuration files, SAP and HANA executables, service-account SSH keys, sudo configurations, and system startup definitions. Access should be restricted through appropriate ownership, permissions, monitoring, and change control.

4. Which ports should be open on a SLES server supporting SAP?

Only ports required for documented SAP communications, approved infrastructure services, and authorized administration should be open. Examples may include instance-specific SAP dispatcher, gateway, message server, HTTP, HTTPS, and SAP HANA ports. Access should be limited to trusted systems, interfaces, and network zones.

5. Should every port on a security blacklist be closed?

No. Some ports commonly included in security review lists may support legitimate services such as SSH, DNS, NTP, LDAP, HTTPS, or SAP HANA. Administrators should identify the process using each port, validate the business requirement, restrict its exposure, and close it when it is unnecessary.

6. What are the most important SLES hardening controls for SAP?

Key controls include timely patching, removal of unnecessary packages and services, secure SSH configuration, strong authentication, least-privilege administration, restrictive file permissions, host-firewall enforcement, AppArmor protection, secure mount options, boot protection, logging, and file-integrity monitoring.

7. How should privileged access be managed on SAP hosts?

Administrators should use unique named accounts and controlled sudo privileges instead of shared root access. Direct root login, empty passwords, unrestricted NOPASSWD rules, and unnecessary interactive access for system accounts should be prohibited. Multifactor authentication should be considered for high-risk administrative access.

8. What is the role of auditd in SLES security monitoring?

The Linux Audit Framework and auditd record security-relevant activity such as privileged command execution, authentication events, user and group changes, file-access failures, permission changes, kernel-module activity, and modifications to critical configurations. Audit records provide evidence for threat detection, investigation, and compliance.

9. Where are SLES audit records stored?

Audit records are normally stored in /var/log/audit/audit.log. Organizations should protect this directory with restrictive permissions, sufficient storage, log rotation, and defined actions for low-space or disk-full conditions. Logs should also be forwarded to a protected central platform or SIEM.

10. How does file-integrity monitoring support SAP security?

Tools such as AIDE can detect unauthorized changes to SAP profiles, HANA configuration files, certificates, secure stores, operating-system binaries, audit tools, SSH settings, and startup files. Monitoring should account for approved changes introduced by patching, maintenance, and certificate renewal.

11. How does the Cybersecurity Extension for SAP support SLES hardening?

The Cybersecurity Extension for SAP assesses SLES configurations across authentication, SSH, privileged access, file permissions, networking, patching, cryptography, audit logging, AppArmor, file-integrity monitoring, and other security areas. It also reviews permissions on sensitive SAP, HANA, and operating-system resources and identifies potentially vulnerable ports and services.

12. What SLES security events can the Cybersecurity Extension for SAP detect?

The solution can monitor for changes to SAP profiles, SSH, PAM, sudo, systemd, crontab, kernel, network, and audit configurations. It can also identify failed access attempts, privilege abuse, root command execution, suspicious scripts, malicious programs, code-injection indicators, account changes, software installation, file modifications, and kernel-module activity.

13. Can SLES security alerts be forwarded to a SIEM?

Yes. Alerts can be forwarded to SIEM platforms for monitoring and investigation by the security operations centre. This allows SLES events to be correlated with SAP application, SAP HANA, authentication, network, and infrastructure activity to identify cross-layer attack sequences.

14. How often should organizations review SLES security controls?

SLES security should be monitored continuously and reassessed after operating-system upgrades, SAP maintenance, architecture changes, new integrations, firewall modifications, and changes to administrative access. Periodic reviews alone may not identify unauthorized activity or configuration drift quickly enough.

15. What is the main benefit of integrating SLES monitoring with SAP security?

Integrated monitoring provides visibility across the operating system, database, and application layers. This helps organizations reduce their attack surface, identify suspicious activity earlier, improve incident investigation, support compliance, and strengthen the resilience of business-critical SAP systems.

16. How does SLES monitoring help protect SAP systems from ransomware?

SLES monitoring can help detect ransomware by identifying operating-system activity associated with initial access, privilege escalation, malware execution, persistence, and file encryption.

The Cybersecurity Extension for SAP monitors events such as unexpected external connections, malicious program execution, root access, code injection, systemd changes, file-system mounts, failed file access, and files being modified, renamed, or deleted.

Correlating these alerts and forwarding them to a SIEM can help security teams identify ransomware attack patterns earlier, investigate affected SAP hosts, and respond before critical SAP data and services are significantly disrupted.

This structure separates the article into distinct sections for operating-system risk, network security, SLES hardening, audit configuration, Cybersecurity Extension for SAP capabilities, ransomware protection, and frequently asked questions.

The post Securing the SAP Foundation: Protecting SUSE Linux Enterprise Server for SAP Applications appeared first on Layer Seven Security.

Hot news note 3747367 addresses a critical memory corruption vulnerability in SAP NetWeaver Application Server ABAP, tracked as CVE-2026-44747. An authenticated attacker could exploit faulty memory-management logic to perform an out-of-bounds stack write, potentially gaining unauthorized access to data, modifying information, or causing system unavailability. The vulnerability therefore has a high impact on confidentiality, integrity, and availability. SAP’s correction introduces proper validation of allocated memory boundaries to prevent the unsafe write. Customers should implement the correction instructions, applicable Support Packages, or the ABAP Kernel patch referenced in the note. A temporary workaround is available by disabling all ICF services configured with the GUI Interface option, including /sap/bc/gui and relevant custom services. However, this disables SAP GUI for HTML functionality and may significantly disrupt operations, so SAP strongly recommends installing the kernel patch instead. Further technical information is available in SAP Knowledge Base Article 3779058.

Hot news note 3727078 addresses a critical directory traversal vulnerability in the Web Container of SAP NetWeaver Application Server Java, tracked as CVE-2026-40128. An unauthenticated remote attacker could craft a malicious HTTP logon request that manipulates file-inclusion parameters, allowing traversal outside the intended directory and processing of a local file. Successful exploitation could expose or modify sensitive information or cause parts of the system to become unavailable. The vulnerability results from insufficient path validation and has a CVSS score of 9.0, with high impact on confidentiality, integrity, and availability. SAP has corrected the issue by preventing traversal outside the intended application context. The note was re-released on July 14, 2026, with updated patch information, extending the ENGINEAPI 7.50 correction coverage from Support Package 20 through Support Package 28. Customers should implement the referenced Support Packages and patches immediately, as no workaround is available. Additional guidance is provided in SAP Note 1974464 and FAQ document 3758864.

Note 3720138 addresses a high-risk HTTP request smuggling vulnerability in SAP Approuter, tracked as CVE-2026-27690. An unauthenticated remote attacker could send a specially crafted HTTP request that causes request-response desynchronization between systems. Successful exploitation could expose other users’ responses and disrupt service availability, resulting in high impact on confidentiality and availability. The vulnerability affects SAP Approuter deployments running in non-Cloud Foundry environments, including relevant XSA scenarios. SAP has resolved the issue in Approuter version 20.10.0 and later by automatically setting DISABLE_CONNECTION_REUSE to TRUE when the application runs outside Cloud Foundry. Customers should upgrade the @sap/approuter Node.js package to version 20.10.0 or above. Organizations using SAP HANA XS Advanced should also follow the mitigation guidance in SAP Note 3770203. The vulnerability has a CVSS score of 9.1 and requires no authentication, user interaction, or elevated privileges. Additional information is available in FAQ SAP Note 3731137.

Note 3753495 addresses insecure sample OAuth2 credentials in SAP Commerce Cloud, tracked as CVE-2026-44761. SAP Commerce documentation previously included sample ImpEx scripts that created an OAuth2 client named trusted_client using publicly documented credentials intended only for development and testing. If a customer executed the script in production and retained the original client secret, an unauthenticated attacker could use the credentials to obtain a valid access token and invoke certain APIs to read or modify data. Successful exploitation has a high impact on confidentiality and integrity but does not affect availability. Customers should audit production environments for the trusted_client OAuth2 client and remove it when it still uses the documented sample secret. As an immediate temporary measure, the client secret should be rotated to a strong, randomly generated value. Environments where the sample client was removed or its secret was already replaced are not affected. SAP has also updated the relevant Commerce documentation, with further guidance available in FAQ SAP Note 3758007.

The post SAP Security Notes, July 2026 appeared first on Layer Seven Security.

This can be achieved by analysing two important log sources for BTP. The first is the Cloud Foundry Controller (CAPI) which governs application deployment and management in BTP. CAPI is the central API service that receives requests and translates them into actions within Cloud Foundry (CF). Cloud Foundry is the platform within BTP that is used to build, deploy and run applications.

CAPI v3 is an API that can be used to retrieve events from the /audit_events endpoint in Cloud Foundry. This includes actions such as service instance and service key lifecycle events, space and organization role assignments, and application lifecycle changes. To retrieve Cloud Foundry audit events from the CF CAPI v3 /v3/audit_events endpoint, you need to authenticate with a Cloud Foundry platform user and assign that user the right level of visibility across the relevant organizations and spaces. A dedicated technical user should be created in SAP Identity Authentication Service and assigned the appropriate Cloud Foundry visibility — typically the Org Auditor role at the organization level and the Space Auditor role in each monitored space — for each organization that needs to be monitored.

After the technical user is created, the IAS origin key should be identified from the SAP BTP trust configuration and used during Cloud Foundry CLI login or token requests. Access should be validated using the CF CLI by confirming the active target, checking the user’s assigned roles, and testing the endpoint with cf curl against /v3/audit_events.

For automated monitoring, integrations should retrieve UAA bearer tokens programmatically using the technical user credentials and securely store those credentials in a secret store or protected environment variable. Once configured, the integration can continuously poll the CAPI v3 audit events endpoint to collect Cloud Foundry runtime events, including service instance changes, service key activity, role assignments, and other audit-relevant events. Because CAPI v3 retains events for 31 days only, polling intervals must be short enough to ensure no events are missed before expiry.

The second important source for security related events in BTP is the Audit Log Management Service. This is a centralized logging and compliance service that collects, stores, and provides access to audit-relevant events across SAP BTP services and environments. This includes user logons and failures, role and permission changes, subaccount configuration changes, API calls, and administrative actions. The CF v2 Audit Log API is used to retrieve events from the service.

To use the CF v2 Audit Log API in SAP BTP, start by creating or locating an Audit Log Management Service instance for the scope of audit events you need to collect. The central plan, which must be deployed in the EU10 region, is used for global account-level audit events, while the standard plan is used for audit events from individual subaccounts. For each required service instance, navigate to the target subaccount in the SAP BTP Cockpit, open Services > Instances and Subscriptions, and select the relevant Audit Log Management Service instance.

Next, create a service key for the instance. The service key contains the API endpoint and OAuth credentials needed to authenticate against the service. After the key is generated, copy the full JSON credential block and identify the key fields: the root-level url, which is the Audit Log Management API endpoint; uaa.url, which is used only for token generation; and the uaa.clientid and uaa.clientsecret, which are used as OAuth client credentials.

Authentication is performed using the OAuth 2.0 client credentials grant type. Send a POST request to uaa.url with /oauth/token appended, using Basic Authentication with the client ID and client secret from the service key. Include grant_type=client_credentials in the request body. A successful response returns an access token, which is then passed as a Bearer token in subsequent API calls.

Once authenticated, retrieve audit log records by sending a GET request to the CF v2 audit log endpoint using the root-level API url, not the uaa.url. The request follows the pattern url/auditlog/v2/auditlogrecords?time_from=<ISO8601_datetime>, with the access token included in the Authorization header. The time_from parameter limits the results to records created at or after the specified timestamp, and additional filters such as time_to can be used to narrow the query further.

This process must be repeated for each Audit Log Management Service instance. Each central or standard instance has its own service key, credentials, API endpoint, and OAuth token, so credentials should not be reused across subaccounts or service plans.

The Cybersecurity Extension for SAP delivers comprehensive security logging and monitoring for SAP BTP by integrating with key telemetry sources, including the BTP Audit Log Management Service and Cloud Foundry APIs. Through this integration, the extension provides real-time detection and alerting across the following classes of events in BTP.

• Identity and Access Management – including the creation, modification, and deletion of identity providers, users, user groups, roles, and role collections; assignment of role collections to users; and high-risk privilege grants such as Global Account, Subaccount, Security Administrator, and emergency administrator access.
• Authentication – covering successful and failed logons, SAML authentication errors, IAS token handling issues, OAuth token issuance, authorization codes, JWT token creation, and service client authentication activity.
• Configuration and Governance – including configuration changes at the global account and subaccount level, password policy updates, API access and OAuth client configuration changes, and token signing key updates.
• Federation and Trust Configuration – such as creation, modification, and deletion of SAML attribute-to-role collection mappings, which can dynamically grant access through identity federation.
• Service and Credential Management – including creation, modification, and deletion of service instances and service keys, as well as access to service key credentials, representing a critical control point for sensitive data exposure.
• Cloud Foundry Platform – covering application lifecycle actions (stop, restart, restage, environment changes, and task execution), space and organization lifecycle events, role assignments and removals, and updates to space security configurations.
• Platform Extensibility and Supply Chain – including registration, update, and deletion of service brokers and buildpacks, which influence the software supply chain and runtime behavior of applications.

By correlating these classes of events into contextual alerts—such as privilege escalation, unauthorized configuration changes, identity misuse, or potential data exposure risks—the Cybersecurity Extension enables organizations to transition from fragmented logging to a centralized, policy-driven detection and response capability across the SAP BTP landscape.

Frequently Asked Questions

Why is security logging important for SAP BTP?

Security logging is important for SAP BTP because the platform supports business-critical applications, integrations, automation, analytics, and AI-enabled services. Monitoring security-relevant events helps organizations detect unauthorized access, privilege escalation, configuration changes, service credential misuse, and other activities that could impact the integrity and security of SAP cloud environments.

What are the main log sources for SAP BTP security monitoring?

The two main log sources are Cloud Foundry CAPI v3 audit events and the SAP BTP Audit Log Management Service. CAPI v3 provides visibility into Cloud Foundry runtime activity, while the Audit Log Management Service captures audit-relevant events from SAP BTP services and environments, including authentication, authorization, configuration, and administrative activity.

What does the Cloud Foundry CAPI v3 audit events endpoint capture?

The CAPI v3 audit events endpoint captures Cloud Foundry platform activity such as application lifecycle changes, service instance creation or deletion, service key activity, space and organization role assignments, and other runtime events. These events are useful for monitoring changes that may affect application security, service access, or platform governance.

How is access to CAPI v3 audit events configured?

Access to CAPI v3 audit events requires authentication with a Cloud Foundry platform user. A dedicated technical user should be created and assigned appropriate visibility across the organizations and spaces being monitored, typically using the Org Auditor and Space Auditor roles. Access should then be validated using the Cloud Foundry CLI and tested against the /v3/audit_events endpoint.

How long are CAPI v3 audit events retained?

CAPI v3 audit events are retained for 14 days. For this reason, automated monitoring integrations should poll the endpoint regularly to ensure that events are collected before they expire.

What does the SAP BTP Audit Log Management Service capture?

The SAP BTP Audit Log Management Service captures audit-relevant events such as successful and failed logons, role and permission changes, subaccount configuration updates, API calls, service activity, and administrative actions. It provides a centralized source of security and compliance evidence across SAP BTP services and environments.

How are Audit Log Management Service events retrieved?

Audit Log Management Service events are retrieved using the CF v2 Audit Log API. Access requires a service instance, a service key, and OAuth client credentials. The integration first requests an OAuth access token using the client credentials grant type, then uses the token to retrieve audit log records from the audit log API endpoint.

What is the difference between the central and standard Audit Log Management Service plans?

The central plan is used for global account-level audit events and must be deployed in the EU10 region. The standard plan is used to collect audit events from individual subaccounts. Organizations may need both plans depending on the scope of monitoring required.

Why should service keys and credentials be managed separately?

Each Audit Log Management Service instance has its own service key, OAuth credentials, API endpoint, and token flow. Credentials should not be reused across subaccounts or service plans because each instance represents a separate logging scope and security boundary.

How does the Cybersecurity Extension for SAP support SAP BTP monitoring?

The Cybersecurity Extension for SAP integrates with the SAP BTP Audit Log Management Service and Cloud Foundry APIs to centralize security monitoring and alerting. It detects high-value events across identity and access management, authentication, configuration governance, federation and trust settings, service and credential management, Cloud Foundry activity, and platform extensibility.

What types of risks can be detected through SAP BTP security logging?

SAP BTP security logging can help detect privilege escalation, unauthorized configuration changes, identity provider misuse, suspicious authentication activity, service key exposure, changes to trust mappings, risky Cloud Foundry role assignments, and modifications to service brokers or buildpacks that may affect the application supply chain.

What is the main benefit of centralizing SAP BTP security monitoring?

Centralized SAP BTP security monitoring helps organizations move beyond fragmented log collection. By correlating events across accounts, subaccounts, services, and runtime environments, organizations can identify meaningful security incidents faster and support a more policy-driven approach to detection, response, and compliance.

The post Security Logging for SAP BTP appeared first on Layer Seven Security.