SAP Commerce Cloud Unauthenticated RCE Under Active Exploitation — Emergency Patching, Detection, and Response Guide

The window between patch release and active exploitation has collapsed — again. Threat intelligence firm Defused has confirmed that a maximum-severity unauthenticated remote code execution vulnerability in SAP Commerce Cloud (formerly Hybris) is being targeted in attacks just three days after SAP shipped the fix. If your organization operates an SAP Commerce storefront — particularly one exposed to the internet for customer-facing e-commerce — you are in the blast radius of an attack that requires no credentials, no user interaction, and no insider knowledge.

This is not a theoretical exercise. When a CVSS 10.0-class unauthenticated RCE in an enterprise commerce platform sees exploitation attempts within 72 hours of patch Tuesday, it means threat actors are diffing the patch, weaponizing the vulnerable code path, and scanning for exposed instances at scale. Every unpatched, internet-reachable SAP Commerce Cloud instance should be treated as a target right now.

SAP Commerce Cloud processes payment data, customer PII, and order workflows — which means a successful compromise isn't just an infrastructure problem. It's a PCI-DSS scope violation, a breach notification event, and potentially a Magecart-style payment skimming operation waiting to happen.

Technical Analysis

Affected Product

• Product: SAP Commerce Cloud (SAP Commerce, formerly Hybris)
• Deployment models: Self-managed SAP Commerce instances and SAP Commerce Cloud (managed) environments where customers control the patch cadence
• Vulnerability class: Unauthenticated remote code execution (pre-auth RCE)
• Severity: Maximum (CVSS 10.0-class)
• Exploitation status: Confirmed active exploitation in the wild per Defused threat intelligence, beginning approximately three days after patch availability

SAP Commerce is a Java-based platform typically deployed on embedded Tomcat or standalone application servers, fronted by Apache or nginx reverse proxies, and heavily customized per deployment. The unauthenticated nature of this flaw is what makes it catastrophic: an attacker can reach the vulnerable endpoint over HTTP/HTTPS from the internet with no session, no token, and no credentials.

