CVE-2026-75650: Adobe Commerce Unauthenticated RCE — Detection, Patching, and Hardening Guide

Adobe's latest security release fixes more than 170 vulnerabilities across its product portfolio — but the one that should be keeping e-commerce defenders up at night is CVE-2026-75650, a defect in Adobe Commerce (formerly Magento) that allows unauthenticated attackers to execute arbitrary code on the underlying server. If you run Adobe Commerce or Magento Open Source, this is a drop-everything patch.

Why This One Matters

Unauthenticated remote code execution against an internet-facing e-commerce platform is the worst-case combination of attack surface and impact. Adobe Commerce instances process payment data, store customer PII, and — because they run as full PHP web applications — provide a direct path from a single crafted HTTP request to code execution on the host.

We've seen this movie before. Commerce/Magento has a long history of being targeted for exactly this class of bug: web skimmers (Magecart), cryptominers, and webshells planted for persistence. When an unauthenticated RCE drops for this platform, threat actors weaponize it in days, not weeks. Mass scanning typically begins within 24–72 hours of patch release as actors diff the patches and build working exploits.

Assume that if your instance was reachable from the internet before patching, it was probed.

Technical Analysis

Affected Products

• Adobe Commerce (on-premise and cloud-hosted, where the underlying application layer is customer-patched)
• Magento Open Source — the same codebase lineage, typically affected by the same defect

Per Adobe's security bulletin (APSB), administrators should consult the advisory for the exact supported version trains and corresponding hotfix builds. Treat any unpatched instance as vulnerable.

The Vulnerability: CVE-2026-75650

What we know from the disclosure:

• Attack vector: Network — exploitation occurs over HTTP/HTTPS against the storefront or admin interface
• Authentication: None required. The attacker does not need valid credentials, a session, or any prior foothold
• Impact: Arbitrary code execution in the context of the web server / PHP-FPM process (typically www-data, apache, or nginx)

While full technical details are being withheld to slow weaponization, the exploitation pattern for this class of Commerce RCE is well understood from a defender's perspective:

1. The attacker sends one or more crafted requests to a vulnerable endpoint — often targeting the REST API, checkout flow, or admin panel routes (e.g., /rest/V1/, /admin/, or custom module endpoints)
2. Input handling fails (deserialization, template injection, or improper sanitization in a request handler)
3. Attacker-controlled PHP executes, typically used to drop a webshell into a web-accessible directory (pub/, var/, media/, or the document root)
4. Post-exploitation follows: credential harvesting from app/etc/env.php, payment skimmer injection, or pivot into internal infrastructure

Exploitation Status

At time of writing, public proof-of-concept code has not been widely observed — but that is not a reason to wait. Unauthenticated RCE in a widely deployed commerce platform is a guaranteed target for both opportunistic scanners and organized groups. Patch first, hunt second, and assume scanning is already underway.

Detection & Response

The most reliable detection strategy here is behavioral: PHP/web-server processes spawning unexpected child processes, unexpected file writes into web-served directories, and anomalous request patterns against the application. These catch exploitation of CVE-2026-75650 and the inevitable follow-on webshells, regardless of the exact exploit string.

Sigma Rules

---
title: Adobe Commerce Web Server Spawning Shell or System Commands
id: 3f8a1c94-7b2e-4d51-9f38-a1c5e2b7d901
status: experimental
description: Detects PHP-FPM, Apache, or Nginx worker processes spawning shells or common post-exploitation utilities — a strong indicator of RCE exploitation against Adobe Commerce / Magento (e.g., CVE-2026-75650).
references:
  - https://www.securityweek.com/adobe-patches-over-170-vulnerabilities-including-commerce-zero-day/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/04/08
tags:
  - attack.execution
  - attack.t1059
  - attack.t1190
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/php-fpm'
      - '/php'
      - '/apache2'
      - '/httpd'
      - '/nginx'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/python'
      - '/python3'
      - '/perl'
      - '/base64'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate Magento cron jobs and indexing tasks invoking system utilities (tune by parent command line)
  - Deployment pipelines running under the web user
level: high
---
title: Webshell Dropped in Adobe Commerce Web-Accessible Directory
id: 8e2b5d17-4c6a-4f83-b7a2-9d1e3f5c8042
status: experimental
description: Detects creation of PHP files in web-served Adobe Commerce directories such as pub/, media/, and var/ — a classic post-exploitation artifact of Commerce RCE used to establish webshell persistence.
references:
  - https://www.securityweek.com/adobe-patches-over-170-vulnerabilities-including-commerce-zero-day/
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/04/08
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: linux
detection:
  selection_path:
    TargetFilename|contains:
      - '/pub/'
      - '/media/'
      - '/var/importexport/'
      - '/var/import/'
      - '/pub/static/'
  selection_ext:
    TargetFilename|endswith:
      - '.php'
      - '.phtml'
      - '.phar'
  condition: selection_path and selection_ext
