CRITICAL: Magento and Adobe Commerce Zero-Day Exploited With No Patch Available

There is a particular flavor of bad news in this business. It is the kind where the vulnerability is real, the exploitation is confirmed, the victim count is climbing, and the vendor has not said a word. That is exactly where Magento and Adobe Commerce operators found themselves this weekend.

Dutch e-commerce security firm Sansec published an advisory on September 5 describing an unauthenticated remote code execution chain it named StyleSmuggler. The short version is that anyone who can reach your storefront over the internet can run code on your server without logging in, without a valid account, and without any interaction from you or your staff. The chain ends in a persistent backdoor. As of this writing Adobe has not published an advisory, has not requested a CVE identifier, and has not shipped a patch. The Adobe Commerce security bulletin index still stops at the August 11 update. The next scheduled release is September 8, and nobody outside Adobe knows whether it will cover this.

The attacks, meanwhile, are happening right now. Sansec caught the campaign on September 4 at 22:40 UTC, and its eComscan product began finding the implant across multiple unrelated stores within half an hour of that. The first confirmed hit on a customer store landed at 22:20 UTC that same evening. Blocking rules went live at 07:15 UTC on September 5. That leaves roughly an eight hour window in which stores were being compromised and no defense existed anywhere, because nobody knew the bug existed.

Fully patched did not save anyone

The detail that should make every Magento operator sit up straight is the profile of the first known victim. That store was running 2.4.6-p15 with both the July and August 2026 security patches applied. By every reasonable measure it was a well maintained installation. It got owned anyway.

Sansec then reproduced the entire unauthenticated chain on clean installations of Magento Open Source 2.4.7, 2.4.8, and 2.4.9. Not a customized build with a sketchy third party module bolted on the side. Clean, out of the box, freshly installed. Their conclusion is blunt, which is that all current versions are affected including the newest one. If you were hoping to land on the safe side of a version cutoff, there is not one to land on.

How the chain actually works

StyleSmuggler is elegant in a way that is genuinely irritating to defend against, because it does not hinge on one obvious injection point you could park a rule in front of. It abuses two of Magento's own subsystems in sequence, and each half looks reasonably innocuous on its own.

Stage one is the poison. The attacker gets PHP code written into a file that Magento itself creates, typically a failure report under var/report/. The injection travels through Magento's template system by way of the styles properties, which is the smuggling half of the name. Routing the payload through styles lets it slip past safeguards that were built to catch more direct template directive abuse. Sansec observed the injection arriving as POST requests to /paypal/transparent/response/ carrying eval statements, and as GraphQL requests using styles parameters.

Stage two is the trigger, and this is the part worth admiring through gritted teeth. Rather than hunting for some exotic way to make the server include that poisoned file, the attacker simply causes Magento to send its own standard Payment Transaction Failed Reminder email. Magento renders the message, the rendering pulls in the attacker controlled file path, and the code executes server side. Nobody has to open the email. Nobody has to click anything. Execution happens during rendering, on your server, entirely inside behavior the application considers normal. Researchers at Disrex traced the far end of the chain and found that manipulated directives inside the injected text push Magento's dependency injection compiler into including an attacker chosen file path that was previously poisoned through the logs.

What lands on the box

Post exploitation is where this stops looking like a smash and grab and starts looking like somebody who intends to stay a while. The payload is a Rust based implant that runs disguised as a fake kernel thread named kworker/u:8:0. On a busy server that is close to invisible in a process listing, and the one tell is that a genuine kernel worker thread does not run as an unprivileged user. If you spot a kworker owned by anything other than root, something has gone badly wrong.

The implant writes itself to a hidden gvfsd directory under the web user's home, specifically .local/share/.gvfsd/gvfsd-user, and drops lock files in that same directory and in /tmp using an eight character hex suffix, alongside a marker file under /tmp beginning with .kw_ and a random string. Persistence comes from a cron entry that fires every five minutes and re-executes the implant, so killing the process without pulling the cron line buys you exactly three hundred seconds of relief.

Command and control runs over WebSocket wrapped in TLS to 99.84.67.186 on port 443, with windwsecurity.run on 443 acting as a remote shell channel. There is also traffic deliberately shaped to look like NTP going to ntp.timesysnc.net, time.microsft.run, and pool.microsft.studio on port 123, which is a thoughtful touch given how many networks wave outbound 123 through without a second glance. Malware staging came from 247.cdnflare.xyz, and attacker traffic was seen from 88.216.72.181 and in bulk from 5.181.86.133. Read those domain names twice. The strings microsft and timesysnc are typo squats built to survive a tired analyst skimming a proxy log at the end of a shift.

Known implant samples start with the SHA-256 prefixes e315687a, 8334b434, and 251fabd5, with the full hash values published in the Sansec and Disrex writeups.

There is one genuinely encouraging note in all of this. In the two Magento Open Source stores that Disrex documented in detail, one on 2.4.8 and one on 2.4.7-p2, investigators found no data exfiltration, no rogue admin accounts, no payment card skimmer, and no database backdoor. Both incidents were contained within eleven to fourteen hours of discovery. That is not evidence the actor is benign. It reads far more like an operator who prioritized establishing broad access first and had not yet decided how to monetize it.

What to do before Adobe says anything

Since there is no patch, everything available to you right now is containment.

Sansec's headline recommendation is to temporarily disable GraphQL until Adobe ships a fix, since it is one of the observed delivery paths. For plenty of storefronts that is genuinely disruptive, and you will have to weigh it against your own exposure and your own front end architecture, but it is the single highest leverage move on the table today.

Hunting is the next priority. Search var/report/ and var/log/system.log for the marker strings X_TRACE_ and X-TRACE-, both of which appear in the injection attempts. Watch for unexplained bursts of Payment Transaction Failed Reminder emails, because the attack has to generate them in order to fire. If a customer or a staff member forwards you a failed transaction notice with raw template variable tags visible in the body, that is not a cosmetic rendering bug, that is somebody actively probing your store.

On the host side, look for that kworker process owned by a non root user and check every crontab for the five minute gvfsd-user entry. If you already run eComscan, version 1.9.7 is the release that detects and terminates this implant, and it is worth knowing that the default scan scope missed infections in early cases because the payload lives in user home directories rather than the document root. Widen your scan paths accordingly.

For hardening, add proc_open to PHP's disable_functions list and mount /tmp, /var/tmp, and /dev/shm with noexec. Neither measure stops the injection itself, but both make the second half of the attacker's day considerably more difficult.

Unofficial patches exist and deserve a look while you wait on Adobe. Disrex and ProxiBlue independently published matching guards that stop the dependency injection scanner from executing outside a CLI context, and Graycore released a module that hardens three separate points in the chain. Third party patches always carry their own risk and you should read the diff before applying anything, but a reviewed community fix on a production storefront still beats an unpatched zero-day under confirmed active exploitation.

If you do find the implant, treat the entire host as compromised rather than cleaning the one binary and moving on. Rotate Magento admin credentials, API keys, database passwords, and anything else the web user could read out of env.php, because a Rust implant with a five minute cron and a live shell channel has had ample opportunity to read all of it.

The business angle

Every client running a Magento or Adobe Commerce storefront is a phone call worth making today, and that call converts unusually well precisely because the vendor has no patch, which means what you are selling is not patch management but detection, containment, and virtual patching that a store owner cannot buy off a shelf. This is close to ideal packaging territory for managed e-commerce monitoring, compromise assessments, and an incident response retainer, because a merchant who has just learned that the first known victim was fully patched is a merchant who finally understands why continuous monitoring is a line item rather than a luxury.