StyleSmuggler: Magento zero-day actively exploited.

StyleSmuggler is a chain of two steps that are each harmless on their own.

Step 1: the attacker sends an unauthenticated request with a payload that Magento dutifully writes to its log file. What ends up in var/log/system.log is valid PHP code.

Step 2: through a template directive, the attacker gets to choose which class Magento instantiates, constructor arguments included. That chain reaches an autoloader from the AWS SDK, which simply includes a given file. That autoloader only checks whether the file exists, never what is in it. And PHP draws no distinction between code files and text files: everything between the PHP tags gets executed, whether the file is called .php or .log.

So Magento logs the code, and an autoloader includes the log file. Net result: unauthenticated remote code execution. No admin account needed, no API key, no click from an employee.

The first assumptions were wrong, by the way. In the early hours several parties thought it lived in the PayPal module, because that was the visible entry point. The flaw is in the template parser. Disabling PayPal or blocking the Payflow URL does not stop variants — that was later tested explicitly.

Magento Open Source and Adobe Commerce 2.4.6 through 2.4.9. The first victim Sansec found was running 2.4.6-p15 with the July and August 2026 patches neatly applied. So patch level tells you little here: at the time of the attack there simply was no patch.

At the time of writing there is no official Adobe patch and no CVE number. Adobe has a security release scheduled for 8 September, but we do not expect StyleSmuggler to be in it — that release was on the calendar long before this zero-day. So count on patching again later this week, once the real fix lands.

Two layers did the heavy lifting, and neither needed a patch.

Hypernode updated the WAF on their platform with rules that block this attack traffic. That applied immediately to every shop running there, without any action from us or from you. On top of that we run Sansec Shield for all our clients, which was blocking from 07:15 UTC onwards — well before any patch, CVE or even a public writeup existed.

In the meantime we have also added protection at application level using an unofficial community patch. It installs as a Magento module and closes three entry points: backend blocks in email template directives, validation of the URL generator classes in grid rows, and neutralising PHP open tags in Web API error reports. It is hardening, not a fix — but it means we are not entirely dependent on WAF rules.

This is exactly why we set up those layers by default instead of debating them per shop. With a zero-day there is no patch to wait for. The question is not whether you are patched, but how quickly something blocks on your behalf and how quickly you notice that something got in.

Are you a client of ours? Then you are already covered. There is nothing for you to do.

Shop not with us? Here is the short overview.

• Assume "possibly hit" if your server was online during the night of 4 to 5 September, until you have proven otherwise. Not the other way around.
• Search your access logs for requests containing styles[. A 500 response on such a request is a useful detection signal: that is the include that failed.
• Check for processes masquerading as kernel threads (bracketed names not owned by root), cron entries that do not belong, and outbound traffic to unknown hosts over unusual ports. Note: the attackers changed process names and payload hosts within a day, so fixed names are a hint, not a checklist.
• Do not reboot and do not delete anything before you have a backup for forensics. A deleted binary that is still running is easy to lose.
• Temporarily block /graphql at web server or firewall level if you do not use it. If you run Hyvä Checkout or other GraphQL consumers that is not an option, and you will have to rely on your WAF and the patches.
• Apply the emergency patches that make the DI scanners CLI-only. That closes the sink, including for POST variants that slip past WAF rules.
• Add protection at application level with the unofficial community patch. Installs as a module through composer and closes three entry points. Test it on staging first: it is a stop-gap with no warranty.
• When in doubt, rotate your credentials: admin accounts, API keys, database passwords and integration tokens.
• Patch as soon as Adobe ships a fix, and keep an eye on Shield updates while new entry points keep surfacing.

The lesson from this weekend is not "patch faster". The first attack happened a full day before anyone knew what to look for, and the first victim was fully patched. Exploitation now comes before discovery.

What does work: layers that are already in place before you need them, and someone paying attention on a Saturday afternoon. Our Magento Total Care subscription includes security patches, monitoring, Sansec Shield and this kind of incident response as standard. No separate quote per emergency, no debate about who gets to work the weekend.

Questions about your own shop? Call or email us, even if you are not a client.

For anyone who wants to retrace it: how this weekend unfolded hour by hour. All times in UTC.

• 4 Sep, 22:20 — first confirmed exploitation. Another shop later finds a hit in its own logs at 22:42. At that point no public writeup exists: exploitation is running ahead of discovery.
• 4 Sep, ~23:10 — a managed Magento server is hit, fifty minutes after the first.
• 5 Sep, 00:59 — one of the affected parties has contained the incident that same night and guarded the vulnerable sink in code. Still eight hours before a detection rule exists anywhere.
• 5 Sep, 07:15 — Sansec Shield starts blocking. No patch, no CVE, no publication: purely based on observed attack traffic.
• 5 Sep, around 11:50 — the first reports come in across the Magento community: suspicious background processes on completely unrelated shops. The only common denominator is Magento on Hypernode. Shortly after, the pattern becomes clear: a payload writes executable PHP into system.log. How that code then gets executed, nobody knows yet.
• 5 Sep, around 11:55 — first stopgap doing the rounds: symlink the log files to /dev/null, after taking a backup for forensics. Treating the symptom, but it removes the fuel.
• 5 Sep, 12:19 — Sansec publishes the StyleSmuggler research and gives the vulnerability a name. Around the same moment the full chain is reconstructed, including the stack trace proving how the log file ends up being included.
• 5 Sep, ~12:54 — Sansec ships an emergency cleanup through eComscan v1.9.6 that kills the processes masquerading as kernel threads.
• 5 Sep, around 13:00 — reinfection. Cron entries and binaries return within minutes on affected servers. Cleaning up is pointless while the door is still open.
• 5 Sep, 14:57 — Hypernode rolls out a platform-wide patch that blocks the incoming attack traffic, followed by cleanup of affected servers and additional endpoint security on those nodes.
• 5 Sep, 22:28 — at one affected shop another poisoned report is written. The chain does not complete, but the payload host, the process names and the delivery vector have all changed compared to the first wave. The attackers iterate in hours, not days.
• 5 and 6 Sep — a public mitigation repo appears with a cleanup guide and emergency patches that make the vulnerable DI scanners CLI-only. Cloudflare WAF rules circulate in the community. Sansec keeps updating Shield as they find alternative entry points.
• 6 Sep — the emergency patches are tested against a working proof of concept on fully patched 2.4.6 and hold up.
• 7 Sep — still no official patch, still no CVE. Adobe's security release is scheduled for 8 September.

• Sansec — StyleSmuggler research
• Disrex — technical analysis and emergency patches
• Mitigation repo with cleanup guide and patches