StyleSmuggler IOC Toolkit — CVE-2026-75650

Magento zero-day · Adobe Commerce zero-day · CVE-2026-75650 · APSB26-146 · VULN-39341 · unauthenticated RCE · Magento malware · Magento backdoor removal · Magento 2.4.9 vulnerability · Rust implant · GraphQL styles injection · PHP web shell

Community indicators-of-compromise, a compromise scanner, and mitigation/patching guidance for StyleSmuggler (CVE-2026-75650) — the unauthenticated Magento Open Source / Adobe Commerce RCE disclosed by Sansec on September 5, 2026, with in-the-wild exploitation confirmed from September 4, 2026. Adobe published an official fix, APSB26-146, on September 7, 2026. If you searched for "StyleSmuggler IOC", "CVE-2026-75650", "APSB26-146", "VULN-39341", "Magento fc-cache malware", "Magento chronyd backdoor", "gvfsd-user Magento", or "Magento GraphQL styles RCE", this is the repo you want.

This is a defensive toolkit only. It contains detection signatures, a compromise scanner, and hardening/blocking rules built from published, first-hand incident reports. It does not contain exploit code, a proof-of-concept trigger, or anything that generates the attack payload. If you are looking for that, you are in the wrong repo — go patch and hunt instead.

Status as of this writing (2026-09-16)

Vulnerability	StyleSmuggler (Sansec's name) — CVE-2026-75650
Vendor	Adobe (Magento Open Source, Adobe Commerce)
CVE	CVE-2026-75650, assigned 2026-09-07
Adobe bulletin	APSB26-146, published 2026-09-07 20:20 UTC, Priority 1 (highest)
Also required	APSB26-138 (Adobe's regular September 2026 Commerce update, isolated patch 249-2026-09-001-CE, released 2026-09-08). Adobe states VULN-39341 must be applied in addition to this, not instead of it.
CVSS	10.0 (3.1 and 4.0) — Critical. Full 3.1 vector: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
CWE	CWE-1336, Improper Neutralization of Special Elements Used in a Template Engine
CISA KEV	Added to CISA's Known Exploited Vulnerabilities catalog 2026-09-08. Federal civilian executive branch (FCEB) remediation deadline: 2026-09-11. CISA's entry also flags this as requiring forensic/IR triage, with known ransomware-campaign use listed as "Unknown." Not just a Magento-community problem — this is now a federally-tracked, actively-exploited RCE.
Official patch	Shipped. Hotfix VULN-39341. Coverage is not universal — see the table below.
Authentication required	None — unauthenticated
Public exploit code	No official PoC from Adobe/Sansec, but corroborating coverage notes a public GitHub repo (created ~Sept 8) describing itself as a research lab reproduction of the full chain — "no public exploit code" is weaker than it sounds. See docs/VULNERABILITY.md.
Affected versions	Reproduced by Sansec on clean Magento Open Source 2.4.7, 2.4.8, 2.4.9; first confirmed victim ran 2.4.6-p15 fully patched (on prior patches)
Exploitation	Active since 2026-09-04 22:20 UTC; continued through patch release; at least three independent toolkits confirmed exploiting the same entry point as of 2026-09-14. One exploit-tracking network reports 500+ distinct source IPs since Sept 9. Third-party WAF telemetry (Imperva) reports observed targets skew retail (~39.5%), lifestyle (~19.5%), and healthcare (~17.9%) — snapshots of individual vendors' visibility, not a claim about the full population of vulnerable stores.
Known Rust-implant variants	[kworker/u:8:0] (Sept 4) → fc-cache v2.1.4 (Sept 6) → chronyd v2.1.5 (Sept 7) — same operator, same agent ID, versions incrementing. The chronyd build has been observed self-relaunching with no cron entry and a PID-1 parent.
Second, unrelated attacker	PHP web shell in pub/media/catalog/product/cache/, preceded by a DNS-exfiltrating recon probe — independent of the Rust implant, confirmed 2026-09-07
Third, distinct toolkit	Confirmed 2026-09-14. A remote-file-include backdoor edited directly into the core framework file vendor/magento/framework/App/View.php, gated by a cookie (gl_google_advisor_824808) disguised as ad-tech tracking. Fetches and executes a remote payload on demand, then deletes the transient file — nothing sits on disk between requests except the one tampered line in a vendor file.
Detonation without the email	Confirmed 2026-09-14. A second chain reaches full code execution via POST /paypal/transparent/response/ (PHP source in the query string) without ever rendering the "failed payment" email — markers MGPROOF::/MGKWSIM::, direct command execution through a kwc parameter. Mitigations built around the email trigger alone do not cover this.
Known delivery vectors	GraphQL styles[] parameter; invalid store code logged to var/log/system.log; file uploaded via Magento's customer custom options; the unrelated second attacker's Store:-header injection; PHP source in the /paypal/transparent/response/ query string (email-independent)
Impact	Remote code execution → persistent Rust-based backdoor, independent PHP web shell, a stealthy framework-level RFI backdoor, Redis session harvesting, credential/secret exposure via app/etc/env.php

Adobe's official patch coverage — check this before assuming you're safe

Product	Covered by APSB26-146	No official fix
Adobe Commerce (incl. B2B, Cloud)	2.4.4 – 2.4.9	below 2.4.4
Adobe Commerce B2B	1.3.3 – 1.5.3	below 1.3.3
Magento Open Source	2.4.6 – 2.4.9 only	2.4.5 and below

If you're on an older, unsupported version, Adobe is not shipping you a fix even though you're just as exploitable. See docs/PATCHING.md for your options — including a note for Mage-OS users, who have a dedicated emergency release (3.5.0) rather than Adobe's Commerce-specific hotfix package.

This information changes fast. Cross-check against the primary sources before acting: Sansec's advisory and Adobe's bulletin. See docs/TIMELINE.md for a running log and cite your sources when you update anything here.

What StyleSmuggler actually is

Magento's own GraphQL styles parameter and its dependency-injection based file scanning are abused as a file-based deferred-execution primitive. The originally documented chain has two stages, but — as of Sansec's September 14 update — it is not the only confirmed chain, and detonation does not always require what stage two originally described:

1. Poison. Attacker-controlled data reaches a Magento-generated log or report file (var/log/system.log via an invalid store code that Magento logs verbatim, or var/report/<hash>), smuggled in through the GraphQL styles[] parameter, a mutated request header, or (for the second, unrelated attacker below) the Store: header.
2. Detonate. The attacker triggers Magento's standard "Payment Transaction Failed Reminder" email. Rendering that email (Magento's getProcessedTemplate path) walks a code path that lets Magento's own DI/code scanner include() the poisoned file, running the attacker's PHP. You do not need to open the email — rendering it server-side is enough — and the chain can fire even when mail delivery itself fails.