SAP's July 2026 Security Day delivered a set of patches that security teams running SAP environments need to process carefully. The headline vulnerability is CVE-2026-44747, an out-of-bounds write flaw in SAP NetWeaver Application Server ABAP scored at CVSS 9.9, one point below the maximum possible severity. Alongside it, SAP patched CVE-2026-27690, an HTTP request and response smuggling vulnerability in the SAP Approuter scored at CVSS 9.1, and CVE-2026-44761, a default credentials flaw in SAP Commerce Cloud also scored at CVSS 9.1. None of the three had confirmed active exploitation at the time of the advisory, but all three carry severity scores and attack characteristics that place them in the category of vulnerabilities that attackers will investigate quickly once public disclosure draws attention to them.
SAP systems present a distinctive risk profile for enterprise organisations. They are not general-purpose servers that handle a narrow slice of business data. They are often the operational core: the environment where financial transactions are processed, supply chain operations are managed, human resources records are stored, and production systems are controlled. A successful compromise of a SAP environment is rarely a footnote in an incident report. It tends to be the incident itself.
SAP NetWeaver Application Server ABAP is the runtime environment for ABAP-based SAP applications. ABAP (Advanced Business Application Programming) is the proprietary programming language that SAP uses for the majority of its business application layer. The AS ABAP component is the execution layer that runs these applications, handles user sessions, processes transactions, and communicates with the SAP database layer. It is not a peripheral component. In a typical SAP deployment, it is the central processing layer that nearly every SAP function depends on.
CVE-2026-44747 is an out-of-bounds write vulnerability in this component. Out-of-bounds write flaws occur when software writes data beyond the boundaries of an allocated memory buffer, corrupting adjacent memory in ways that can cause crashes, data corruption, or, under controlled conditions, arbitrary code execution. SAP's advisory describes the impact as memory corruption that could lead to unauthorised data access, modification, or system unavailability. The CVSS score of 9.9 reflects an authenticated attack path: the attacker must have valid credentials to reach the vulnerable component, which is what keeps the score one point below 10.0. But authentication requirements in SAP environments are frequently softer barriers than they sound, given the number of service accounts, administrative users, and integration connections that exist in a typical enterprise SAP deployment.
SAP's workaround for environments that cannot immediately install the patched ABAP Kernel is to disable specific ICF (Internet Communication Framework) nodes through transaction SICF. This workaround has a cost: disabling those ICF nodes also disables SAP GUI for HTML, the browser-based interface that many users rely on for SAP access. In environments where the HTML GUI is in active use, implementing the workaround creates an immediate user experience impact that organisations will need to manage. This tension between security mitigation and operational continuity is common in SAP security events, and it is part of why SAP patches often take longer to deploy than patches in other software categories, even when the underlying vulnerability is critical.
The SAP Approuter is a Node.js-based component that serves as the single entry point for web applications built on the SAP Business Technology Platform. It handles authentication, session management, routing, and request proxying for cloud-native SAP applications. In non-Cloud Foundry environments, CVE-2026-27690 allows an unauthenticated attacker to send specially crafted HTTP requests that cause desynchronisation between the front-end and back-end connection handling.
HTTP request and response smuggling attacks exploit inconsistencies in how different layers of an HTTP processing chain interpret message boundaries. When the front-end and back-end disagree on where one HTTP request ends and the next begins, an attacker can inject a prefix into what the back-end believes is the next legitimate request. The consequences range from poisoning the response cache with malicious content that gets served to other users, to accessing content that should be behind authentication barriers, to bypassing security controls that operate at the front-end layer but not the back-end layer. In the specific case of CVE-2026-27690, SAP's advisory notes that the flaw enables request-response desynchronisation that exposes user responses and enables denial-of-service attacks against the Approuter service.
The CVSS score of 9.1 and the unauthenticated attack path make this a particularly important patch for organisations running SAP applications in non-Cloud Foundry environments. The absence of an authentication requirement means the attack surface includes any HTTP connection that can reach the Approuter, which in internet-exposed deployments means the attack surface is the public internet. Even in internally deployed configurations, the unauthenticated nature means that any attacker with network access to the Approuter, including an insider or a compromised system elsewhere on the network, can attempt exploitation without needing to compromise credentials first.
CVE-2026-44761 is the third critical vulnerability in July's SAP Security Day, and it represents a different category of risk entirely. SAP Commerce Cloud, the enterprise e-commerce platform, includes sample OAuth 2.0 client configuration scripts in the SAP Help Portal documentation. These sample scripts contain hardcoded credentials that are intended as examples for implementation guidance. The flaw exists when organisations retain these sample configurations in production environments rather than replacing the hardcoded values with unique, strong credentials of their own.
The impact SAP describes for CVE-2026-44761 is high on both confidentiality and integrity. An attacker who discovers that a Commerce Cloud deployment is using the default sample credentials can authenticate to the OAuth 2.0 client using the documented values and gain access to the platform at the level that client is authorised for. The attack requires no exploitation of technical vulnerabilities in the software itself. The software is working as designed. The vulnerability is in the deployment practice: failing to replace sample credentials before moving a configuration to production.
This class of vulnerability is both common and consistently underestimated. It appears regularly in security assessments of enterprise deployments, often in products where the documentation provides ready-to-use sample configurations for complex integration scenarios. The convenience of a working sample that can be dropped into a deployment as-is creates exactly the condition this flaw exploits. Organisations running SAP Commerce Cloud should audit their OAuth 2.0 client configurations specifically for the presence of credentials that match or resemble the sample values published in SAP Help Portal documentation, and rotate any that match regardless of how long they have been in place.
SAP's advisory for all three July 2026 critical vulnerabilities noted that there was no evidence of active exploitation in the wild at the time of publication. This distinction from the SonicWall advisory published the same week matters, but it should not translate into a slower response. The absence of confirmed exploitation at the moment of public disclosure is, in many cases, simply a statement about the gap between when researchers discover and report a vulnerability and when attackers begin scanning for it at scale. That gap is shorter today than it has historically been.
SAP environments are known targets for sophisticated attackers. SAP-specific attack tooling, including tools that scan for vulnerable SAP components and exploit common SAP misconfigurations, has existed for years and is available in underground markets. When a CVSS 9.9 flaw in a core SAP component receives public attention, the time between advisory publication and first exploitation attempts is measured in days, not weeks. The practical window for patching before exploitation begins is narrow, and the absence of confirmed exploitation at disclosure is not a guarantee that the window will remain open until a convenient maintenance schedule arrives.
SAP releases security patches on the second Tuesday of each month, a cadence that parallels Microsoft's Patch Tuesday and exists for similar reasons: it gives SAP customers a predictable schedule to plan their patching cycles and allows the coordination of multiple fixes into a structured release. July 2026's Security Day included patches for all three critical vulnerabilities alongside a larger set of medium and low-severity fixes across the SAP product portfolio.
For organisations with mature SAP change management processes, the standard approach is to evaluate the severity of each patch, group them by product area and environment tier, and schedule deployment accordingly. CVE-2026-44747 in NetWeaver AS ABAP, CVE-2026-27690 in Approuter, and CVE-2026-44761 in Commerce Cloud represent the top priority tier from this month's release. They should not wait in a general patch queue alongside lower-severity fixes. For environments where emergency patching outside the standard cycle is possible, these three vulnerabilities warrant it.
Patching SAP systems is technically and organisationally more complex than patching most enterprise software. SAP environments are typically deeply customised, tightly integrated with other enterprise systems through SAP's integration framework, and subject to functional testing requirements before changes can be confirmed as safe in production. A kernel update to address CVE-2026-44747 requires testing against the organisation's specific ABAP application landscape, not just confirmation that the update deploys cleanly on a test system. That testing cycle takes time, and the time it takes means the window of vulnerability extends longer than in simpler software environments.
The workaround for CVE-2026-44747 (disabling ICF nodes via SICF) exists specifically to address this situation. It allows organisations that cannot immediately deploy the patched ABAP Kernel to reduce their exposure while the testing cycle for the full patch runs its course. Implementing the workaround immediately and running the full patch through testing in parallel is the approach that balances security urgency against the operational caution that SAP environments require. For CVE-2026-44761, no workaround is needed at the software level: the fix is an operational one, replacing the documented sample credentials with unique values, which can be done immediately without waiting for a patch deployment cycle.
Understanding your organisation's external attack surface becomes particularly relevant during SAP patching events. SAP components that are externally accessible, including Approuter-fronted web applications, expand the attack surface significantly beyond the internal systems that traditional SAP security focuses on. Mapping which SAP components face the internet and which are internal-only is a prerequisite for prioritising patches, because the urgency of patching CVE-2026-27690 in an externally accessible Approuter deployment is materially higher than in a deployment that is accessible only from within a protected internal network.
The July 2026 Security Day is a reminder that SAP security is not a once-a-year consideration that surfaces during audit cycles. It is a continuous operational discipline. Three critical vulnerabilities across three different SAP product lines in a single monthly release is not unusual. The range of affected products, from core ABAP application server to cloud-native application routing to commerce platform, reflects the diversity of the SAP landscape that most large enterprises maintain. Each of these product lines has its own update mechanism, its own testing requirements, and its own change management path. Treating them as a unified portfolio that requires coordinated attention is the approach that keeps the overall SAP attack surface under control.
The patch for CVE-2026-44747 requires updating the ABAP Kernel, which is a specific term in SAP architecture that non-SAP security specialists often misinterpret. The ABAP Kernel is not the operating system kernel of the server on which SAP runs. It is SAP's own execution engine: the layer of compiled C code that interprets and runs ABAP programs. It sits between the operating system and the ABAP application layer, handling memory allocation, work process management, and the execution context that every ABAP program runs within.
Updating the ABAP Kernel requires a specific SAP procedure that differs from a standard operating system patch. The new kernel binary must be downloaded from the SAP Service Marketplace, placed in the specific directory that SAP expects, and the SAP system must be restarted for the new kernel to take effect. The restart requirement has operational consequences: an SAP system restart affects all users currently connected and all background jobs currently running. For production systems running continuous processing, such as those running payroll, financial close processes, or manufacturing execution, scheduling and coordinating that restart is a non-trivial organisational task that requires advance communication, business approval, and a maintenance window. This operational overhead is the reason SAP kernel updates are often delayed relative to the urgency of the underlying vulnerability, and it is also the reason SAP provides workarounds: they exist specifically for organisations that need risk mitigation before they can schedule the restart.
CVE-2026-44761 represents a vulnerability class that should not need a formal CVE to be taken seriously by any security team: default credentials left in production systems. The fact that this flaw received a CVSS score of 9.1 and was patched in a formal SAP Security Day release reflects the seriousness of the consequences when those credentials are exploited in a complex enterprise system like SAP Commerce Cloud, but the root cause is a configuration practice that security fundamentals have advised against for decades.
The persistence of this class of vulnerability in enterprise software is partially a documentation problem. When a vendor publishes sample configurations with hardcoded credential values, the implicit message to administrators who are new to the product is that these values work, and working configurations have a strong tendency to remain in production environments. The pressure to move quickly through implementation, the complexity of SAP Commerce Cloud configuration, and the relative obscurity of OAuth 2.0 client management within SAP's broader administration interface all contribute to situations where the sample configuration ships to production unchanged. Addressing CVE-2026-44761 requires not just patching but an audit of all OAuth 2.0 client configurations in Commerce Cloud deployments to identify any that were derived from sample configurations and never had their credential values changed.
The broader question this raises is how many other sample configurations exist across an organisation's SAP landscape that carry default or sample credentials that were never changed. SAP is a complex environment with many integration points, and sample configurations exist across multiple product lines and integration scenarios. A targeted audit of OAuth 2.0 clients in Commerce Cloud is the immediate action CVE-2026-44761 demands. A broader review of all sample-derived integration credentials across the SAP landscape is the more thorough response that transforms a reactive patch into a structural improvement.
CVE-2026-27690 in the SAP Approuter falls into a vulnerability category that has received increased attention over the past two years as web application architectures have moved toward microservices and API gateways. HTTP request and response smuggling exploits a fundamental tension in how HTTP intermediaries handle the same traffic differently: when the front-end proxy and the back-end server disagree on message boundaries, an attacker can inject data into what the back-end perceives as the beginning of the next legitimate request.
The Approuter's role as the single entry point for cloud-native SAP applications makes it a high-value target for this class of attack. If an attacker can successfully smuggle requests through the Approuter, they can potentially bypass authentication controls that the Approuter enforces but the back-end microservices do not, access internal application endpoints that are not supposed to be reachable from external connections, or poison responses that the Approuter caches and serves to other users. The unauthenticated nature of CVE-2026-27690 means none of these outcomes require credentials to attempt.
For SAP BTP applications where the Approuter is the boundary between the internet and internal application logic, patching CVE-2026-27690 should be treated with the same urgency as a perimeter firewall rule change. The Approuter is the firewall in that architecture. A vulnerability in it is not an internal application risk; it is a perimeter risk that determines what the application's entire security posture is actually protecting against.
A consistent finding in enterprise security assessments is that SAP environments receive less systematic security attention than the business risk they represent warrants. The reasons are structural: SAP teams typically report into IT or business operations rather than security, SAP-specific security tooling requires specialist knowledge that general security teams rarely have, and the risk of breaking business-critical processes during security testing or patching creates a conservative culture around change in SAP environments.
The result is that SAP systems, which process some of the most sensitive business data in most large organisations, often operate with older patch levels and less rigorous security configuration than comparable general-purpose infrastructure. CVE-2026-44747, CVE-2026-27690, and CVE-2026-44761 in the July 2026 Security Day are not unusual in SAP's patch release history. Multiple critical and high-severity SAP vulnerabilities are released every month. The organisations that consistently fall furthest behind on SAP patching are those where the security team and the SAP team operate in organisational silos, each waiting for the other to take initiative.
Closing this gap requires the same integration of SAP into security governance that applies to any other business-critical system. SAP security notes should be reviewed by security teams on the same cadence as other vendor advisories. SAP environments should be included in vulnerability scanning and patch tracking programmes. And the urgency of critical SAP patches should be evaluated against the same risk framework as critical patches in operating systems, databases, and network infrastructure. The external attack surface of an organisation that runs internet-accessible SAP components, including Approuter-fronted BTP applications and Commerce Cloud storefronts, extends beyond what traditional perimeter security assessments typically cover.
When an enterprise network appliance is compromised, the attacker's next step is almost always to monetise the access. Credentials harvested from session logs, certificates extracted from the device, and authentication tokens captured in transit have a well-established route: they end up in stealer logs on criminal forums, dark web marketplaces, or private channels where initial access brokers sell them to the next buyer in the chain.
Defendis monitors these channels continuously. If credentials or data linked to your organisation surface following a perimeter device compromise, Defendis surfaces the exposure with full context: which individual is affected, what data was taken, and how the compromise likely unfolded. That intelligence allows your security team to act on a specific, confirmed risk rather than conducting an expensive, broad investigation with no direction.
Book a demo to see how Defendis approaches dark web monitoring for enterprise security teams.
