How a forged XML document can pass a cryptographic signature check and impersonate any SAP user

The Context

SAP NetWeaver Application Server ABAP is the runtime platform that powers SAP's enterprise software suite, including the ERP, finance, supply chain, and HR systems that tens of thousands of organizations worldwide depend on for daily operations. In large enterprises, SAP NetWeaver is not one system but the hub of a connected landscape: multiple SAP products, tenants, and business processes all authenticate through a shared identity layer. When that identity layer fails, everything connected to it fails with it.

The specific component at issue is SAP's implementation of Security Assertion Markup Language (SAML) authentication. SAML is the protocol that allows a user to log in once through a central identity provider and then access multiple connected systems without logging in again. It is the backbone of enterprise single sign-on (SSO). In large SAP estates, SAML is not an optional feature. It is the primary access control mechanism for the entire landscape.

The Attack, Phase by Phase

Phase 1: Initial Access and Assertion Capture

The attacker starts with a legitimate low-privileged account, the kind a contractor or entry-level employee might have. They initiate a normal SAML login to SAP NetWeaver, which causes the identity provider to issue a valid, cryptographically signed SAML assertion. The attacker intercepts this assertion using a proxy tool before it reaches SAP. They now hold a real, signed XML document. They haven't broken anything yet. They've just captured the raw material for the next step.

Phase 2: XML Document Restructuring

The attacker decodes the intercepted assertion and opens the raw XML. They then perform a surgical restructuring: the original signed assertion is moved to a wrapper or sibling position in the document where it remains present and cryptographically intact. A new, forged assertion element is inserted in the position the application logic will read. This forged assertion contains a different identity, pointing to an administrator or any other target account. Critically, the original signed content has not been modified. The signature is still valid. The document now contains two assertions: one real and signed (hidden in a wrapper), one fake and unsigned (in the position the application will process).

Phase 3: Signature Verification Bypass and Identity Acceptance

The attacker submits the restructured document to SAP NetWeaver's SAML Assertion Consumer Service endpoint. SAP's verifier checks the cryptographic signature. It finds the original signed content, which is intact, and the check passes. The application logic then locates the assertion by tag name or document position rather than by confirming it is the same element the signature covered. It processes the forged assertion. SAP NetWeaver accepts the tampered identity as legitimate and issues a session as the impersonated user. No error is logged. No alarm is raised.

Phase 4: Privilege Escalation and Cross-Tenant Impersonation

With a forged session as an administrator, the attacker can read or modify financial records, HR data, and operational configurations. Because SAP landscapes connect multiple systems through the same federated identity layer, the attacker can pivot to connected SAP systems and tenants that trust the compromised identity. The CVSS "changed scope" rating reflects this: the blast radius is not limited to the entry point. Every system that trusts SAP NetWeaver's identity decisions is now exposed.

What Made This Possible

1. Verification and consumption are separate code paths. SAP's signature verifier and its identity-consumption logic look at different parts of the XML document. There is no enforcement that the element being verified is the same element being acted on. This structural disconnect is the root cause.

2. SAML's XML complexity creates ambiguity. SAML assertions are XML documents, and XML is a format where the same logical content can be represented in multiple structural ways. Locating an element by tag name or document position, rather than by cryptographic binding, leaves room for an attacker to insert content that passes one check and fails another.

3. Low-privilege access is all that's required. The attacker does not need to compromise an administrator account first. Any authenticated user can initiate a SAML flow and capture a valid signed assertion. The attack converts a low-privilege foothold into full administrative impersonation in a single step.

A passing signature check is not proof the application is acting on the signed data. It is only proof that the signed data is somewhere in the document.

What Should Have Stopped This

Every defense that would have reduced the blast radius here shares one trait: it does not depend on the SAML signature check being the sole enforcement point for identity.

• Strict XML signature validation tied to element identity. The fix SAP applied enforces that the element the signature covers is the same element the application processes. This is the correct architectural control: the verifier and the consumer must agree on which element is authoritative.
• Least-privilege access within SAP. If the impersonated session cannot reach sensitive data or connected systems without additional authorization checks, the blast radius shrinks even when impersonation succeeds. Role-based access controls inside SAP act as a second enforcement layer that does not rely on SAML integrity.
• Network segmentation of SAP systems. Limiting which systems can reach the SAML Assertion Consumer Service endpoint reduces the attacker's ability to submit forged documents in the first place.
• Monitoring for anomalous session behavior. A low-privilege user suddenly operating as an administrator is detectable if behavioral baselines exist. The attack produces no cryptographic alarm, but it does produce behavioral anomalies.

The Takeaway

CVE-2026-44748 is not a failure of cryptography. The signature algorithm worked correctly. The failure is the assumption that a passing signature check means the application is acting on the signed data. When verification and consumption are separate code paths, an attacker does not need to break the signature. They only need to make the two code paths look at different parts of the same document.