How the Attack Works (Defender's View)

While SAP has not published deep technical detail on the vulnerable code path (standard practice for SAP Security Notes), the observable post-exploitation pattern for Java application server RCEs like this is consistent and well-understood:

1. Reconnaissance: Attackers scan for internet-facing SAP Commerce instances, typically fingerprinting on storefront endpoints, /medias/, /-/occ/ (Omni Commerce Connect API), or accelerator-specific paths.
2. Exploitation: A crafted HTTP request — usually POST with a malicious serialized or template-driven payload — hits the vulnerable unauthenticated endpoint.
3. Code execution: The payload executes in the context of the Java/Tomcat process. Expect to see the java or java.exe process spawning cmd.exe, powershell.exe, /bin/sh, /bin/bash, curl, or wget.
4. Persistence: JSP webshells are the classic drop — attackers write a .jsp file into a web-accessible directory within the Hybris webroot (hybris/bin/platform/tomcat/webapps/...) to survive restarts and enable recurring access.
5. Post-exploitation: Outbound C2 connections from the application server, credential harvesting from local.properties/configuration files, and lateral movement into back-office systems.

Why the 72-Hour Exploitation Window Matters

Patch diffing of SAP Security Notes is a mature discipline. Enterprise software with predictable monthly patch cadences gives attackers a reliable delivery schedule of new weapons. The takeaway for defenders: for internet-facing SAP products, your patch SLA for maximum-severity notes is measured in hours to days, not weeks. If your change management process requires a two-week CAB cycle for a CVSS 10.0 pre-auth RCE on a public e-commerce tier, your process is the vulnerability.

Detection & Response

The most reliable detections for this class of attack focus on post-exploitation behavior rather than the exploit request itself, since exact vulnerable URI patterns may vary by deployment. The highest-fidelity signals are: the Java/Tomcat process spawning shells or downloaders, and JSP files appearing in web-accessible directories.

---
title: SAP Commerce Java Process Spawning Shell or Script Interpreter
id: 8f2c1a94-3b6d-4e7f-a9c2-5d1e0f7b8a34
status: experimental
description: Detects Java/Tomcat processes associated with SAP Commerce spawning command shells, script interpreters, or download tools — a high-fidelity indicator of successful exploitation of an application-layer RCE such as the SAP Commerce Cloud unauthenticated code execution flaw.
references:
  - https://www.bleepingcomputer.com/news/security/max-severity-sap-commerce-cloud-flaw-now-targeted-in-attacks/
  - https://attack.mitre.org/techniques/T1190/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/02/15
tags:
  - attack.initial_access
  - attack.t1190
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
detection:
  selection_parent:
    ParentImage|endswith:
      - '\java.exe'
      - '\javaw.exe'
      - '\tomcat.exe'
      - '/java'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\curl.exe'
      - '\certutil.exe'
      - '/bin/sh'
      - '/bin/bash'
      - '/usr/bin/curl'
      - '/usr/bin/wget'
      - '/usr/bin/python'
  condition: selection_parent and selection_child
falsepositives:
  - SAP Commerce integrations that legitimately invoke external utilities (rare; verify per deployment)
  - Monitoring agents co-located on the application server
level: high
---
title: JSP Webshell File Creation in SAP Commerce Webroot
id: 3d7e5b21-9a4f-4c68-b1d3-6e2f8c9a4b51
status: experimental
description: Detects creation of JSP files in SAP Commerce Tomcat webapps directories, consistent with webshell deployment following exploitation of the SAP Commerce Cloud unauthenticated RCE. Baseline your environment first — SAP deployments legitimately contain JSP files, so this rule targets NEW file creation events in webroot paths.
references:
  - https://www.bleepingcomputer.com/news/security/max-severity-sap-commerce-cloud-flaw-now-targeted-in-attacks/
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/02/15
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
detection:
  selection_path:
    TargetFilename|contains:
      - 'hybris\\bin\\platform\\tomcat\\webapps'
      - 'hybris/bin/platform/tomcat/webapps'
      - '\\webapps\\ROOT'
      - '/webapps/ROOT'
  selection_ext:
    TargetFilename|endswith:
      - '.jsp'
      - '.jspx'
  condition: selection_path and selection_ext
falsepositives:
  - Legitimate SAP Commerce deployments and hot folder updates — restrict alerting to creation events outside of deployment windows and by the java/tomcat process where telemetry allows
level: high

// Hunt: Java/Tomcat spawning shells or download tools — SAP Commerce RCE post-exploitation
// Microsoft Sentinel / Defender XDR — last 14 days
let suspicious_children = dynamic(["cmd.exe","powershell.exe","pwsh.exe","wscript.exe","cscript.exe","curl.exe","certutil.exe","bash","sh","wget","curl","python"]);
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName in~ ("java.exe","javaw.exe","tomcat.exe","java")
| where FileName in~ (suspicious_children)
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
          FileName, ProcessCommandLine, AccountName, InitiatingProcessAccountName
| order by TimeGenerated desc;
// Supplementary: outbound network connections from the Java/Tomcat process to rare external IPs
DeviceNetworkEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName in~ ("java.exe","javaw.exe","tomcat.exe","java")
| where RemoteIPType == "Public"
| summarize ConnectionCount = count(), DistinctDestinations = dcount(RemoteIP)
    by DeviceName, RemoteIP, RemotePort, InitiatingProcessFileName
| where ConnectionCount < 20  // low-and-slow C2 candidates; tune against your baseline
| order by DeviceName asc;

-- Velociraptor artifact: SAP Commerce post-exploitation triage
-- 1) Suspicious child processes of java/tomcat AND 2) recent JSP writes in webroot
LET procs = SELECT Pid, Name, CommandLine, Exe, Username, CreateTime, Ppid
FROM pslist()
WHERE Name =~ '(?i)java|tomcat'

