Three days after SAP patched a maximum-severity flaw in Commerce Cloud, attackers were already trying to exploit it. Threat intelligence firm Defused says it caught exploitation attempts in its honeypots almost immediately, and Microsoft’s Shadowserver project has since fingerprinted more than 4,200 internet-facing SAP Commerce Cloud instances.
The vulnerability, tracked as CVE-2026-58231, carries a perfect CVSS score of 10.0. It is a code injection flaw in the Commerce Cloud Data Hub Adapter, and it lets an unauthenticated attacker run arbitrary code on the target system. For shops running SAP Commerce on exposed infrastructure, this is about as bad as it gets.
What the vulnerability is
The flaw lives in the Data Hub Adapter, a component that moves product, inventory, and order data between SAP Commerce Cloud and connected systems. The problem comes down to two misses: insufficient authorization checks and weak input validation. A remote attacker can feed crafted input into the adapter’s exposed functions and get code execution back, with no credentials and no user interaction required.
The vulnerability is classified as a code injection issue, CWE-94. Its vector is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, which spells out the worst case: network reachable, low attack complexity, no privileges, no interaction, and a scope change that hits confidentiality, integrity, and availability at the highest level.
Affected versions and the patch
SAP confirmed the vulnerable releases are COM_CLOUD 2211 and the 2211-JDK21 variant. The company published a fix in Security Note 3771065 as part of its standard August 2026 security patch round.
Here is the uncomfortable part. Exploitation attempts started within three days of that patch. Public proof of concept code was not available at that point, which tells you something about the people running this. They are not waiting on public write-ups; they are comparing patch diffs and figuring out the vulnerable code paths on their own.
Why a 10.0 rating matters here
A perfect CVSS score is rare, and it usually appears around flaws that check every nasty box at once: remotely exploitable, no authentication, complete compromise. This one does exactly that. An attacker who lands it can run commands on the Commerce Cloud backend, which is the system holding product catalogs, customer data, order history, and payment-related records.
For operators, a 10.0 tells you to treat this as a take-it-right-now event, not a schedule-it-later item. The clock on a flaw like this is measured in fork gets, not months.
What defenders should do
Apply the note. Security Note 3771065 contains the fix, and every reachable Commerce Cloud instance should be patched before anything else happens. If you run the affected COM_CLOUD versions and the note requires additional steps beyond the missing checks, follow the remediation guidance in the note exactly.
While that is in flight, restrict who can reach the adapter. SAP recommends locking down the Data Hub Adapter endpoint with IP filter sets, so only known integration partners can talk to it. Any unauthenticated access path should be treated as hostile.
Watch the logs for requests headed at the Data Hub Adapter that arrive without expected integration context. An HTTP request that reaches these functions and carries no recognizable API or service identity is exactly the shape of an exploitation attempt.
Beyond the patch
If you have any doubt whether your environment was exposed before you patched, treat credentials and secrets on those systems as potentially leaked and rotate them. Exploitation does not always stop at code execution, and hand-rolled credentials used by the adapter may have been alive in the wild.
There is a broader pattern here that is worth holding on to. When a patch lands and attackers move within days, they are not being lucky, they are being systematic. A vendor fix is now less of a head start and more of a countdown, because reverse-engineered payloads follow the diffed fix quickly. Your one reliable defense is speed.
The art of the quick pivot
Looking at how the attacker side reacted to this disclosure is useful. When security teams talk about a perfect CVSS score, the temptation is to treat it as a lab exercise until a proof of concept appears in the open. That instinct is becoming dangerous. Here, no public PoC existed when Defused saw the first attempts, yet the exploitation still happened.
What changed is the reverse-engineering workflow at the top end of the threat ecosystem. Patch the fix, look at what files changed, and there is a short list of functions that just became interesting. A vendor note that says unauthenticated code execution in an adapter is not a hint, it is an instruction print. Skilled operators do not need a PoC to move quickly; they need the diff.
The defense that follows is blunt. Your patch window is your only real window, and it is shorter than the two-week cadence that many enterprise change-management processes assume. If the fix cannot be applied immediately, the compensating control is isolation: pull the vulnerable system out of the direct path, put it behind an allowlist, and monitor the adapter traffic hard enough that a probe shows up in the daily report rather than the quarterly one.
The broader lesson
This is not the first time a vendor patched a 9 or 10 and saw exploitation follow within days, and it will not be the last. The security posture at stake here is the one where you assume you will be probed soon after a fix. Whatever your patch cadence was last quarter, the pace of exploit development argues for getting faster.
The bottom line
CVE-2026-58231 is a 10 out of 10 unauthenticated RCE in SAP Commerce Cloud, and it is already being hit in the real world. The exposed-instance count sits somewhere above 4,200, and the window between patch and attack is measured in days. Patch against the note, close the adapter to unauthenticated callers, and scrub any systems that were reachable before remediation.