This is the same class of failure as the Stryker Intune wipe: a trusted mechanism (device management, cryptographic verification) is turned against the organization it was built to protect, not by breaking the mechanism but by exploiting the gap between what the mechanism checks and what the system acts on. The Axios supply chain attack followed the same logic: the build pipeline trusted a package because it passed the right checks, while the malicious payload sat in a part of the package the checks didn't cover.

Pattern to remember: A security check that passes does not guarantee the application is acting on the checked content. Verification and consumption must be cryptographically bound to the same element, or the check is incomplete.

What changed: XML Signature Wrapping turns the signature itself into camouflage. The attacker does not forge or break the signature. They exploit the gap between the element the verifier locates and the element the application consumes, so the signature becomes evidence only that the original content exists somewhere in the document, not that the application acted on it.

The Technical Mechanism

CVE-2026-44748 is a classic XML Signature Wrapping (XSW) attack against the SAML authentication stack in SAP NetWeaver Application Server ABAP. The root cause is CWE-347: Improper Verification of Cryptographic Signatures.

In a correctly implemented SAML flow, the service provider receives a signed XML assertion, verifies the cryptographic signature, and then consumes the identity data from the verified element. The vulnerability arises because SAP's implementation fails to enforce that the element the signature covers is the same element the application logic processes. The verifier and the consumer are separate code paths that locate the assertion by different means (tag name, XPath expression, or document position) rather than by cryptographic binding.

Attack path:

1. Attacker authenticates as a low-privileged user and initiates a SAML login flow against the SAP NetWeaver Assertion Consumer Service (ACS) endpoint.
2. Attacker intercepts the IdP-signed SAML response (via proxy, e.g., Burp Suite with SAML Raider) and decodes it: URL decode, Base64 decode, raw inflate to obtain raw XML.
3. Attacker restructures the XML document: the original <saml:Assertion> element (with its valid <ds:Signature>) is relocated to a wrapper or sibling node. A new, unsigned <saml:Assertion> element containing an attacker-controlled <saml:NameID> or <saml:Subject> is inserted at the position the application logic will process.
4. Attacker re-encodes and resubmits the restructured document to the ACS endpoint.
5. SAP's signature verifier locates the original signed assertion (still present, still intact) and the <ds:SignatureValue> validates correctly.
6. SAP's identity-consumption logic locates the assertion by tag name or document position, finds the forged element, and issues a session as the attacker-specified identity.
7. No signature verification failure is recorded. The attacker holds a valid session as any user in the system.

The vulnerability spans SAP_BASIS versions 702 through 919, covering many years of SAP deployments. The CVSS 3.1 vector reflects a changed scope (C:H/I:H/A:H across trust boundaries), meaning successful exploitation results in complete compromise of confidentiality, integrity, and availability beyond the directly vulnerable component.

The permanent fix, delivered in SAP Security Note 3746332, enforces strict binding between the signed element and the element consumed by application logic. The only available temporary workaround is disabling SAML authentication entirely.

CVE and Advisories

• CVE-2026-44748: XML Signature Wrapping in SAP NetWeaver AS ABAP and ABAP Platform. CVSS 9.9. Affects SAP_BASIS 702 through 919.
• SAP Security Note 3746332: The authoritative patch. Classified HotNews. Requires SAP customer portal access.
• CCB Advisory, June 9, 2026: Centre for Cybersecurity Belgium public warning recommending immediate patching.

MITRE ATT&CK Mapping

Indicators of Compromise

Detection is structurally difficult because the attack produces no cryptographic failure. The signature check passes. No authentication error is logged at the SAML layer. Potential indicators include:

• SAML assertions containing multiple <saml:Assertion> elements or unexpected wrapper structures in XML parsing logs, if raw SAML request logging is enabled.
• Sessions established for high-privilege or administrative accounts from IP addresses or user agents inconsistent with those accounts' normal access patterns.
• Low-privilege user accounts initiating SAML flows followed immediately by high-privilege session activity from the same source.
• Anomalous access to sensitive SAP transactions (financial posting, HR data, system configuration) by accounts with no prior history of such access.

The Centre for Cybersecurity Belgium confirmed no active exploitation in the wild had been observed as of June 9, 2026. The absence of observed exploitation does not reduce urgency: the attack requires only a low-privilege account and a proxy tool, and no proof-of-concept had been publicly released at disclosure time.

Attribution

CVE-2026-44748 was discovered and responsibly disclosed to SAP by the Onapsis Research Labs (ORL). SAP patched the vulnerability on its regular monthly Security Patch Day, June 9, 2026. No threat actor, nation-state group, or criminal organization has been attributed to discovery or exploitation of this vulnerability. No active exploitation in the wild had been confirmed at the time of public disclosure.

Primary Sources