LET children = SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Ppid in (SELECT Pid FROM procs)
  AND Name =~ '(?i)cmd|powershell|pwsh|sh$|bash|curl|wget|certutil|wscript|cscript'

SELECT * FROM children

// JSP files written in the last 7 days under SAP Commerce webapps paths
SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=['C:/hybris/**/webapps/**/*.jsp', '/opt/sap/hybris/**/webapps/**/*.jsp'])
WHERE Mtime > (now() - 7 * 24 * 3600)
ORDER BY Mtime DESC

#!/bin/bash
# SAP Commerce Cloud — emergency triage and hardening verification
# Run on the application server (adjust HYBRIS_HOME as needed)

HYBRIS_HOME="/opt/sap/hybris"

# 1) Find JSP files modified in the last 7 days (webshell candidates)
echo "[+] Recent JSP files in webapps directories:"
find "$HYBRIS_HOME" -path "*/webapps/*" -name "*.jsp" -mtime -7 -ls 2>/dev/null

# 2) Look for suspicious child processes of the Java/Tomcat process
JAVA_PID=$(pgrep -f 'hybris|tomcat' | head -20)
echo "[+] Child processes of Java/Tomcat:"
for pid in $JAVA_PID; do
  ps --ppid "$pid" -o pid,ppid,user,cmd 2>/dev/null
done

# 3) Check for outbound connections from the Java process (C2 candidates)
echo "[+] Outbound connections from application processes:"
ss -tnp 2>/dev/null | grep -iE 'java|tomcat' | grep -vE '127.0.0.1|::1'

# 4) Audit access logs for anomalous unauthenticated POST requests
echo "[+] High-volume POST sources in Tomcat access logs (last 3 days):"
find "$HYBRIS_HOME" -name "localhost_access_log*" -mtime -3 -exec \
  awk '$6 ~ /POST/ {print $1}' {} \; 2>/dev/null | sort | uniq -c | sort -rn | head -20

# 5) Verify current SAP Commerce patch level against the latest SAP Security Note
#    (confirm via SAP for Me -> Security Notes for your exact release)
echo "[+] Current platform version marker:"
grep -r "version" "$HYBRIS_HOME/bin/platform/project.properties" 2>/dev/null | head -5

Remediation

1. Patch immediately — this is an emergency change. Apply the SAP Security Note addressing this maximum-severity SAP Commerce Cloud vulnerability as published on SAP's most recent Security Patch Day. Retrieve the applicable note for your exact release from SAP for Me (support.sap.com / me.sap.com) under Security Patch Day notes for SAP Commerce. Do not wait for the next maintenance window; exploitation is confirmed and ongoing.

2. If you cannot patch within hours, reduce exposure now:

• Place the vulnerable application tier behind a WAF with virtual patching rules blocking anomalous POST bodies to unauthenticated endpoints.
• Restrict direct internet access to the SAP Commerce application tier; expose only the storefront front-end through a hardened reverse proxy.
• Block outbound internet egress from the application server except to an explicit allowlist (SAP update services, payment gateways). This breaks C2 and payload staging even if exploitation succeeds.

3. Hunt before you patch. Because exploitation began days ago, patching alone is not sufficient — you must assume possible pre-patch compromise. Run the detection content above against at least the last 14 days of telemetry. Specifically look for: Java/Tomcat child processes, unexpected JSP files, new local accounts, and outbound connections from the app tier to non-business destinations.

4. If compromise is confirmed: isolate the host, preserve memory and disk images before remediation, rotate all credentials stored in SAP Commerce configuration (database credentials, API keys, payment gateway secrets), and assess PCI-DSS breach notification obligations — storefront code execution frequently leads to payment skimming.

5. Fix the process, not just the server. Establish an emergency patch lane for CVSS 9.0+ unauthenticated flaws in internet-facing systems with a 24–72 hour SLA. Subscribe to SAP Security Patch Day notifications and threat intel feeds (such as Defused) that flag exploitation-in-the-wild so you are not learning about attacks from the news cycle.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub