# StyleSmuggler — Unpatched Magento and Adobe Commerce Zero-Day Exploited to Backdoor Online Stores > An unauthenticated remote code execution zero-day vulnerability in Magento Open Source and Adobe Commerce, discovered by Sansec and named StyleSmuggler. The two-stage attack chain abuses Magento's GraphQL endpoint and template rendering system to inject PHP code into log files, then triggers execution through the built-in Payment Transaction Failed Reminder email template — deploying a persistent Rust backdoor disguised as a Linux kernel thread. Actively exploited since September 4, 2026 with confirmed compromises of multiple stores and no official patch or CVE as of publication. - **Published:** 2026-09-06T00:00:00Z - **Last reviewed:** 2026-09-14T21:21:12.946Z - **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-2358 - **ID:** TL-2026-2358 - **Severity:** CRITICAL (CVSS 10) - **Category:** VULNERABILITY - **Status:** ACTIVE - **Detections:** 9 · **IOCs:** 60 (full data via the Threadlinqs MCP server — Purple tier) - **CVEs:** CVE-2026-75650 ## Description StyleSmuggler is an unauthenticated remote code execution (RCE) zero-day vulnerability affecting Magento Open Source and Adobe Commerce, discovered by Dutch e-commerce security firm Sansec on September 4, 2026. The vulnerability is actively exploited in the wild with confirmed compromises of at least two stores managed by Disrex Group, plus additional victims detected via Sansec's eComscan platform. As of September 6, 2026, no CVE has been assigned by Adobe, no official patch has been released, and all supported versions of Magento Open Source (2.4.6 through 2.4.9) and the corresponding Adobe Commerce versions are confirmed affected — including one victim running 2.4.6-p15 with July and August 2026 security patches applied. The attack follows a sophisticated two-stage chain. In Stage 1 (injection), the attacker sends a malicious HTTP request through Magento's GraphQL endpoint with crafted styles[] parameters that bypass input sanitization and force Magento's template rendering engine to write PHP code into files the application itself maintains — either var/log/system.log (via an invalid store code logged verbatim) or var/report/ (via uncaught exception failure reports). The trigger header marking the poisoned content is an X-TRACE- followed by ten hex characters (early campaign) or X- followed by twelve hex characters (later same day, after the marker was deliberately changed). In Stage 2 (execution), the attacker triggers Magento's built-in Payment Transaction Failed Reminder email by submitting an order with a .invalid domain address and a zero total. Magento's getProcessedTemplate() method parses the {{block}} directive embedded in the attacker-controlled text, instantiating objects through parameters like generatorClass and with_resolved. The object-injection chain walks through Magento's internal class hierarchy until it reaches one of three dependency-injection compiler scanner methods — ArrayScanner::collectEntities(), ClassesScanner::includeClass(), or XmlInterceptorScanner::_handleControllerClassName() — in setup/src/Magento/Setup/Module/Di/Code/. These methods accept attacker-controlled file paths and execute them via PHP include or require_once. Because PHP's include executes any PHP content in the file, a log file full of harmless-looking diagnostic messages becomes executable code. A TypeError from array_merge() with an integer argument in system.log immediately after the include is a forensic tell confirming successful exploitation; stealthier variants append return []; to the payload, leaving no error trace. Upon code execution, a PHP dropper probes six PHP process-execution functions sequentially — shell_exec, exec, system, passthru, proc_open, popen — and uses the first available. On one store where the first four were disabled by open_basedir, proc_open remained enabled and was sufficient for the dropper to spawn the child process, which then operated outside PHP's confinement entirely. The dropper downloads an architecture-matched (~1.9 MB, stripped, statically linked) Rust binary from https://247.cdnflare.xyz/files/kworker-linux-, compiles for both x86-64 and arm64, makes it executable, and detaches it as a background process. The binary installs itself at ~/.local/share/.gvfsd/gvfsd-user — outside the web document root, under the site user's home directory — and masquerades as [kworker/u:8:0] to mimic a legitimate Linux kernel thread. Genuine kernel threads are owned by root with zero resident memory; a bracketed process name owned by a site user with real RSS consumption is the definitive detection signal. The implant sets its command-line string to the bracketed value directly, so checks against the comm field (which ps derives from args) match nothing. Persistence is achieved through a cron entry written directly to /var/spool/cron/crontabs/, bypassing the crontab command so syslog records no REPLACE events. The entry executes the implant every 5 minutes: */5 * * * * exec /.local/share/.gvfsd/gvfsd-user. The implant re-adds the entry within one second of removal; one store exhibited 1,728 identical lines. The binary in memory may differ from the file on disk, as confirmed on one compromised store — defenders are advised to hash the running process from /proc//exe as well as the file on disk. The implant persists even after file deletion through the deleted inode accessible via /proc//exe. C2 communication occurs over multiple channels: WebSocket over TLS to 99.84.67.186:443 (and windwsecurity.run:443 for remote shell access), as well as custom NTP-shaped traffic over UDP port 123 to ntp.timesysnc.net, time.microsft.run, and pool.microsft.studio — blending with legitimate NTP traffic on the network. On at least one compromised store, two 200+ MB packet captures contained zero packets to any known C2 address; instead, the implant held 28 simultaneous connections to the local Redis instance on 127.0.0.1:6379, reading Magento session data. This pattern makes egress-based network monitoring unreliable as a compromise indicator. Attack infrastructure includes 26+ distinct source addresses spanning at least two waves: two hosting-provider IPs (5.181.86.133 from CloudVPS with 96 requests, 91.238.181.19 from AS49434 with 48 requests in a second wave) and 24 residential proxy IPs from consumer ISPs sending 2-6 requests each. Blocking only the most prominent attacker IP (88.216.72.181 with 45 requests) would stop less than a quarter of observed traffic. The malware download host 247.cdnflare.xyz resolves to both IPv4 and IPv6 (2a06:98c1:3120::2, 2a06:98c1:3121::2). Several early-warning signs help merchants detect compromise: (1) a Payment Transaction Failed Reminder email containing raw unresolved {{var ...}} template tags, a customer address on a .invalid domain, and a total of zero — described by Disrex as exhaust from the exploitation attempt passing through Magento's template filter; (2) Magento's fallback 'an error occurred generating this content' message inside email address blocks; (3) unexpected bursts of Payment Transaction Failed Reminder emails; (4) the presence of X_TRACE_, X_-hex, or ::::/MG<20hex> patterns. Multiple unofficial mitigations have been published. Disrex Group shipped a composer-patches source patch adding a PHP_SAPI !== 'cli' guard to all three DI scanner methods, verified working on Magento 2.4.6 through 2.4.9 and live-tested on 2.4.7-p2 and 2.4.8-p4. ProxiBlue (Lucas van Staden) independently published the identical guard on September 5. Graycore published a Composer-installable hardening module (graycore/magento2-style-smuggler-patch) with three entry-point protections: email template block directive filtering, grid row URL generator class validation, and PHP open tag breaking in Web API fatal error reports — explicitly noting this is hardening, not a fix. Server-level protections include disabling all six PHP process-execution functions (especially proc_open), mounting /tmp, /var/tmp, and /dev/shm with noexec, and deploying web server rules blocking styles[], generatorClass, and with_resolved parameters in query strings (bypassable via POST body). Temporarily disabling GraphQL is recommended for classic/Hyvä storefronts that do not require it. Sansec Shield detection rules have been operational since September 5 at 07:15 UTC. Adobe's next scheduled security release is September 8, 2026, although it has not been confirmed to address this vulnerability. ## MITRE ATT&CK - T1583.001 Acquire Infrastructure: Domains - T1587.001 Develop Capabilities: Malware - T1190 Exploit Public-Facing Application - T1059.007 JavaScript - T1053.003 Scheduled Task/Job: Cron - T1036.005 Match Legitimate Resource Name or Location - T1564.001 Hide Artifacts: Hidden Files and Directories - T1027 Obfuscated Files or Information - T1005 Data from Local System - T1071.001 Web Protocols - T1573.001 Encrypted Channel: Symmetric Cryptography - T1001.003 Protocol or Service Impersonation - T1090.002 Proxy: External Proxy - T1059 Command and Scripting Interpreter - T1059.004 Command and Scripting Interpreter: Unix Shell - T1505.003 Server Software Component: Web Shell - T1036.004 Masquerading: Masquerade Task or Service - T1070.004 Indicator Removal: File Deletion - T1082 System Information Discovery - T1095 Non-Application Layer Protocol - T1573 Encrypted Channel - T1041 Exfiltration Over C2 Channel - T1497.001 Virtualization/Sandbox Evasion: System Checks - T1083 File and Directory Discovery - T1105 Ingress Tool Transfer - T1048.003 Exfiltration Over Unencrypted Non-C2 Protocol - T1622 Debugger Evasion - T1071.004 Application Layer Protocol: DNS - T1008 Fallback Channels - T1595.002 Active Scanning: Vulnerability Scanning - T1608.001 Stage Capabilities: Upload Malware - T1140 Deobfuscate/Decode Files or Information - T1567 Exfiltration Over Web Service ## Sources - [StyleSmuggler — Full Technical Analysis (Sansec)](https://sansec.io/research/stylesmuggler) - [Unpatched Magento and Adobe Commerce Zero-Day Exploited to Backdoor Online Stores](https://thehackernews.com/2026/09/unpatched-magento-and-adobe-commerce.html) - [StyleSmuggler Magento Zero-Day — Disrex Incident Report](https://www.disrex.nl/blogs/stylesmuggler-magento-zero-day) - [StyleSmuggler Mitigation Repository (Disrex)](https://github.com/disrex-group/stylesmuggler-mitigation) - [StyleSmuggler Attack Chain — HOW-IT-WORKS (Disrex)](https://github.com/disrex-group/stylesmuggler-mitigation/blob/main/HOW-IT-WORKS.md) - [Magento 2 StyleSmuggler Patch (Graycore)](https://github.com/graycoreio/magento2-style-smuggler-patch) - [Magento and Adobe Commerce 0-Day RCE — Cybersecurity News](https://cybersecuritynews.com/magento-and-adobe-commerce-0-day-rce/) - [Create Hosting Advisory — Critical Security Vulnerability StyleSmuggler](https://www.createhosting.co.nz/support/announcements/111/Critical-Security-Vulnerability-StyleSmuggler---Adobe-Commerce-or-Magento-Open-Source.html) - [StyleSmuggler IOC List (Disrex)](https://github.com/disrex-group/stylesmuggler-mitigation/blob/main/IOC.md) - [StyleSmuggler Cleanup Guide (Disrex)](https://github.com/disrex-group/stylesmuggler-mitigation/blob/main/CLEANUP.md) - [ProxiBlue Unofficial Magento StyleSmuggler Patches](https://gist.github.com/ProxiBlue) ## Full data Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp Canonical: https://intel.threadlinqs.com/threat/TL-2026-2358