← Back to Feed CACHED · 2026-10-08 06:51:56 · CACHE_KEY CVE-2026-75650
CVE-2026-75650 · CWE-1336 · Disclosed 2026-09-07

Adobe Commerce / Magento Open Source Server-Side Template Injection (StyleSmuggler) Unauthenticated RCE

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

Someone left the back door of every mall store unlocked, and burglars have been walking in for a month

CVE-2026-75650 — nicknamed StyleSmuggler — is a server-side template injection (SSTI) vulnerability in Adobe Commerce (2.4.4–2.4.9), Adobe Commerce B2B (1.3.3–1.5.3), and Magento Open Source (2.4.6–2.4.9). An unauthenticated attacker sends a crafted Store HTTP header to the GraphQL endpoint, injecting PHP code into var/log/system.log. A second set of requests creates a guest cart with a smuggled {{block}} template directive in the billing address, then triggers a declined payment via /paypal/transparent/response/. The resulting 'Payment Transaction Failed Reminder' email render chains through Magento\Email\Block\Adminhtml\Template\Preview → S3Client → ArrayScanner::collectEntities → include on the poisoned log — executing the attacker's PHP in the Magento process context. No authentication, no user interaction, no non-default configuration required.

Adobe rated this CVSS 10.0 / CRITICAL and the vendor score is exactly right. Every element of the vector — network-accessible, low complexity, no privileges, no user interaction, scope changed, full CIA impact — is present in the real attack chain. The Scope: Changed rating is justified because the SSTI in the template engine gives OS-level code execution beyond the vulnerable component. There are zero friction points: GraphQL is enabled by default, guest checkout is standard for e-commerce, logging is default, email rendering is automatic. The attack targets internet-facing storefronts by design. This is one of the rare CVEs where the vendor's 10.0 is genuinely earned.

"Unauth RCE zero-day hitting every Adobe Commerce and Magento storefront — patch within hours, not days."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Log poisoning via GraphQL

Attacker sends an unauthenticated POST /graphql request with a malicious Store HTTP header containing PHP code (e.g., <?php system('id'); ?>). Magento's store resolver rejects the unrecognized store code and the error handler writes the raw header value — including the PHP — unescaped into var/log/system.log. No authentication or session is needed. The GraphQL endpoint is enabled by default in all affected versions.
Conditions required:
  • Internet-facing Magento/Adobe Commerce instance
  • GraphQL endpoint enabled (default)
  • Standard Magento logging configuration (default)
Where this breaks in practice:
  • None — every production Magento storefront meets these conditions out of the box
Detection/coverage: WAF rules detecting PHP opening tags (<?php, <?=) in the Store header. Akamai App & API Protector CMD Injection rules, Fastly virtual patch, and CrowdSec rules all cover this vector natively.
STEP 02

Guest cart creation + SSTI directive injection

Attacker creates a guest cart via GraphQL and sets the billing address with a {{block}} template directive smuggled into the styles/address fields. The directive exploits a str_replace-based filter signing mechanism that fails to neutralize block syntax when embedded within style properties. This plants the SSTI payload in the cart's billing address record in the database, waiting for template rendering.
Conditions required:
  • Guest checkout enabled (standard for any e-commerce site)
  • Cart creation API accessible without authentication (default)
Where this breaks in practice:
  • None — guest checkout is a core Magento feature; disabling it breaks the storefront
Detection/coverage: Input validation monitoring on address fields. Anomalous {{block}} or {{var}} syntax in cart address data could be flagged by custom application-layer monitoring.
STEP 03

Declined payment triggers email render

Attacker submits a payment payload designed to fail through the /paypal/transparent/response/ endpoint, invoking handlePayflowProResponse. The declined transaction triggers Magento's built-in 'Payment Transaction Failed Reminder' email notification. This email rendering happens server-side — no human needs to open or receive the email for the attack to succeed. The template engine processes the smuggled directive during email composition.
Conditions required:
  • Payment gateway configured (standard for commerce sites)
  • Transaction failure email enabled (default Magento behavior)
Where this breaks in practice:
  • Minimal — any configured payment method works; even a misconfigured gateway produces the failure path
Detection/coverage: Anomalous payment failure rates from a single IP. Burst of 'Payment Transaction Failed' emails in the admin notification queue.
STEP 04

Template engine chains to include poisoned log

