A Magento Zero-Day Is Being Exploited Now, and the First Victim Was Fully Patched

The First Victim Was Fully Patched

Start with the fact that matters most, because it removes the answer most merchants reach for first.

The first store Sansec confirmed compromised was running Magento Open Source 2.4.6-p15 with the July and August 2026 security patches applied. Its security:patch-status came back clean. It was, by every check a merchant is told to run, up to date.

It was compromised anyway, because the flaw has no patch to apply. Sansec published the finding on September 5 under the name StyleSmuggler, and reproduced the full unauthenticated chain on clean installations of 2.4.7, 2.4.8 and 2.4.9. All current versions of Magento Open Source and Adobe Commerce are affected.

Exploitation started before the disclosure. The first confirmed attack was at 22:20 on September 4, and Sansec found the campaign twenty minutes later.

As of this writing there is no CVE identifier, no Adobe advisory and no fix. We checked Adobe's own bulletin index rather than taking anyone's word for it. The most recent Adobe Commerce bulletin is APSB26-92 from August 11, and the index itself is current to August 25, so the gap is real rather than a stale page.

What the Attack Actually Does

StyleSmuggler is an unauthenticated remote code execution flaw, which means an attacker needs no account, no session and no help from anyone inside the business.

It works in two stages. The first plants PHP inside Magento's own template system, reaching it through the styles properties, which is what lets it slip past the safeguards that already exist there. The requests seen at victims take the shape of a POST to /graphql carrying a styles[...] parameter.

The second stage does not run the code directly. It gets Magento to run it, by triggering the platform's standard Payment Transaction Failed Reminder email.

That second stage is the part worth slowing down on.

The Email That Runs Before Anyone Opens It

Nobody has to open the message. The injected code executes while Magento renders it, which happens on the server, before anything is handed to a mail server.

Two consequences follow, and both cut against instinct.

An unexplained burst of failed payment notifications is a reason to look, but a quiet mailbox proves nothing. The attack still succeeds when delivery fails outright, so a store with broken outbound mail is not a store that is safe. It is a store that will find out later.

And there is no user to blame and no training that would have helped. This is not a phishing chain that needed somebody to click. The trigger is a routine, legitimate feature of the platform doing exactly what it was built to do.

What Gets Left Behind

A successful attack starts a background process written in Rust that opens a connection to a command and control server at 99.84.67.186 over TLS and waits.

It hides in the most ordinary place available, presenting itself as [kworker/u:8:0], which reads as a normal kernel worker to anyone scrolling a process list. Persistence is a cron entry running every five minutes out of a dot-directory under the site user's home.

Here is the part that should raise the temperature rather than lower it. Sansec reports no sign yet that the backdoor has been used for anything. It connects, and it waits.

That is not reassurance. A foothold that has not been spent is a foothold somebody is still holding, on a server that processes card payments and holds customer records. The card skimmer, the data export or the ransom note is a later decision by whoever is on the other end of that connection, and it is their decision rather than yours.

Sansec also notes that at publication no security vendor other than Sansec recognised the implant. An antivirus scan coming back clean this week is not evidence of anything.

Check Your Store Now

These checks come from Sansec's published indicators. They take a minute and they need nothing installed.

crontab -l | grep -i gvfsd
ls -la ~/.local/share/.gvfsd/ /tmp/.kw_* /tmp/.gvfsd-* 2>/dev/null
ps -eo pid,comm,args | grep -i kworker
grep -rl 'X_TRACE_' var/report/

Run the last one from the Magento root. A hit in var/report/ is the injection stage leaving its mark in the failure reports the attack generates on purpose.

On the network side, the published indicators are the C2 at 99.84.67.186 on 443, a malware download host at 247.cdnflare.xyz, a remote shell endpoint at windwsecurity.run, and three hosts carrying command traffic shaped to look like NTP on UDP 123. The typosquats are deliberate. A name like time.microsft.run is built to survive a glance at a firewall log.

If any of these turn up, treat the server as compromised rather than as needing a clean-up. Rotate the Magento admin credentials, the database credentials, the API keys and anything else the application could reach, because a process that ran as your site user could read all of it.

What You Can Do Before Tuesday

There is one free measure that addresses the entry point, and it is a real trade-off rather than a free win.

Disabling GraphQL closes the route the attacks are using. It also breaks anything that depends on it, which on a modern store often means a headless storefront, a PWA front end, a mobile app or a third party integration. On a traditional Luma store it usually costs nothing. On a headless store it takes the shop offline, so the honest sequence is to find out which you are before you touch it, not after.

If GraphQL cannot go, the fallback is to block requests whose query string carries a styles[ parameter at the web server or the CDN, ahead of PHP. Several Magento agencies published rules for this over the weekend. Treat those as stopgaps written under time pressure rather than as vetted patches, and prefer a filtering rule you can remove cleanly to an unofficial code change you will have to remember to unwind.

Whatever you choose, write down what you changed and when. On Tuesday somebody has to undo it.

Read the Vendor Advice With One Eye Open

Sansec found this, published it early while stores were being hit, and deserves the credit for both. Their advice is also, in order, buy their blocking product, buy their scanner, and only then the free measure. That is not dishonest and their products may well be the right answer for a large store, but it is a vendor's priority list rather than a neutral one, and it is being reprinted as neutral in most of the coverage.

The same caution applies in the other direction to the unofficial patches circulating. They come from people trying to help at speed, they modify dependency injection code, and nobody has reviewed them the way a vendor patch gets reviewed.

If Tuesday Does Not Fix It

Adobe's next scheduled security release is September 8. Whether it covers StyleSmuggler is unknown, and the schedule was set long before anyone knew this existed.

Plan for the version where it is not covered. That means the mitigation you pick today should be one you can live with for a fortnight rather than one you are counting the hours until you can remove, and it means the compromise checks above are worth repeating after the bulletin lands rather than once tonight.

A store that was already breached on September 4 does not become clean when the patch ships. Patching closes the door. It does nothing about whoever is already inside.

Sources: Sansec, StyleSmuggler, Adobe Security Bulletins index, Adobe Commerce APSB26-92, The Hacker News