On September 5 the Dutch e-commerce security firm Sansec published an advisory on StyleSmuggler, the name it gave to an unpatched flaw in Magento and Adobe Commerce that gives an unauthenticated attacker remote code execution on the store’s server. The advisory puts the first attacks on September 4, and went out early, in its own words, because stores are being compromised right now. Adobe has issued no patch, no CVE identifier and no advisory of its own; per the same document, its enterprise support confirmed on September 7 that a fix is in progress, without a date. For hosting providers the detail worth pausing on is what the first known victim was running: 2.4.6-p15, with the July and August 2026 security updates applied and a clean patch status.
Key facts as of September 7, 2026, 13:29 UTC, the timestamp on Sansec’s advisory
- What it does: unauthenticated remote code execution, followed by a persistent backdoor. Sansec reproduced the full chain on clean Magento Open Source 2.4.7, 2.4.8 and 2.4.9, and says all current versions are affected.
- Interim mitigation: temporarily disable GraphQL until Adobe ships a fix, for anyone not running Sansec’s own blocking product.
- Adobe: no bulletin, no CVE. The next scheduled security release is September 8, and Adobe has not said whether it covers this flaw.
- Where the implant lives: under the site user’s home directory or in /tmp, not the web root, disguised as a kernel thread or a system process. Persistence varies, and Sansec says an empty crontab is not evidence that a host is clean.
- Session storage is not a defence: moving sessions to Redis or the database does not stop the attack, per the advisory.
The Two Stores That Were Hit, and the Window They Fell Into
Two of the compromised stores were hosted and handled by Disrex, a Magento hosting and development company that ran them on its own infrastructure under its RexHosting brand, and which described the incident in answers to The Hacker News. Both were Magento Open Source rather than Adobe Commerce. One ran 2.4.8 and was a customer of Sansec’s blocking product, with the module installed, enabled and licensed, and was hit at 23:10 UTC on September 4, hours before the first rules for this flaw went live. The other ran 2.4.7-p2, a patch level from August 2024, and was hit at 00:55 UTC on September 5. Sansec’s own timeline dates the first confirmed exploitation to 22:20 UTC on September 4 and its first blocking rules to 07:15 the next morning, so both stores were breached before rules for this flaw existed.
One of those stores had a commercial blocking layer active and was still hit, because the rules for this flaw did not exist yet. The first victim Sansec identified makes the patching point more directly: it ran 2.4.6-p15, with the July and August security updates applied and a clean patch status, which The Hacker News notes is the latest patch level Adobe offers for that release line.
Two Stages, With a Failed Payment Email as the Trigger
The advisory describes the flaw as an injection into Magento’s template system, using what it calls the styles properties, which is where the name comes from, to get past existing safeguards. It works in two stages. First the attacker poisons PHP code, in the example given there, by causing the store to generate a failure report. Then Magento executes the poisoned code itself, while rendering a failed payment email. Nobody has to open that message, and Sansec says the attack can succeed even when the delivery fails. Hardening the session layer does not help: one merchant reported an attempt that failed against session storage and, eight seconds later, a second attempt from the same operator that succeeded by using a file uploaded through Magento’s custom options instead. Sansec is treating the investigation as open, and calls the operators quick to iterate.
The Implant Lives Outside the Web Root
The backdoor is the reason this belongs on a hosting operations list, not just a merchant’s. Sansec describes a small Rust program that runs under a borrowed name: [kworker/u:8:0], which belongs to a Linux kernel thread, then fc-cache in the September 6 builds, and from September 7 chronyd, the real name of the time daemon on most Linux systems. It installs under the site user’s home directory or in /tmp rather than the web root, at paths such as ~/.cache/fontconfig/fc-cache, or in a hashed directory under /tmp. On one host the implant simply renamed itself, keeping the same agent identifier, so a second process name is not necessarily a second infection.
Persistence varies between hosts. Some builds install a cron entry, written straight into the spool file rather than through crontab, so the system log records no replacement. One store carried the same line 1,728 times and the implant restored it within a second of removal, Disrex told The Hacker News. Other builds relaunch themselves with no cron entry at all, which is why Sansec now says plainly that an empty crontab is not evidence that a host is clean, and that the spool file should be checked directly as well, rather than relying on the output of crontab -l.
The beacon is dressed as time synchronization, according to the same advisory. Every 60 seconds the implant resolves a hostname beginning ntp and sends 48-byte UDP packets to port 123 that look like NTP server replies, which passes most egress filtering unremarked. Only the first four bytes are really NTP; the rest carries the agent identifier, hostname, username, operating system version, memory and disk usage, uptime and whether it is running as root. Two tells separate it from a real client: it emits nine datagrams about ten milliseconds apart where a client sends one, and every datagram is marked as a server reply, which a client has no reason to send.
What to Do Before Adobe Ships
The mitigation Sansec offers to anyone outside its own product is to disable GraphQL temporarily. That is a store-level decision rather than a host-level one, and it is not free: headless and progressive web app storefronts depend on GraphQL, while classic and Hyvä storefronts generally do not, so the conversation with each merchant differs.
On the host’s own side there is more to work with, and one item is free. Where the web user cannot write a crontab, the implant keeps trying once a minute and every attempt is logged as crontab: (www-data) AUTH (crontab command not allowed). At the merchant who reported it, www-data sat in /etc/cron.deny, which blocked persistence outright and left thousands of those lines in syslog; the first of them dated the infection more than a day before anyone noticed the process. Grepping authentication logs for that string costs nothing, and it finds the attempt on hosts where the write was refused.
Beyond that, Sansec’s advisory lists the process names, the paths under the site user’s home and in /tmp, and the indicators to block. It also notes that removing the background process is not enough: a separate actor has been arriving through the same flaw and dropping a web shell into the product image cache, under the hash-named directories in pub/media, where one extra PHP file is easy to miss. Sansec’s own Shield and eComscan come first among its recommendations, and its published indicators can be checked across a fleet independently of either. Adobe’s next scheduled release falls on September 8, and whether it addresses StyleSmuggler was still unknown when this was written.
About the Data
Technical detail, affected versions, indicators and mitigation come from Sansec’s StyleSmuggler advisory, read on September 7, 2026 at the timestamp shown above; the advisory is being updated through the day as the investigation continues, so everything here is a snapshot of that moment. The account of the two hosted stores, their timings and the implant’s behaviour on them comes from Disrex’s answers to The Hacker News. Adobe had published no advisory or CVE for this flaw at the time of writing.
