Bug in SAP's S/4 HANA exploited in the wild, rated critical CVSS 9.9

SecurityBridge Threat Research Labs shared Sept. 4 discovering a critical 9.9 code injection flaw in SAP S/4 HANA was exploited in the wild. SecurityBridge urged security teams to apply the patch originally issued by SAP on Aug. 11.

The researchers said exploitation of CVE-2025-42957 required access only to a low-privileged user to fully compromise an SAP system.

The bug affects all S/4 HANA releases and successful exploitation gives an attacker access to the operating system and complete access to all data in the SAP system.

“2025 has been marked by a worrying trend of SAP vulnerabilities being exploited in the wild, with the window between disclosure and large-scale exploitation narrowing dramatically,” said Jonathan Stross, SAP Security Analyst at Pathlock.

Stross said that in the case of CVE-2025-42957, the exploitation activity surged dramatically as the patch was released — attackers quickly picked up the vulnerability and weaponized it more broadly. He said successful exploitation of CVE‑2025‑42957 can grant an attacker administrator‑level control in SAP and deliver a path to OS‑level actions.

“In practice, attackers can steal sensitive regulated data, create hidden backdoors, harvest credentials, disrupt operations, and even deploy ransomware,” said Stross. “This latest vulnerability underscores the growing urgency of applying SAP security updates without delay. A patch timeframe of a month, which is still common in some enterprises, is no longer feasible against these type of threats.”

Shane Barney, chief information security officer at Keeper Security, added that this recent SAP CVE is a textbook example of why teams should never let untrusted input dictate how code runs. Once dynamic code execution is in play, attackers can turn small openings into complete system compromise, said Barney.

Barney said the right mitigations start with avoiding dynamic code execution altogether — or at minimum — strictly whitelisting what commands are allowed. Here are some steps:

Validate all inputs against allow-lists, not block-lists.
Replace risky dynamic execution with libraries or APIs that provide safer parsing and better visibility.
Run applications with the minimum OS and database privileges possible, and use sandboxing, containerization or microservices to contain the blast radius if something goes wrong.
Layer defenses with tools like web application firewalls and make sure logging and alerting are in place to flag unexpected execution paths.

“The real takeaway is that defenders need a deep understanding of how their applications are designed to operate — what they connect to, which ports they use and how they behave at runtime,” said Barney. “Only by comparing that expected state to what’s actually happening can teams catch and contain attacks like this before they spread.”