A newly disclosed zero-day vulnerability dubbed “StyleSmuggler” is putting every current installation of Magento Open Source and Adobe Commerce at risk of complete takeover, and there is still no official patch, advisory, or CVE identifier to fix it. Researchers at Dutch e-commerce security firm Sansec, working alongside hosting specialist Disrex Group, disclosed the flaw after tracing live compromises back to a previously unknown attack chain built entirely out of Magento’s own legitimate code.

An attack built from trusted components

Unlike a typical injection bug tied to a single vulnerable parameter, StyleSmuggler abuses the way Magento’s platform is designed to work. Attackers manipulate properties inside routine GraphQL requests to smuggle malicious PHP code into files that Magento itself creates during normal operation. Because the code rides in through a legitimate, expected process rather than an obviously malformed request, it can slip past defenses tuned to catch conventional web shells or file-upload abuse.

The payload stays dormant until Magento’s own email system does the rest of the work. When the platform internally renders a routine “Payment Transaction Failed Reminder” notification, it triggers a chain of the platform’s own classes to execute code that, as researchers put it, “was only ever meant to run through the command-line dependency-injection compiler.” No shopper has to click anything, no administrator has to approve anything, and no separate upload endpoint is required. The store effectively attacks itself on the attacker’s behalf.

Every current version is exposed

Sansec confirmed the technique works against Magento and Adobe Commerce 2.4.7, 2.4.8, and the newly released 2.4.9, meaning fully up-to-date deployments offer no protection. In at least one confirmed compromise, the victim was running version 2.4.6-p15 with both the July and August 2026 security patches applied, underscoring that this is not a case of neglected maintenance. Because Adobe has not yet shipped a fix or assigned a CVE, store operators currently have no official patch to install, only mitigations.

A malware implant built to hide

Once code execution is achieved, investigators found attackers dropping a compact, statically linked Rust binary roughly 1.9MB in size, compiled for both x86-64 and ARM64 architectures. The implant disguises itself in the process list as an innocuous kernel worker thread, using a name resembling [kworker/u:8:0], and communicates over Redis connections rather than conventional outbound web traffic. Researchers also noted discrepancies between the binary running in memory and any copy left on disk, a technique specifically intended to frustrate standard forensic and antivirus scanning.

That combination, a native-code implant, disguised process naming, and non-HTTP command channels, points to an operator with meaningful investment in evading detection on compromised e-commerce infrastructure, rather than an opportunistic script.

What store operators can do right now

With no official patch available, defenders are largely limited to reducing the attack surface until Adobe responds. Recommended interim steps include:

• Temporarily disable GraphQL entirely on storefronts that do not rely on a headless frontend, closing off the primary injection path.
• Apply the unofficial, community-published hardening patches released by Sansec, ProxiBlue, or Graycore while an official fix is pending.
• Disable PHP’s proc_open function where it is not explicitly required by store functionality.
• Mount temporary directories with the noexec flag so dropped files cannot be executed even if planted.
• Actively monitor the var/report and var/log/system.log directories for the artifacts and error markers associated with exploitation attempts.

Security teams should also review outbound Redis and unusual process activity on commerce servers, since the implant’s disguise is aimed at passing a casual glance rather than close inspection.

A reminder that patch compliance is not the whole story

StyleSmuggler is a sharp illustration of a problem that goes beyond Magento: attackers increasingly succeed by chaining together a platform’s own trusted features rather than exploiting an obviously “broken” one. A fully patched, well-maintained store was still compromised, which means version currency alone cannot be treated as proof of safety. Until Adobe ships an official fix, e-commerce operators running Magento or Adobe Commerce should treat GraphQL exposure and email-template rendering as active risk areas, not routine infrastructure, and apply the available community mitigations without waiting for a CVE to make it official.