stylesmuggler-ioc-toolkit

StyleSmuggler (CVE-2026-75650) IOC toolkit for Magento Open Source and Adobe Commerce. Detect compromised stores, Rust implants, PHP web shells, persistence artifacts, and known indicators of compromise.

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

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.

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 two-stage, file-based deferred-execution primitive rather than a single obvious injection point:

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.

An easy, no-tooling early warning sign: a garbled "Payment Transaction Failed Reminder" email in your inbox with raw, unrendered {{var ...}} tags and a customer address ending in .invalid. This is often the first visible sign, before anyone checks a log.

Sansec's updates confirmed a second, independent exploitation path for the same Rust-implant campaign: even stores that moved session storage off Redis and onto the database were still compromised — the same operator's second attempt succeeded seconds later using a file uploaded through Magento's customer custom options feature instead. Moving session storage is not a fix by itself.

Separately, on September 7, Sansec found a completely unrelated attacker using the exact same StyleSmuggler entry point for a much simpler payload: a PHP web shell dropped into Magento's own product-image cache (pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php), preceded by a reconnaissance probe that hides its payload in the Store: HTTP header and exfiltrates its findings over DNS rather than an HTTP response. This is "off-the-shelf tooling," per Sansec — not a sustained campaign — but it means a single vulnerable host can carry two unrelated intrusions through one flaw. Cleaning up the Rust implant does not mean your store is clean.

The Rust implant itself has also evolved: the original [kworker/u:8:0]-masquerading build (Sept 4) was followed by an fc-cache-masquerading build v2.1.4 (Sept 6) that beacons out disguised as NTP traffic, and then a chronyd-masquerading redeploy v2.1.5 (Sept 7) of the same implant, same agent ID — evidence the attacker is actively iterating to evade whatever detection you publish. Sansec states it hasn't yet seen evidence this implant was weaponized beyond persistence/recon — don't read that as reassurance given the unrelated attacker's working web shell on the same access path.

See docs/FAQ.md for quick answers, docs/VULNERABILITY.md for the full technical writeup and sourcing, docs/PATCHING.md for applying Adobe's official fix, and docs/INCIDENT_RESPONSE.md for what to do if the scanner finds something.

Quick start

1. Patch, if your version is covered:

2. Scan for existing compromise regardless of patch status — patching stops new exploitation, it doesn't clean an existing backdoor or web shell:

Or the Python version for structured (JSON) output, e.g. for feeding a SIEM:

Both scripts are read-only by default — they detect and report, they don't kill processes or delete files unless you pass --remediate, because premature cleanup destroys forensic evidence (see docs/INCIDENT_RESPONSE.md).

What the scanner checks

• Known filesystem persistence artifacts across all three observed Rust-implant builds:
  • [kworker/u:8:0] build: ~/.local/share/.gvfsd/gvfsd-user, its lock files, /tmp/.kw_*, /tmp/.gvfsd_*
  • fc-cache build v2.1.4 (Sept 6): ~/.cache/fontconfig/fc-cache, /tmp/.fc_<8hex>.lock
  • chronyd build v2.1.5 (Sept 7): /tmp/.chrony-<8hex>/chronyd