During email rendering, the smuggled {{block}} directive instantiates Magento\Email\Block\Adminhtml\Template\Preview. The gadget chain continues through the AWS S3Client class and ArrayScanner::collectEntities, which performs a PHP include on the path pointed to by the styles.first property — which the attacker has set to var/log/system.log. The PHP code injected in Step 1 executes in the context of the Magento web server process (typically www-data or apache).
Conditions required:
  • Template engine processing enabled (default)
  • Poisoned log file from Step 1 still on disk (logs persist by default)
Where this breaks in practice:
  • None — this is standard Magento template processing; there is no opt-out
Detection/coverage: File integrity monitoring (FIM) on var/log/system.log for PHP tags. Runtime application self-protection (RASP) detecting include calls on log files. Anomalous Laminas\Loader\Exception\InvalidArgumentException in exception logs.
STEP 05

Post-exploitation: backdoor and webshell deployment

With PHP execution achieved, attackers deploy persistent implants. Observed payloads include a 1.9 MB statically-linked Rust backdoor (x86-64 and ARM64) disguised as kernel threads ([kworker/u:8:0], fc-cache, chronyd) that beacons over UDP/123 using NTP-shaped traffic to C2 at 185.157.160.251. PHP webshells are dropped in pub/media/, and gs-netcat and WraithC2 RAT instances provide redundant access. Persistence is maintained via cron jobs restarting the implant every 5 minutes.
Conditions required:
  • Successful code execution from Step 4
  • Write access to web-accessible directories (granted by PHP process)
Where this breaks in practice:
  • EDR on the host could detect the Rust binary or anomalous cron entries, but many Magento hosts run without endpoint agents
Detection/coverage: Process monitoring for unexpected binaries masquerading as kernel threads. File integrity monitoring on pub/media/. Cron audit for entries matching implant restart patterns. Network monitoring for UDP/123 traffic to non-NTP destinations.
03 · Compensating Control

1
CRITICAL 10.0→HIGH 7.5
SEVERITY REDUCED
Deploy WAF virtual patch blocking PHP tags in Store header and GraphQL input — Akamai App & API Protector, Fastly, and CrowdSec all ship virtual patches that block the primary exploitation vectors (PHP opening tags in the Store header and template directives in GraphQL parameters). Deploy within hours as an interim measure under the noisgate mitigation SLA for CRITICAL (≤3 days) while scheduling the full hotfix. This breaks Step 1 (log poisoning) of the attack chain.
2
CRITICAL 10.0→LOW 2.0
SEVERITY REDUCED
Apply hotfix VULN-39341 (APSB26-146) — The vendor patch sanitizes template directive processing and prevents the include gadget chain. Apply immediately — this is a KEV-listed actively exploited zero-day, so the noisgate mitigation SLA override applies: patch within hours, not days. The hotfix alone is necessary but not sufficient; credential rotation must follow.
3
CRITICAL 10.0→IGNORE 0.0
SEVERITY REDUCED
Rotate Magento encryption key and all protected credentials — Post-patch, rotate the Magento encryption key, all payment gateway API keys, database passwords, REST/SOAP/GraphQL integration tokens, OAuth secrets, SSH/deploy keys, and extension API keys. If the storefront was unpatched between September 4 and your patch date, assume compromise and perform forensic triage. Adobe's guidance is eight steps, not one. Deploy within 3 days per noisgate mitigation SLA for CRITICAL.
4
CRITICAL 10.0→MEDIUM 5.0
SEVERITY REDUCED
Run forensic triage for post-exploitation indicators — Search for: Rust binaries masquerading as [kworker/u:8:0], fc-cache, or chronyd; PHP files under pub/media/; cron entries restarting implants every 5 minutes; Laminas\Loader\Exception\InvalidArgumentException in exception logs; anomalous UDP/123 traffic to non-NTP destinations; gs-netcat or WraithC2 processes. Use Sansec's eComscan or manual triage. Deploy within 3 days.
5
CRITICAL 10.0→MEDIUM 4.0
SEVERITY REDUCED
Disable GraphQL endpoint if not required — If the storefront does not use GraphQL for its frontend, disable the endpoint entirely via web server configuration (deny on /graphql). This breaks Step 1 of the chain. However, many modern Magento frontends (PWA Studio, headless) require GraphQL, making this impractical for most deployments.
What doesn't work
  • IP-based blocking alone — CrowdSec data shows only 57 of 410 attacking IPs appeared on existing blocklists; 155 IPs were residential proxies that rotate too quickly for IP reputation to be effective.
  • Disabling guest checkout — While this would theoretically break Step 2 (guest cart creation), it is commercially unacceptable for virtually all e-commerce sites and the attacker may be able to create an account and achieve the same cart injection as an authenticated user.
  • Disabling transactional emails — This would prevent Step 3's email rendering trigger, but it breaks order confirmations, shipping notifications, and password resets — functionally disabling the storefront.
  • Network segmentation alone — The vulnerable endpoint is the storefront itself, which must be internet-facing to serve customers. Segmentation cannot prevent the initial exploitation; it can only limit lateral movement after compromise.