falsepositives:
  - Extension/module installation via Composer or the Commerce marketplace (filter known deployment windows and the deploy user)
  - Legitimate generated static content (should not contain executable PHP entry points in these paths)
level: high
---
title: Suspicious Requests Targeting Adobe Commerce API and Admin Endpoints
id: c47d9f02-1a8b-4e65-93ac-2b6d8e1f7503
status: experimental
description: Detects HTTP request patterns consistent with scanning and exploitation attempts against Adobe Commerce REST API, admin routes, and setup endpoints following public disclosure of an unauthenticated RCE.
references:
  - https://www.securityweek.com/adobe-patches-over-170-vulnerabilities-including-commerce-zero-day/
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/08
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection_uri:
    c-uri|contains:
      - '/rest/V1/'
      - '/rest/default/V1/'
      - '/setup/'
      - '/downloader/'
      - '/admin/'
  selection_method:
    cs-method:
      - POST
      - PUT
  selection_status:
    sc-status:
      - 200
      - 302
      - 500
  condition: selection_uri and selection_method and selection_status
falsepositives:
  - Legitimate storefront API traffic (the /rest/V1/ paths are heavily used by real customers — alert on volumetric anomalies, unusual source IPs, or POSTs to /setup/ and /downloader/, which should never be exposed)
level: medium

A note on tuning: the third rule is intentionally the noisiest of the set. The /rest/V1/ endpoints are the Commerce API backbone and will fire constantly in production. The high-value signals there are POSTs to /setup/ or /downloader/ paths (which should be blocked at the edge entirely) and bursts of API traffic from single source IPs or known VPS/Tor egress ranges. Tune accordingly, or scope that rule to setup/downloader paths only in high-volume environments.

KQL (Microsoft Sentinel)

If your Commerce hosts ship Syslog/CEF to Sentinel, this hunt surfaces web-server processes spawning shells and suspect child process trees. The second query hunts web request logs ingested via CommonSecurityLog or a custom log table for probing of sensitive Commerce paths.

// Hunt 1: PHP/web-server processes spawning shells or tooling (post-exploitation indicator)
Syslog
| where TimeGenerated > ago(14d)
| where ProcessName in~ ("php-fpm", "php", "apache2", "httpd", "nginx", "sh", "bash", "dash", "curl", "wget", "nc", "ncat", "python", "python3", "perl")
| where SyslogMessage has_any ("sh -c", "/bin/bash", "/bin/sh", "base64 -d", "curl http", "wget http")
| project TimeGenerated, Computer, ProcessName, SyslogMessage, SeverityLevel
| order by TimeGenerated desc

// Hunt 2: Requests to Commerce setup/downloader/admin paths from external sources
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where RequestURL has_any ("/setup/", "/downloader/", "/admin/", "/rest/V1/integration/admin/token")
| where RequestMethod in ("POST", "PUT")
| summarize Requests = count(), UniqueURLs = dcount(RequestURL), Statuses = make_set(ResponseCode, 10) by SourceIP, RequestURL, bin(TimeGenerated, 1h)
| order by Requests desc

// Hunt 3: Device-level process anomalies on Linux Commerce hosts (if MDE is deployed)
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName has_any ("php-fpm", "php", "apache2", "nginx", "httpd")
| where FileName in~ ("sh", "bash", "dash", "curl", "wget", "nc", "ncat", "python3", "perl", "base64")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, AccountName
| order by TimeGenerated desc

Velociraptor VQL

Use this artifact to sweep Commerce hosts for recently created PHP files in web-accessible directories — the standard webshell landing zones. Run it across your fleet immediately, then scope to the window between patch disclosure and patch application.

-- Hunt for recently created PHP/webshell files in Adobe Commerce web directories
SELECT FullPath, Size, Mtime, Ctime, Mode
FROM glob(globs=[
    '/var/www/**/pub/**/*.php',
    '/var/www/**/pub/**/*.phtml',
    '/var/www/**/media/**/*.php',
    '/var/www/**/var/importexport/**/*.php',
    '/var/www/**/var/import/**/*.php',
    '/srv/**/pub/**/*.php',
    '/usr/share/nginx/**/pub/**/*.php'
])
WHERE Mtime > now() - 1209600
ORDER BY Mtime DESC

For a second pass, combine with pslist() filtered on php-fpm/apache2 parent processes with shell children, and review netstat() output for the web-server user holding unexpected outbound connections — a common tell for reverse shells and skimmer exfiltration callbacks.

Verification and Hardening Script

The following Bash script verifies your Commerce version against the patch, audits web directories for recently modified PHP files, checks for rogue crons under the web user, and confirms dangerous paths are blocked at the reverse proxy. Run it on every Commerce node.

