SAP S/4HANA CVE-2026-44770

Exploitation requires a valid, authenticated session in the affected SAP S/4HANA system - specifically, a user account with at least restricted (low-privilege) access (PR:L per CVSS vector). The vulnerability manifests when such a user issues requests against specific entity set keys within the Create Single Payment OData service, bypassing authorization checks that should restrict visibility to authorized keys only. Exploitation is limited by: (1) the attacker must possess valid SAP credentials, ruling out unauthenticated external attackers; (2) access to the SAP S/4HANA system is typically restricted to internal networks or VPN; (3) impact is read-only information disclosure - no data modification or service disruption is possible. No special non-default configuration is required; the flaw is present in standard deployments of the affected component.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) scores 4.3 (Medium), reflecting network exploitability with low complexity but a mandatory authentication prerequisite (PR:L). The scope is unchanged and impact is limited solely to low confidentiality - no integrity or availability exposure is present. No KEV listing confirms active exploitation and no POC is identified, further reducing operational urgency. The real-world risk is constrained primarily by the authentication requirement: an attacker must first obtain valid (even low-privilege) credentials to an SAP S/4HANA instance, which is typically an internal or VPN-restricted enterprise system. For organizations with strict user provisioning, the threat surface is narrow. However, in large enterprises where many employees hold SAP accounts with restricted profiles, the pool of potential internal abusers is non-trivial. The missing EPSS score prevents probability-based triage; risk should be assessed contextually against the sensitivity of payment data exposed via the affected entity sets.

An authenticated SAP user with a restricted profile logs into the SAP S/4HANA Fiori or OData interface and crafts a direct GET request targeting the Create Single Payment entity set endpoint using keys outside their authorized scope. Because no authorization check intercepts the request, the application returns the payment-related entity data, exposing sensitive financial records to the restricted user. No public exploit code is identified, making opportunistic exploitation less likely than insider misuse.