Every current version of Magento Open Source and Adobe Commerce — including the latest 2.4.9 line, fully patched against every prior known CVE — is exploitable right now by an unauthenticated attacker. Sansec, the e-commerce security firm that has tracked Magecart-style skimmer campaigns for years, disclosed the chain on September 5 under the name StyleSmuggler after finding it already live against real stores. As of this writing, Adobe has assigned no CVE identifier and published no advisory or patch.

What Happened

Attacks began September 4. Sansec’s first identified victim was running Magento 2.4.6-p15 with July and August 2026 security patches applied and a clean security:patch-status — meaning every disclosed Magento vulnerability up to that point had already been remediated. StyleSmuggler doesn’t need any of them; it’s a previously unknown injection path in Magento’s own template and dependency-injection compiler code.

Sansec reproduced the full unauthenticated chain from scratch against clean, unmodified installs of Magento Open Source 2.4.7, 2.4.8, and 2.4.9.

Technical Details

StyleSmuggler is a two-stage attack that never requires a login:

  1. Inject. The attacker sends attacker-controlled data through a storefront-facing input that eventually reaches Magento’s styles handling in the template layer. Rather than being rejected or escaped, this data gets written into a Magento report or log artifact — Sansec’s writeup specifically calls out the standard “Payment Transaction Failed Reminder” email as a trigger, meaning the poisoned content lands in a file Magento generates automatically as part of normal store operation. Nobody has to open the email; the payload just needs to exist somewhere Magento will later read back and render.
  2. Detonate. A second request causes Magento to evaluate that previously-written content. Sansec traces the execution path into Magento’s dependency-injection compiler — the same subsystem normally driven by bin/magento setup:di:compile — which performs a variable-path include on attacker-influenced data. That include is where injected PHP actually runs, giving the attacker full code execution in the context of the web server.

No authentication, no admin panel access, and no plugin or third-party extension is required — this lives in Magento/Adobe Commerce core.

  • Affected: All current Magento Open Source and Adobe Commerce versions, confirmed through 2.4.9, independent of patch level
  • CVE: none assigned as of publication
  • Vendor advisory: none published as of publication
  • Attack vector: Unauthenticated, network, storefront-reachable
  • Disclosed by: Sansec, September 5, 2026
  • First observed exploitation: September 4, 2026

Impact

Successful exploitation hands the attacker arbitrary PHP execution on the storefront server, which in prior Magento incidents has translated directly into persistent backdoors, admin account creation, and payment-skimming code injected into checkout pages — the same objective as the Magecart campaigns Sansec has tracked for a decade, but reached through an entirely fresh, unauthenticated entry point that bypasses every patch a store operator has already applied. Adobe Commerce and Magento Open Source together power a large share of mid-to-large online retail, and because this bypasses patch level entirely, “we’re fully patched” is not a defense right now. Sansec has said stores are actively being compromised as it published.

Mitigation

With no vendor patch available, mitigation is entirely compensating controls:

  • Deploy Sansec’s Shield rules, which went live the morning of September 5 and have reportedly blocked observed StyleSmuggler attempts; refined rules covering both the inject and detonate stages are rolling out on an ongoing basis.
  • Disable GraphQL on the storefront temporarily — Sansec’s specific recommendation until Adobe ships an official fix, since GraphQL is one of the reachable paths into the vulnerable code.
  • Apply WAF rules blocking template-injection markers ({{, <%, ${) in storefront-facing inputs, enforcing strict request-size limits, and disallowing non-GET/POST methods on storefront routes.
  • Restrict bin/magento setup:di:compile and related CLI execution to non-request-triggerable contexts; a CLI guard that refuses non-CLI invocation removes the detonation primitive independent of how the request is shaped, which closes off parameter-relocation bypasses (e.g., moving values into the POST body).
  • Audit for compromise now, not after a patch lands. Check for unexpected admin users, unrecognized cron jobs, modified core template or DI-cache files, and checkout-page JavaScript that wasn’t there before September 4. Community mitigation tooling (e.g., the disrex-group/stylesmuggler-mitigation repo) includes a compromise scanner alongside web-server rules.
  • Watch for the official Adobe advisory and CVE and patch immediately once released — this is an emergency-patch situation, not a next-maintenance-window one.

References