XHack
Author
Table of Contents
15
By Salman Khan, OSCP+, Founder of XHack, SRT (Synack Red Team member)
Read this in 30 seconds: StyleSmuggler is an unauthenticated remote code execution zero-day in Magento Open Source and Adobe Commerce, disclosed by Sansec on September 5, 2026, with live attacks confirmed since September 4. It affects every current version, including 2.4.9, and needs zero credentials. The attack works in two stages: first, an attacker smuggles PHP code into a Magento-generated log or report file by abusing a
stylesparameter in a GraphQL request, then triggers Magento to send its own “Payment Transaction Failed Reminder” email, which forces a template-rendering chain that abuses Magento’s dependency-injection code scanners toinclude()the poisoned file and execute it.No patch existed as of this writing, Adobe’s next scheduled bulletin is September 8. Attackers are already dropping a Rust-based backdoor that masquerades as a kernel worker process and phones home over TLS WebSocket. If you run Magento or Adobe Commerce, disable GraphQL if you can, apply the community DI-scanner patch, and hunt for the IOCs below today.
The most dangerous part of StyleSmuggler isn’t the exploit, it’s the delivery mechanism. Nobody has to click a link, open an attachment, or fall for anything. The vulnerable code path is the same one that renders every ordinary transactional email your store already sends. An attacker triggers a failed payment, Magento does what Magento always does, and that alone is enough to run their code.
Sansec, the e-commerce security firm that discovered it, named the flaw StyleSmuggler and pushed the disclosure out before finishing its full write-up, because, in their words, stores were being compromised in real time. Multiple outlets picked up the story within hours of disclosure. It’s an unauthenticated RCE affecting Magento Open Source and Adobe Commerce versions 2.4.7, 2.4.8, and 2.4.9, the current, fully-patched release line. The first confirmed victim was actually running 2.4.6-p15 with July and August 2026 security patches already applied, which tells you this isn’t a case of someone skipping updates. It’s a genuinely new hole.
There’s no CVE assigned yet. Adobe’s next scheduled security bulletin lands September 8, which means for at least three days after public disclosure, every Magento store on earth is exposed with no official fix.
Strip away the technical jargon and StyleSmuggler is a two-step trick: poison a file Magento writes for itself, then trick Magento into running that file.
Stage 1, Injection: The attacker sends a crafted request to Magento’s GraphQL endpoint that includes a malformed store parameter or similar input. Magento, doing exactly what logging is supposed to do, writes that input verbatim into var/log/system.log or an error report under var/report/. Except this time, the “input” is PHP code the attacker chose.
Stage 2, Execution: The attacker triggers Magento’s own “Payment Transaction Failed Reminder” email, a completely legitimate, everyday store notification. Rendering that email routes through Magento’s template filter, and a styles parameter in the original GraphQL request chains through Magento’s dependency-injection system until it reaches a scanner class that blindly includes a caller-supplied file path, the poisoned log file from Stage 1. The moment that file gets include()‘d, the attacker’s PHP code executes as the Magento application.
Nobody opens the email. Nobody has to receive it. The code runs the instant Magento renders it internally.
This is the part that makes StyleSmuggler genuinely hard to patch cleanly, and it’s public information from the community’s own technical breakdown. The chain terminates in one of three Magento DI (dependency injection) code scanner classes, whose entire job is scanning generated code during the CLI-only setup:di:compile step. The vulnerable pattern looks like this:
public function collectEntities(array $files)
{
foreach ($files as $file) {
if (file_exists($file)) {
$data = include $file; // Parses AND executes
// ...
}
}
}That include $file line was written assuming $file would only ever be a path generated during a trusted, command-line-only compilation step. StyleSmuggler’s GraphQL request chain reaches this exact code path from an unauthenticated web request instead, with $file pointed at the log file the attacker poisoned in Stage 1. Two sibling classes, ClassesScanner.php and XmlInterceptorScanner.php, have the identically-shaped bug using require_once instead of include.
The insight worth sitting with here: the entry point cannot be cleanly guarded, because the exact same code path renders every legitimate transactional email and newsletter your store sends. You can’t just block “the vulnerable request”, the vulnerable request looks identical to normal store operation until it reaches the DI scanner sink. That’s why the fix has to happen at the sink, not the door.
Once the included file runs, the implant probes for whatever code-execution function is actually available on the box, shell_exec, exec, system, passthru, proc_open, popen, checking each in turn until one works. It then downloads a roughly 1.9MB Rust-compiled backdoor from 247.cdnflare.xyz.
The implant establishes persistence through a crontab entry:
*/5 * * * * exec <home>/.local/share/.gvfsd/gvfsd-user
It masquerades in the process list as [kworker/u:8:0], mimicking a Linux kernel worker thread to blend into normal ps output, and communicates with a command-and-control server at 99.84.67.186:443 over a TLS-wrapped WebSocket connection, dressing malicious traffic up as ordinary encrypted web traffic.
stylesmuggler-di-scanner-guard.patch) that adds a PHP_SAPI !== 'cli' check to the three vulnerable scanner classes, so they refuse to run outside a genuine command-line compilation context:"extra": {
"composer-exit-on-patch-failure": true,
"patches": {
"magento/magento2-base": {
"StyleSmuggler: DI code scanners are CLI-only": "patches/magento/magento2-base/stylesmuggler-di-scanner-guard.patch"
}
}
}Applied via composer -o install, or manually with patch -p1 --forward < patches/magento/magento2-base/stylesmuggler-di-scanner-guard.patch followed by bin/magento setup:di:compile. This is community incident-response code, not an official Adobe patch, so test on staging first.
proc_open in php.ini (disable_functions = proc_open) as a blast-radius reducer. The logic is blunt but effective: no exec function available, no dropped implant runs, whatever sink the attacker actually reaches./tmp, /var/tmp, and /dev/shm with noexec. Even if the implant downloads successfully, a noexec mount stops the binary from ever running..gvfsd/gvfsd-user, a suspicious [kworker/u:8:0]-labeled process that doesn’t trace back to an actual kernel thread, and any outbound TLS traffic to 99.84.67.186 or DNS lookups for 247.cdnflare.xyz.var/log/system.log and var/report/ for embedded PHP tags or obfuscated code that has no business being in a log file.StyleSmuggler is the latest entry in a pattern that keeps recurring across CMS platforms: a feature meant for trusted, internal, CLI-only use gets reached from an untrusted web-facing code path because nobody threat-modeled that connection. The DI scanner was never designed to process attacker input, it was designed to scan generated code during a build step a developer runs on their own machine. Nobody wrote it defensively because nobody imagined a web request would ever reach it. That’s precisely why it took a name-brand zero-day and live compromises to surface it.
The other lesson is about detection surface. A vulnerability chain that abuses your own logging and email systems is deliberately choosing the parts of your application least likely to be monitored as attack surface. Security teams watch login forms and file uploads. Almost nobody watches whether their payment-failure email template just got used as a code execution primitive.
Brand note: a version-check vulnerability scanner would tell you Magento 2.4.9 is “up to date” right up until the moment it gets compromised through a code path nobody thought to test, because the vulnerability isn’t in a version number, it’s in how two unrelated legitimate features, GraphQL input handling and transactional email rendering, interact in a way the platform’s own developers never modeled.
The XHack AI agent maps how a platform’s legitimate features can chain together the way an attacker actually thinks, not just whether a CVE database has an entry for your version string. For e-commerce infrastructure carrying customer payment data, human-led VAPT tests exactly these cross-feature interaction risks that automated scanning misses, and XHack doesn’t store your findings on our servers either, your engagement data stays local and fully deletable by you.
StyleSmuggler is an unauthenticated remote code execution zero-day affecting Magento Open Source and Adobe Commerce versions 2.4.7 through 2.4.9. It works by injecting PHP code into a Magento-generated log file via a GraphQL styles parameter, then triggering a transactional email that forces Magento’s dependency-injection scanner to include and execute that poisoned file.
Not an official one yet. Adobe’s next scheduled security bulletin is September 8, 2026. A community-developed patch that guards the three vulnerable DI scanner classes against non-CLI execution is circulating and has been independently verified, but it’s incident-response code, not an Adobe-issued fix, so test it on staging before deploying to production.
No. That’s what makes it dangerous. The attacker triggers a routine “Payment Transaction Failed Reminder” email that Magento sends automatically as part of normal store operation. The malicious code executes the moment Magento renders that email internally, nobody needs to open it, click a link inside it, or even receive it.
Check for a crontab entry referencing .local/share/.gvfsd/gvfsd-user, a running process labeled [kworker/u:8:0] that doesn’t correspond to an actual kernel thread, and outbound connections to 99.84.67.186 or lookups for 247.cdnflare.xyz. Also inspect var/log/system.log and var/report/ for embedded PHP code that shouldn’t be there.
If you don’t have a dedicated Magento-aware WAF, yes, Sansec’s own recommendation is to temporarily disable GraphQL until an official patch ships. It costs you some storefront functionality that depends on the GraphQL API, but it closes the injection stage of the attack chain entirely in the meantime.
StyleSmuggler is what happens when two completely unremarkable, fully legitimate platform features, logging and transactional email, get chained together into unauthenticated code execution. No login required, no patch available, and the entry point can’t be cleanly blocked because it’s the same path every normal store email travels through. Disable GraphQL if you can afford to, apply the community patch as an interim measure, and hunt the IOCs today. Adobe’s official fix is still days away, and attackers already have a three-day head start.
Related articles
By Salman Khan, OSCP+, Founder of XHack, SRT (Synack Red Team member) A leaked password is bad. A secret that […]...
By Salman Khan, OSCP+, Founder of XHack, SRT (Synack Red Team member) Read this in 30 seconds: CVE-2026-86218 is a [&hel...
By Salman Khan, OSCP+, Founder of XHack, SRT (Synack Red Team member) Read this in 30 seconds: CVE-2026-85046 is a [&hel...