04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationConfirmed active exploitation since September 4, 2026 (3 days before patch). Multiple independent threat actor groups observed. Sansec first detected exploitation at 22:20 UTC on Sept 4. CrowdSec recorded 2,760 signals from 500+ unique IPs in the first week (Sept 9–13), peaking at 1,303 signals on Sept 11. 65% of attacking IPs are US-based; 155 classified as residential proxies (Comcast, Charter, Verizon). Malware deployed includes Rust backdoor (v2.1.5), PHP webshells, gs-netcat, and WraithC2 RAT.
Proof-of-concept availabilityPublic PoC available. abraxas/CVE-2026-75650 on GitHub — a fully functional Python 3 exploit with Docker lab setup targeting POST /graphql. Also listed in SecureWithUmer/CVE-2026-PoCs and XZ1r0/cve-2026-poc-collection. A Nuclei template has been submitted to the official nuclei-templates repository and tested against Magento v2.4.9 and v2.4.7-p2.
EPSS0.03949 (3.9%) — while not in the top percentile by EPSS alone, this significantly understates real-world risk given confirmed mass exploitation and KEV listing. EPSS is a lagging indicator here.
CISA KEV statusListed on September 8, 2026. Federal remediation due date: September 11, 2026 (72 hours). Forensic triage required. Ransomware campaign use: unknown at time of listing. CISA alert.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — 10.0 CRITICAL. Every metric is at its worst-case value. AV:N = reachable over the internet. AC:L = no race conditions or special config. PR:N = no authentication. UI:N = no victim interaction. S:C = SSTI in template engine gives OS-level code execution beyond the vulnerable component. C:H/I:H/A:H = full confidentiality, integrity, and availability impact.
Affected versionsAdobe Commerce and Magento Open Source 2.4.4 through 2.4.9 (all patch levels up to and including 2.4.8-p5, 2.4.7-p10, 2.4.6-p15). Adobe Commerce B2B 1.3.3 through 1.5.3. Older branches (2.2, 2.3, 2.4.0–2.4.3) are EOL but community backports exist.
Fixed versionsHotfix VULN-39341 via security bulletin APSB26-146, released September 7, 2026. Compatible with all versions 2.4.4–2.4.9. Adobe classifies this as Priority 1 (apply immediately). Post-patch, credential rotation is mandatory.
Scanning / exposureCrowdSec observed 500+ attacking IPs with 2,760 exploitation signals in the first 5 days. 193 distinct source IPs on peak day (Sept 11). ACSC (Australia) noted a 'substantial number of potentially vulnerable instances' in their alert. Magento/Adobe Commerce powers hundreds of thousands of internet-facing storefronts globally — every unpatched instance with GraphQL enabled (default) is directly reachable.
Disclosure timelineSept 4, 2026 — First exploitation detected by Sansec. Sept 5 — Sansec public disclosure. Sept 7 — Adobe emergency hotfix APSB26-146 released. Sept 8 — CISA KEV addition. Sept 11 — Federal remediation deadline.
Reporting researcherDiscovered in the wild by Sansec (eCommerce security firm). Independently analyzed by Akamai, Fastly, Tenable, and CrowdSec.

Sources.

  1. Sansec — StyleSmuggler 0-day Research
  2. Akamai — CVE-2026-75650 StyleSmuggler Analysis
  3. Adobe Experience League — APSB26-146 Advisory
  4. CISA KEV Addition Alert (September 8, 2026)
  5. CrowdSec — Exploitation Tracking Report
  6. Tenable — StyleSmuggler FAQ
  7. Fastly — What is Style Smuggler?
  8. GitHub PoC — abraxas/CVE-2026-75650
05 · The Call

Final Verdict
= UNCHANGED to CRITICAL (10.0/10)

