SAP shipped Commerce Cloud with a demo OAuth2 client whose password is on the internet in their own help portal
SAP Commerce Cloud ships a *sample* OAuth2 client that exists to let admins copy-paste through the getting-started guide. The client ID and secret are published verbatim in SAP Help Portal documentation, so if an operator never removed or rotated that client after go-live, an unauthenticated remote attacker can hit the /authorizationserver/oauth/token endpoint, receive a valid access token, and then call OCC/REST APIs to read or modify data. Affected releases are HY_COM 2205, COM_CLOUD 2211, and COM_CLOUD 2211-JDK21; SAP addressed it in July 2026 Security Patch Day.
SAP's 9.1 / CRITICAL rating matches reality for the default-configuration case. The vector is AV:N/AC:L/PR:N/UI:N — unauthenticated, network, low complexity, high confidentiality *and* integrity impact — and the target is an e-commerce platform holding customer PII, order records, and pricing logic. The only reason a given tenant might not be exploitable is if the operator followed hardening guidance and deleted the sample client; that is a configuration accident away, not a technical mitigation. Treat as CRITICAL until proven otherwise on each instance.
4 steps from start to impact.
Locate an exposed SAP Commerce Cloud endpoint
/authorizationserver/oauth/token, /rest/v2/, and /occ/v2/ paths on retail domains. Shodan/Censys queries for Server: SAP headers or the Hybris/OCC URL structure are trivial. Commerce Cloud storefronts are inherently internet-facing.- Target runs affected HY_COM 2205 or COM_CLOUD 2211/2211-JDK21
- OCC/REST API is reachable from the attacker's network
- Storefronts sit behind CDNs/WAFs that may rate-limit token endpoints
Request an access token with the documented sample client credentials
grant_type=client_credentials&client_id=<sample>&client_secret=<published> to the token endpoint using curl or a two-line Python script. The credentials come directly from SAP Help Portal — no guessing, no brute force. If the sample client was never removed, the server issues a valid JWT.- Sample OAuth2 client still registered in
oauthclientdetails - Sample client secret unchanged
- Operators who followed the SAP hardening checklist and deleted the sample client at go-live are immune
- Some deployments rotate the secret via impex during release automation
Enumerate scopes and reachable APIs
basic, extended, previewservice, or admin scopes depending on the sample client's grants). They then walk OCC catalogs, users, orders, and B2B endpoints via GET /occ/v2/{basesite}/....- Sample client bound to non-trivial scopes (default is usually broader than teams realize)
- If the sample client was configured with only
basicscope the blast radius is limited to catalog reads
Read and modify data
- Client has write scope OR read scope on PII endpoints
- B2B tenants sometimes silo APIs per basesite, limiting blast radius to a single storefront
The supporting signals.
| In-the-wild exploitation | No confirmed campaigns as of 2026-07-14 (day of disclosure). SAP e-commerce default-credential bugs historically weaponize within days once client_id/secret pairs circulate on Telegram/X. |
|---|---|
| Public PoC | No named repo yet; PoC is a two-line curl against /authorizationserver/oauth/token with credentials copied from SAP Help Portal documentation. Trivial to reproduce. |
| EPSS | Not yet scored (published today). Expect rapid climb given AV:N/PR:N/AC:L and public credentials. |
| KEV status | Not listed on CISA KEV as of 2026-07-14. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N — unauthenticated network attack, no user interaction, high confidentiality and integrity impact, no availability impact. Vendor score 9.1. |
| Affected versions | HY_COM 2205, COM_CLOUD 2211, COM_CLOUD 2211-JDK21. |
| Fixed version / note | SAP Security Note published 2026-07-14; fix removes the sample OAuth2 client from default provisioning and adds a startup warning if it is still present. |
| CWE | CWE-1392 — Use of Default Credentials. |
| Exposure data | Shodan queries for SAP Hybris/Commerce OCC endpoints return several thousand internet-facing hosts globally; percentage still running the sample client is unknown but historically for SAP default-cred bugs is 10–30%. |
| Disclosure / reporter | Disclosed 2026-07-14 in SAP July Patch Day. Reporter credited in SAP Security Note (not publicly listed on NVD yet). |
noisgate verdict.
Verdict stays CRITICAL because the exploit is *unauthenticated + network + trivial* against a canonical high-value role (an e-commerce platform storing PII, orders, and pricing) and the credentials required are published in SAP's own documentation. The single decisive factor is role multiplier: any Commerce Cloud tenant that never rotated the sample client is one curl away from mass data exposure.
Why this verdict
- Unauthenticated + published credentials: the attacker doesn't guess, brute-force, or phish — they copy-paste from SAP Help Portal. AC:L/PR:N is not aspirational, it is literal.
- Role multiplier: SAP Commerce Cloud is by definition a high-value role — customer PII, B2B pricing, order pipelines, payment context. Chain end is mass data read/modify. Floor is CRITICAL for this component class.
- Configuration-dependent, not architecture-dependent: every tenant that skipped the 'delete sample client' step in the hardening checklist is exposed. This is not a narrow version window — it spans three major release trains (2205, 2211, 2211-JDK21).
- Friction is thin: WAF/CDN in front of storefronts does not block
/oauth/token; that endpoint is required for legitimate integrations. Rate-limiting slows enumeration but does not stop a targeted attacker. - No KEV/PoC yet is a timing artifact — disclosed today. Trivially reproducible with public data, so weaponization is expected within days, not months.
Why not higher?
Already at the top severity bucket. No higher tier exists in the noisgate schema. A perfect 10 would require availability impact (A:H) or an unauth RCE giving code execution on the host; this bug is data-plane, not host-plane.
Why not lower?
Downgrading to HIGH would require evidence that ≥99% of installed base rotates the sample client at provisioning. SAP does not enforce removal, the default provisioning ships the client, and historic default-credential bugs in SAP show 10–30% residual exposure. Without installed-base evidence to the contrary, the CRITICAL floor holds.
What to do — in priority order.
- Delete the sample OAuth2 client immediately — In SAP Commerce Backoffice or via impex, remove the sample client row from
oauthclientdetails(the specific clientId is named in SAP Security Note for July 2026). This is the direct fix and applies within minutes — deploy within 3 days per noisgate mitigation SLA for CRITICAL, ideally within hours given the trivial exploit. - Block
/authorizationserver/oauth/tokenat the WAF for the sample client_id — Add a WAF rule that inspects POST bodies to the token endpoint and rejects requests whereclient_idequals the published sample value. Buys time on tenants that cannot immediately restart Commerce nodes. - Rotate secrets for ALL non-sample OAuth2 clients — If the sample client was left in place, assume operator hygiene on other clients is also weak. Rotate every client secret and audit
oauthclientdetailsfor stale integrations. - Audit access logs for the sample client_id going back 90 days — Search access and Tomcat logs for token issuance events referencing the sample client_id. Any hit from a non-SAP-owned IP is treated as an incident: assume PII/order data read.
- Apply the SAP July 2026 Security Patch — The vendor fix removes the sample client from default provisioning and logs a warning at startup if still present. Apply within 90 days per noisgate remediation SLA for CRITICAL, sooner if you cannot verify the client has been deleted.
- Storefront WAF / CDN alone — the token endpoint must accept POSTs from legitimate integrations, so a blanket block breaks the platform. Only a client_id-specific rule helps.
- IP allow-listing on the storefront — many teams allow-list corporate IPs on Backoffice but leave
/authorizationserver/open because integrations run from many CIDRs. - MFA / SSO — irrelevant. This is machine-to-machine OAuth2 client_credentials; there is no interactive login to protect.
- Network segmentation — a Commerce storefront is by definition internet-facing; you cannot segment your customers away from it.
Crowdsourced verification payload.
Run from an auditor workstation with network reachability to the Commerce Cloud storefront. Invoke as ./check-cve-2026-44761.sh https://shop.example.com <sample_client_id> <sample_client_secret>, supplying the sample client_id/secret from the SAP Security Note. No target-side privileges required — this is a black-box check against the public token endpoint.
#!/usr/bin/env bash
# noisgate check for CVE-2026-44761
# Detects whether SAP Commerce Cloud sample OAuth2 client is still active.
# Usage: ./check-cve-2026-44761.sh <base_url> <sample_client_id> <sample_client_secret>
# Exit 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN
set -u
if [ "$#" -ne 3 ]; then
echo "UNKNOWN: usage $0 <base_url> <client_id> <client_secret>" >&2
exit 2
fi
BASE="${1%/}"
CID="$2"
CSEC="$3"
ENDPOINT="${BASE}/authorizationserver/oauth/token"
RESP=$(curl -sk -o /tmp/noisgate_44761.json -w "%{http_code}" \
-X POST "$ENDPOINT" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=client_credentials&client_id=${CID}&client_secret=${CSEC}") || {
echo "UNKNOWN: network failure contacting $ENDPOINT"
exit 2
}
case "$RESP" in
200)
if grep -q '"access_token"' /tmp/noisgate_44761.json; then
echo "VULNERABLE: sample OAuth2 client issued a valid access token at $ENDPOINT"
rm -f /tmp/noisgate_44761.json
exit 1
fi
echo "UNKNOWN: HTTP 200 without access_token — inspect response"
exit 2
;;
400|401)
echo "PATCHED: token endpoint rejected sample client credentials (HTTP $RESP)"
rm -f /tmp/noisgate_44761.json
exit 0
;;
404)
echo "UNKNOWN: token endpoint not found — verify base URL"
exit 2
;;
*)
echo "UNKNOWN: unexpected HTTP $RESP from $ENDPOINT"
exit 2
;;
esac
If you remember one thing.
oauthclientdetails today — this is your noisgate mitigation SLA of ≤3 days for CRITICAL, and given the credentials are literally published on SAP's help portal, aim for hours not days; (3) grep 90 days of access logs for the sample client_id and treat any external hit as a confirmed breach; (4) schedule the SAP July 2026 Security Patch across the fleet within the noisgate remediation SLA of ≤90 days for CRITICAL. Do not wait for KEV listing — the exploit is a two-line curl and the credentials are already public.Sources
- SAP Security Patch Day — July 2026 (vendor)
- BleepingComputer — SAP fixes critical flaws in NetWeaver and Commerce Cloud
- CSA Singapore advisory AL-2026-075
- Cryptika — SAP Security Update July 2026
- entplexit — SAP Security News 07/2026
- heise — SAP Patchday July 2026
- SAP Help Portal — Configuring OAuth Clients in Commerce
- SAP KBA 3641255 — Moving to New OAuth Implementation in Commerce Cloud JDK 21
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.