Most common vulnerabilities in SAP systems: a technical guide

By the QuantumSec team

Most SAP compromises don't exploit an exotic flaw: they exploit well-known configurations that nobody thoroughly reviewed for years. This guide covers the most common vulnerabilities we find when auditing production SAP environments, from the easiest to fix to the one that usually carries the highest business impact.

Default accounts and weak passwords

SAP ships with standard accounts (SAP*, DDIC, SAPCPIC, EARLYWATCH) with widely documented default passwords. It's common to find them unchanged in development or pre-production clients — and, less often than it should be, in production too —, which is especially dangerous for the SAP* account, which under certain configurations retains system-administrator-equivalent privileges.

Misconfigured RFC interface and Gateway

SAP's Gateway manages Remote Function Call (RFC) calls between systems. When the access control lists (the secinfo and reginfo files) are misconfigured or missing, an attacker on the network can register malicious RFC programs or execute administrative functions without authenticating. The RECON vulnerability (CVE-2020-6287), which affected SAP NetWeaver AS Java and received the maximum severity score (CVSS 10), is the best-known example of how far a flaw at this layer can go: it allowed creating a user with maximum privileges without prior authentication.

Broken segregation of duties (SoD)

When a single user accumulates transactions that should be kept separate — for example, creating a vendor and approving payment to that vendor, or creating a purchase order and confirming its receipt — the authorization system makes it harder for an internal control to detect fraud. This kind of conflict tends to accumulate over time, as additional roles are granted without reviewing the full set of permissions a user already holds.

Unapplied SAP Security Notes

SAP releases security fixes monthly, on the second Tuesday of each month (SAP Security Patch Day), as SAP Security Notes. A system that accumulates unapplied security notes for months or years is exposed to publicly known vulnerabilities — often with public exploits too — that an attacker can identify simply by checking the system version and patch level.

Vulnerable custom ABAP code

Custom ABAP developments — reports, custom transactions, Web Dynpro or BSP extensions — don't automatically go through the same security controls as SAP's standard code. SQL or OS command injection is common when the development directly concatenates user input, and cross-site scripting shows up in custom web interfaces that don't properly sanitize output.

Exposed Fiori, OData and Message Server services

As SAP exposes more functionality through Fiori and OData APIs, the attack surface reachable from outside the internal network grows. An unrestricted Message Server, or an OData service with looser authorization controls than its equivalent SAP GUI transaction, can become an entry point that nobody monitors with the same level of attention as traditional access.

FAQ

Is an SoD review the same as a SAP pentest?

No. An SoD review confirms, on paper, which permission combinations users hold. A SAP pentest confirms whether those combinations — and other technical vulnerabilities like the Gateway, ABAP code or patch status — are actually exploitable, and demonstrates the real impact of a compromise.

Is the RECON vulnerability (CVE-2020-6287) still relevant?

The flaw itself has been patched since 2020, but it remains relevant as a reference case: months after disclosure there were still unpatched systems being actively scanned by attackers, illustrating the real risk of letting SAP Security Notes pile up unapplied.

How often should a SAP system be audited?

At least once a year, and always after relevant changes: an S/4HANA migration, a significant expansion of modules or roles, or an incident that raises suspicion of a compromise or internal fraud.