Why this verdict

  • Zero friction in the attack chain: Every step uses default Magento configuration. GraphQL is enabled by default, guest checkout is core functionality, payment failure emails are automatic, and logging writes unescaped input to disk by default. There are no prerequisites that narrow the reachable population.
  • Unauthenticated remote access from the internet: The entire chain requires PR:N — no credentials, no session, no prior access. The target platform is an internet-facing storefront by design. This is not a post-compromise amplifier; it IS the initial access vector.
  • Active zero-day exploitation with multiple operators: Confirmed exploitation began September 4 — three days before the patch existed. 500+ attacking IPs, Rust backdoors, PHP webshells, gs-netcat, and WraithC2 deployed across victim stores. This is not theoretical.
  • Public PoC and scanner templates available: A fully functional Python 3 PoC (abraxas/CVE-2026-75650) and a Nuclei template are publicly available, lowering the barrier to exploitation to script-kiddie level.
  • Role multiplier: Production e-commerce infrastructure (canonical high-value role). Adobe Commerce and Magento ARE the storefront — 100% of production installations occupy the high-value role by definition. Compromise yields: (a) *PCI-scoped cardholder data* — database contains payment tokens, order histories, customer PII regulated under PCI DSS, GDPR, and CCPA; (b) *Supply-chain pivot* — attackers inject JavaScript card skimmers (Magecart-style) affecting every customer transaction, extending blast radius to the entire customer base; (c) *Credential harvest* — the Magento encryption key protects payment gateway API keys, integration tokens, database credentials, and SSH keys, enabling lateral movement into payment processors and backend infrastructure. Blast radius: host → tenant → supply chain. The floor is CRITICAL because ≥10% of installs (effectively 100%) occupy the high-value role.
  • KEV-listed with 72-hour federal deadline: CISA added this to KEV on September 8 with a September 11 remediation due date, confirming the US government's assessment that this poses immediate risk to federal and critical infrastructure.

Why not higher?

There is no higher severity. CVSS 10.0 is the maximum possible score, and CRITICAL is the highest severity bucket. Every attack-path metric is at its worst-case value.

Why not lower?

Downgrading would require identifying meaningful friction in the attack chain, and there is none. The target is internet-facing by design, the attack is unauthenticated, every step uses default configuration, exploitation is confirmed in the wild at scale, and the blast radius includes PCI-regulated data and supply-chain (Magecart) impact. Any friction-based argument fails: 'requires internet exposure' is the canonical deployment model, 'requires payment processing' is the core function of commerce software, 'requires logging' is default behavior. The installed base is 100% high-value-role by definition.

06 · Verification

Crowdsourced verification payload.

Run this script on the Magento/Adobe Commerce application server as the web user or root. Pass the Magento root directory as the first argument: bash check_cve_2026_75650.sh /var/www/magento. Requires read access to composer.json and PHP source files.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# CVE-2026-75650 (StyleSmuggler) Vulnerability Check
# Checks whether the Magento/Adobe Commerce installation is patched against CVE-2026-75650.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

MAGENTO_ROOT="${1:-.}"
RED='\033[0;31m'; GREEN='\033[0;32m'; YELLOW='\033[1;33m'; NC='\033[0m'

# Verify Magento root
if [[ ! -f "${MAGENTO_ROOT}/composer.json" ]] || [[ ! -d "${MAGENTO_ROOT}/app/etc" ]]; then
    echo -e "${YELLOW}UNKNOWN${NC} — ${MAGENTO_ROOT} does not appear to be a Magento root directory."
    exit 2
fi

# Detect edition and version
VERSION=""
EDITION="unknown"
if grep -q 'magento/product-enterprise-edition' "${MAGENTO_ROOT}/composer.json" 2>/dev/null; then
    EDITION="Adobe Commerce"
    VERSION=$(grep -oP '"magento/product-enterprise-edition"\s*:\s*"\K[^"]+' "${MAGENTO_ROOT}/composer.json" 2>/dev/null || true)
elif grep -q 'magento/product-community-edition' "${MAGENTO_ROOT}/composer.json" 2>/dev/null; then
    EDITION="Magento Open Source"
    VERSION=$(grep -oP '"magento/product-community-edition"\s*:\s*"\K[^"]+' "${MAGENTO_ROOT}/composer.json" 2>/dev/null || true)
fi

if [[ -z "$VERSION" ]] && [[ -x "${MAGENTO_ROOT}/bin/magento" ]]; then
    VERSION=$("${MAGENTO_ROOT}/bin/magento" --version 2>/dev/null | grep -oP '\d+\.\d+\.\d+(-p\d+)?' || true)
fi