• The self-restoring crontab entries the implant writes directly to the cron spool — every 5 minutes for the gvfsd-user build, twice an hour (13,43 * * * *) for fc-cache
• A masquerading process named [kworker/u:8:0], fc-cache, or chronyd that is not owned by root (or, for fc-cache/chronyd, doesn't match the real system binary)
• SHA-256 of on-disk binaries and of the live /proc/<pid>/exe image (the two can differ — the implant has been observed updating itself in memory)
• Poisoned log/report files (var/log/system.log, var/report/) for injected PHP, the two known trigger-header shapes (X-TRACE-<10hex> and X-<12hex>), and the second, unrelated attacker's campaign markers (ss5_/ss6_<hex>) and DNS-canary domain (oast.site)
• Proof-of-execution response markers (MG<20hex>::...::/MG<20hex>) left behind in logs when the payload actually ran
• PHP files under pub/media — which should never contain executable PHP on a correctly configured Magento store — matching the second attacker's web-shell drop pattern
• Established connections to the published C2/download hosts — including the fc-cache/chronyd build's NTP-shaped beaconing to ntp.timesync.to:123/UDP (and fallbacks), and its plain-HTTP calls to public IP-lookup services
• Anomalous local Redis connection counts (session-harvesting has been observed entirely over 127.0.0.1:6379, with zero outbound C2 traffic — a quiet network is not a clean one) — and note that moving sessions off Redis alone does not close the second, file-upload-based exploitation vector

Full indicator list with sourcing: iocs/.

Patching and mitigation

1. Apply Adobe's official hotfix (VULN-39341 / APSB26-146) if your version is covered — see docs/PATCHING.md for identifiers, where to get it, and how to apply it. This is now the priority, ahead of the interim mitigations below.
2. If you can't patch immediately, or your version isn't covered, use the interim mitigations in mitigations/:
   • Block or rate-limit GraphQL's styles[] delivery path (nginx / Apache)
   • Block PHP execution under pub/media/pub/static (nginx / Apache) — targeted defense against the second, unrelated attacker's web-shell technique
   • ModSecurity rules for POST-body inspection and fail2ban as a reactive backstop
   • See mitigations/README.md for scope limitations — none of these close the customer-custom-options vector or the second attacker's Store:-header delivery.
3. Run the compromise scanner regardless of patch/mitigation status. Patching and mitigating stop new exploitation; neither cleans an already-dropped backdoor or web shell.
4. If the scanner finds anything, treat the host as fully compromised, not just "backdoor present." Code execution as the site user exposes everything that user can read, starting with app/etc/env.php. At minimum, after containment: flush session storage (Redis and/or DB), rotate the Magento crypt/key, all admin passwords (and invalidate existing admin sessions), the database password, every payment-provider API key and other integration credential in env.php, and any SSH/deploy keys the site user could read. Also check the admin_user table for a rogue account and pub/media/ / pub/static/ / theme directories for dropped webshells — both the Rust implant's and the unrelated second attacker's — before you consider a store clean. Full ordered steps: docs/INCIDENT_RESPONSE.md.

Repo layout

Frequently searched terms

CVE-2026-75650, APSB26-146, VULN-39341, Magento zero-day 2026, Adobe Commerce zero-day, StyleSmuggler patch, Magento GraphQL vulnerability, Magento styles parameter RCE, gvfsd-user malware, fc-cache Magento backdoor, chronyd Magento malware, Magento kworker process malware, Magento Redis session hijack, Magento unauthenticated RCE September 2026, Magento 2.4.9 exploit, Adobe Commerce backdoor removal, Magento pub/media web shell, eComscan StyleSmuggler, Sansec Shield StyleSmuggler.

Sourcing and provenance

Every indicator in this repo traces back to a cited, published source — primarily Sansec's advisory (updated through at least 2026-09-07 20:50 UTC), Adobe's APSB26-146 bulletin, and community incident-response write-ups from responders who handled live infections. See the citation at the bottom of each file in iocs/.

Do not treat anything here as exhaustive or final. IOCs (trigger headers, user-agent strings, implant disguises, and now a second attacker's campaign markers) have already changed multiple times within days of disclosure; expect them to change again. Match shapes and behavior, not just literal strings, wherever the scripts let you.

Contributing

Seen a variant, a new hash, a new source address, or a false positive? Open an issue or PR with what you observed and how you observed it. Please:

• Redact your own organization's identifying details before sharing.
• Don't post exploit payloads or working trigger requests here — indicators and detection logic only.
• Report the underlying vulnerability itself to Sansec and Adobe PSIRT, not to this repo.

License

MIT for the code in this repo (see LICENSE). Indicator data is provided "as is" for defensive use, with sourcing noted throughout.

Disclaimer

This is unofficial, community-built defensive tooling, not an Adobe or Sansec product, and is not affiliated with either. It is provided without warranty. Adobe's official patch (APSB26-146) has been released, but coverage is limited to specific product versions — check Adobe's security bulletin directly before assuming your installation is covered or fixed.