Patch to Exploit in Three Days: How CVE-2026-58231 Opens SAP Commerce Cloud's Data Hub Adapter to Unauthenticated Attackers

We keep coming back to bugs where the vendor's own trusted internal plumbing turns out to be the attack surface. SAP's August Security Patch Day landed on the 11th. By the 14th, Defused's honeypots were logging hits on port 443 aimed at /datahubadapter/import/** from 216.249.99.43 in AS11402 (Charlotte Colocation Center), with no public proof of concept in circulation. Somebody had pulled the vendor patch, diffed it, spotted the missing check, and started spraying whatever internet-facing SAP Commerce Cloud instances they could reach (Bleeping Computer, CybersecurityNews).

CVE-2026-58231 is worth your afternoon because the vulnerable path is not a forgotten JSP or an abandoned admin console. It is the sanctioned way SAP Commerce Cloud ingests bulk data from a Data Hub server, and it speaks Hybris's own ImpEx dialect. Under the right flag ImpEx runs Groovy, which means a POST body accepted here is functionally a script running inside your commerce JVM; pair that with a default authentication client that never got rotated at deploy time and unauthenticated visitors are handed a scripting shell inside the retail platform your Fortune 500 customers check out against.

What the Data Hub Adapter was supposed to be

Data Hub sits between your ERP world and Commerce Cloud: it pulls IDocs and other feeds, transforms them into a canonical model, and publishes them into Commerce as ImpEx over an HTTP adapter (SAP Help Portal, hybrismart deep dive). The adapter's job is narrow: accept those pushes, unpack the ImpEx, and hand it to Commerce's import engine so catalog, prices, and inventory stay in sync upstream. It is trusted to the point that Commerce assumes the caller is a Data Hub server on a controlled segment, authenticated by a single OAuth client credential shipped in the extension itself that customers are meant to swap out at deployment time.

A default client and an endpoint that does not check twice

SAP Security Note 3771065 covers the details (Layer Seven, Onapsis). The adapter ships with a default authentication client, and once a request presents that identity the import functions skip the authorization checks a properly configured deployment would rely on. Compounding it, those import functions do not sufficiently validate their inputs. An unauthenticated attacker who can reach /datahubadapter/import/** over HTTPS submits whatever ImpEx payload they like, and the server processes it as if a paired Data Hub had just delivered a routine catalog refresh. SAP calls the class improper authorization plus insufficient input validation, and the CVSS 10.0 reflects that both halves are reachable without credentials, without user interaction, at low complexity.

When the data format is also a scripting language

ImpEx is the internal DSL Commerce Cloud uses for bulk data operations. Ninety percent of the time it is boring: rows of product records, price sheets, stock updates. It also carries scripting hooks. A block introduced with #% beforeEach: executes as Groovy against the running JVM before each row, and matching #% beforeAction: and #% afterAction: blocks run at defined lifecycle points (Hybris Groovy reference, SAP Community). Code execution is gated by an impex.legacy.scripting flag; Hybris' own guidance is to keep that flag off in production for anything loaded via hot folders, but for the Data Hub Adapter's normal operation that gate is often open because legitimate integrations use scripting hooks to massage incoming data.

SAP has not published the exact primitive the in-the-wild attackers are using, and no public PoC exists. The reachable capabilities of ImpEx tell you the primitive space is narrow: with code execution on, a two-line #% beforeEach: block wrapping Runtime.getRuntime().exec("...") is enough; with it off, file writes and processor injection give a patient attacker a chain. Either way the attacker gets code running as the Commerce Cloud application user, which typically has direct access to the item type database and cached tokens for connected ERP and payment systems.

What the honeypot actually caught

Defused's timeline is tight: patch shipped August 11, 2026, first exploitation attempts on August 14 (eSecurity Planet, Security Affairs). Initial bursts came from 216.249.99.43 in AS11402 (Charlotte Colocation Center, United States), classified as automated mass scanning. It is a pattern that keeps repeating on SAP advisories rated CVSS 9.0 and above: adversaries treat the vendor patch as the exploit, diff it, and race the enterprise patch cycle by a comfortable margin. The interesting question is which unpatched instances are not honeypots.

Why your existing telemetry probably misses it

Requests to /datahubadapter/import/** are supposed to happen, and in a healthy environment they happen constantly, arriving as HTTP POST bodies over TLS from a short list of Data Hub IPs and returning 200. Your WAF is unlikely to carry a signature for ImpEx, and even if it did the payload looks like a normal data push right up to the #% control lines. Most SIEM content packs for SAP focus on ABAP stacks, RFC, and gateway abuse rather than the Commerce Cloud Java runtime, and application logs mostly record which items were imported, not the scripting that ran on the way in.

The adapter usually sits on an internal segment behind a load balancer, which lulled teams into treating it as low risk while authentication actually held. With a default client bypass in play, any compromised workstation, VPN client, or third-party integration on that segment becomes a launchpad; Charlotte Colocation just found the internet-facing ones first.

Hunting it in your own logs

Three anchors are worth building. Invert your IP allowlist and use it as detection: you already know which hosts are supposed to POST to /datahubadapter/import/**, so alert on any request to that path from a source outside that list, ideally at the load balancer or reverse proxy where the client IP is still visible. Then ingest ImpEx bodies (or hash and sample if size is a concern) and search for #% beforeEach, #% beforeAction, #% afterAction, #% impex.include, or Groovy Runtime and ProcessBuilder references at the top of a payload from a source you have no data contract with. Watch the Commerce Cloud host too: the Hybris server JVM (hybrisserver.sh, y-tomcat) spawning sh, bash, curl, wget, nc, python, or powershell is worth an immediate page.

In MITRE ATT&CK terms you are covering T1190 (Exploit Public-Facing Application) at the ingress, T1078.001 (Default Accounts) at the authentication gap, and T1059 (Command and Scripting Interpreter) at the payload. Pull the last thirty days of adapter access logs and diff source IPs against your Data Hub inventory; hits from 216.249.99.43, from anywhere else in AS11402, or from any ASN that is not a paired Data Hub are the first place to look for a compromise that has already happened.

Patch, restrict, verify

The fix ships in SAP Commerce Cloud 2211.55 and 2211-jdk21.17, both addressing SAP Security Note 3771065 and requiring the rebuilt image to be re-deployed the same way any other Commerce Cloud release is (Onapsis). If a full patch cycle will take more than a few days, use SAP's own IP Filter Set feature to restrict /datahubadapter/import/** to the exact IPs of your Data Hub servers, which is the interim workaround SAP recommends. Turn off ImpEx code execution in the adapter's configuration wherever your flows do not need it, so an authorization bypass alone does not hand attackers a Groovy shell. Rotate the default client credential and everything the Commerce Cloud application user can reach: ERP connector creds, payment gateway keys, inventory tokens, and any object store credentials in use.

Verification is the part teams skip and then regret. After the patch, fire a POST at your import path from a host that is not on the allowlist, with no authentication, carrying a minimal ImpEx payload whose #% beforeEach: block writes a marker file to a known location; on a patched build the request should be rejected before the script runs, and if a marker file lands on disk you are not patched, whatever the version banner claims.

This is the loop BlueTeamAutomation runs continuously: safely emulate the adapter-to-script chain against your estate on a schedule, correlate what your EDR and SIEM caught, and produce audit-ready evidence the detection actually fired. BASzy exists because "we patched it" is a claim, and the only trustworthy version of that claim is a repeatable test that says so on Monday and again the week after.