#!/bin/bash
# CVE-2026-75650 verification & hygiene audit for Adobe Commerce / Magento
REPORT="/tmp/commerce_audit_$(date +%Y%m%d_%H%M%S).txt"
DOCROOTS=("/var/www/html" "/srv/magento" "/usr/share/nginx/html")

echo "=== Adobe Commerce Security Audit - $(date) ===" | tee "$REPORT"

# 1. Report installed Commerce version (compare against Adobe APSB advisory)
echo -e "\n[1] Installed Commerce version:" | tee -a "$REPORT"
for root in "${DOCROOTS[@]}"; do
  if [ -f "$root/bin/magento" ]; then
    php "$root/bin/magento" --version 2>/dev/null | tee -a "$REPORT"
  fi
done
echo "    -> Verify against the fixed versions listed in the Adobe APSB bulletin" | tee -a "$REPORT"

# 2. Find PHP files modified in the last 14 days in web-served directories
echo -e "\n[2] PHP files modified in last 14 days under pub/, media/, var/:" | tee -a "$REPORT"
for root in "${DOCROOTS[@]}"; do
  find "$root/pub" "$root/media" "$root/var/importexport" "$root/var/import" \
    -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \) \
    -mtime -14 2>/dev/null | tee -a "$REPORT"
done

# 3. Review crontab for the web server user (common persistence vector)
echo -e "\n[3] Crontab entries for www-data / nginx / apache:" | tee -a "$REPORT"
for user in www-data nginx apache; do
  crontab -u "$user" -l 2>/dev/null | tee -a "$REPORT"
done

# 4. Flag world-writable PHP files in the document root
echo -e "\n[4] World-writable PHP files:" | tee -a "$REPORT"
for root in "${DOCROOTS[@]}"; do
  find "$root" -type f -name "*.php" -perm -o+w 2>/dev/null | tee -a "$REPORT"
done

# 5. Check that /setup/ and /downloader/ return 403/404 externally
echo -e "\n[5] Edge exposure of setup/downloader paths:" | tee -a "$REPORT"
for path in /setup/ /downloader/; do
  code=$(curl -sk -o /dev/null -w "%{http_code}" "https://localhost${path}" --max-time 5)
  echo "    ${path} -> HTTP ${code} (must be 403 or 404)" | tee -a "$REPORT"
done

echo -e "\nAudit complete. Report saved to $REPORT" | tee -a "$REPORT"

Remediation

1. Patch immediately. Apply the hotfix referenced in Adobe's security bulletin (APSB) for your Commerce/Magento Open Source version train. Adobe Commerce on Cloud customers should confirm with Adobe whether the managed infrastructure layer has been patched on their behalf; on-premise customers own this entirely. Official advisories live at helpx.adobe.com/security.html and the Adobe Security Bulletin index.
2. Treat patching as the start of IR, not the end. Because this flaw is unauthenticated and the platform is internet-facing, assume pre-patch exposure. Hunt with the queries above across at least the last 30 days. Check app/etc/env.php modification times — stolen DB and admin credentials from that file are the first thing attackers grab.
3. Rotate credentials on any instance that was unpatched and internet-reachable: database credentials, admin accounts, API/integration tokens (/rest/V1/integration/ tokens), encryption keys, and any downstream secrets reachable from the host.
4. Block dangerous paths at the edge. /setup/, /downloader/, and direct access to /var/, /app/, and /vendor/ should return 403 at your WAF/reverse proxy. The admin panel should be IP-allowlisted or behind VPN/ZTNA. If your WAF supports it, deploy virtual-patching signatures for Commerce CVE-2026-75650 as interim coverage.
5. File integrity monitoring on web roots. Any PHP file created in pub/, media/, or var/importexport/ outside a deployment window should page the on-call. This single control catches the overwhelming majority of Commerce post-exploitation.
6. Restrict the web user. The PHP-FPM user should have no write access outside designated directories, no sudo, and no outbound network access except explicitly required destinations (payment gateways, Adobe services). Egress filtering on commerce hosts breaks reverse shells and skimmer exfil dead.
7. Segment and monitor. Commerce hosts should sit in a DMZ segment with no direct path to internal AD/production networks. Ensure web access logs, PHP-FPM logs, and process execution telemetry (auditd/eBPF/MDE) are flowing to your SIEM before the next bulletin drops — Adobe ships large patch trains like this one regularly, and Commerce is a perennial target.

If you find evidence of exploitation — unexpected PHP files, web-user shells, or anomalies in env.php timestamps — treat it as a full incident: isolate the host, capture forensic images before remediation, and engage your IR retainer. Payment-processing environments carry PCI-DSS implications that change your notification obligations the moment cardholder data is in scope.

Related Resources

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