if [[ -z "$VERSION" ]]; then
    echo -e "${YELLOW}UNKNOWN${NC} — Could not determine Magento version."
    exit 2
fi

echo "Detected: ${EDITION} ${VERSION}"

# Check for hotfix VULN-39341 / APSB26-146
HOTFIX_FOUND=false
HOTFIX_SOURCE=""

# Method 1: composer.lock or composer.json references
for f in "${MAGENTO_ROOT}/composer.json" "${MAGENTO_ROOT}/composer.lock"; do
    if [[ -f "$f" ]] && grep -qiE 'VULN-39341|APSB26-146|CVE-2026-75650' "$f" 2>/dev/null; then
        HOTFIX_FOUND=true
        HOTFIX_SOURCE="composer reference in $(basename $f)"
    fi
done

# Method 2: m2-hotfixes directory
if [[ -d "${MAGENTO_ROOT}/m2-hotfixes" ]]; then
    if ls "${MAGENTO_ROOT}/m2-hotfixes/"*39341* 2>/dev/null | grep -q . || \
       ls "${MAGENTO_ROOT}/m2-hotfixes/"*75650* 2>/dev/null | grep -q .; then
        HOTFIX_FOUND=true
        HOTFIX_SOURCE="m2-hotfixes directory"
    fi
fi

# Method 3: Check patch application logs
for patchlog in "${MAGENTO_ROOT}/var/.patch"/* "${MAGENTO_ROOT}/var/log/patch"*; do
    if [[ -f "$patchlog" ]] && grep -qiE 'VULN-39341|APSB26-146|CVE-2026-75650' "$patchlog" 2>/dev/null; then
        HOTFIX_FOUND=true
        HOTFIX_SOURCE="patch log $(basename $patchlog)"
    fi
done

# Method 4: Check the Template Filter source for the fix signature
FILTER_FILE="${MAGENTO_ROOT}/vendor/magento/framework/Filter/Template.php"
if [[ -f "$FILTER_FILE" ]]; then
    if grep -qE 'sanitizeDirective|stylesSanitize|VULN.39341|neutralizeTemplateDirectives' "$FILTER_FILE" 2>/dev/null; then
        HOTFIX_FOUND=true
        HOTFIX_SOURCE="patched Template.php"
    fi
fi

if $HOTFIX_FOUND; then
    echo -e "${GREEN}PATCHED${NC} — Hotfix VULN-39341 (APSB26-146) detected via ${HOTFIX_SOURCE}."
    exit 0
fi

# Parse version components
BASE_VER=$(echo "$VERSION" | grep -oP '^\d+\.\d+\.\d+')
if [[ -z "$BASE_VER" ]]; then
    echo -e "${YELLOW}UNKNOWN${NC} — Could not parse version: ${VERSION}"
    exit 2
fi

IFS='.' read -r MAJ MIN PATCH <<< "$BASE_VER"

# Affected range: 2.4.4 through 2.4.9
if (( MAJ == 2 && MIN == 4 && PATCH >= 4 && PATCH <= 9 )); then
    echo -e "${RED}VULNERABLE${NC} — ${EDITION} ${VERSION} is in the affected range (2.4.4–2.4.9)."
    echo "Hotfix VULN-39341 (APSB26-146) was NOT detected."
    echo "Apply immediately: https://experienceleague.adobe.com/en/docs/commerce-knowledge-base/kb/announcements/commerce-apsb26-146"
    # Also check for IOCs
    echo ""
    echo "=== Quick IOC scan ==="
    if find "${MAGENTO_ROOT}/pub/media/" -name '*.php' -newer "${MAGENTO_ROOT}/composer.json" 2>/dev/null | head -5 | grep -q .; then
        echo -e "${RED}WARNING:${NC} PHP files found in pub/media/ — possible webshell"
        find "${MAGENTO_ROOT}/pub/media/" -name '*.php' -newer "${MAGENTO_ROOT}/composer.json" 2>/dev/null | head -10
    fi
    if grep -r 'Laminas.Loader.Exception.InvalidArgumentException' "${MAGENTO_ROOT}/var/log/exception.log" 2>/dev/null | head -1 | grep -q .; then
        echo -e "${RED}WARNING:${NC} StyleSmuggler exploitation signature found in exception.log"
    fi
    exit 1
else
    echo -e "${YELLOW}UNKNOWN${NC} — ${EDITION} ${VERSION} is outside the documented affected range (2.4.4–2.4.9). Verify manually."
    exit 2
fi