Sansec, the Dutch firm that watches Magento for a living, published an advisory on 5 September 2026 on a flaw it calls StyleSmuggler, under active exploitation since 4 September.

As of 6 September there is no CVE, no patch, no Adobe advisory and no vendor workaround.

Affected: Magento Open Source 2.4.6, 2.4.7, 2.4.8 and 2.4.9, and Adobe Commerce. All current versions are confirmed vulnerable. Adobe Commerce on Cloud is unconfirmed either way.

The sentence that matters

The first confirmed victim was running 2.4.6-p15 with the latest August 2026 patches applied.

Fully patched. Compromised anyway.

That is worth sitting with, because the standard advice does not work here. "Are you up to date" is the first question anyone asks after a Magento incident, and this week the answer is not diagnostic. There are at least 2 confirmed breaches, verified through independent incident response by Disrex Group and by hosting providers Nexcess and Liquid Web — three parties who do not share an interest in agreeing.

The email nobody opens

The exploitation is two stages.

First, PHP code is injected into files that Magento itself writes.

Second, execution is triggered through a Payment Transaction Failed Reminder email — and in Sansec's words, "the code runs while Magento renders the message, so no one has to open it."

That is the part worth understanding properly. There is no victim in this chain. Nobody clicks anything, nobody opens an attachment, no customer or administrator makes a mistake. A scheduled job renders a templated email on the server, and rendering it is the execution.

Any control that depends on someone not falling for something is irrelevant here.

The backdoor pretends to be the kernel

What lands is a Rust binary of roughly 1.9 MB, built for both x86-64 and arm64, running as a background process disguised as [kworker/u:8:0].

On Linux, names in square brackets in a process listing are how the kernel presents its own threads. Choosing that name means an administrator scrolling through output sees something they have been trained their whole career to ignore.

It is also a checkable lie. Real kernel threads are children of kthreadd, which is PID 2. A userspace process wearing a kernel thread's name will not have that parent, and it will have things a kernel thread never has — an executable path, memory mappings, open sockets. That check takes one command and it is the most useful thing in this article.

No skimmer, which is the strange part

Magento compromises are almost always about payment card skimming. This one is not, so far.

In one Disrex investigation there was no evidence of data exfiltration, no rogue administrator accounts, no injected payment skimmer and no database backdoor. The attackers established access and did nothing visible with it.

Two readings fit. Either this is staging — access banked now, monetised later or sold on — or the operators are building an inventory to sell. Both are speculation and neither is supported by published evidence, so hold them loosely. What is established is that a persistent backdoor exists on stores where nothing appears to have been stolen, and that "we checked and nothing was taken" is not the same as "we are fine".

Indicators

Files:

  • ~/.local/share/.gvfsd/gvfsd-user
  • ~/.local/share/.gvfsd/.gvfsd_[8 hex].lock
  • /tmp/.gvfsd_[8 hex].lock
  • /tmp/.kw_[random]

SHA-256: e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7 (Sansec), 8334b434fa3fe9f59cebe9609b11e0b1fd19d10212c45c705adec1902a1d06ef (Disrex, disk), 251fabd50d7b18a8b5e1b3ef5d64e7198c17244778f6461fb1ab07f6169bf220 (Disrex, memory).

Network: 247.cdnflare[.]xyz, and 99.84.67[.]186:443, 88.216.72[.]181, 5.181.86[.]133.

Note the .gvfsd naming — it borrows from GNOME's virtual filesystem daemon, another name chosen to be skipped over.

What to do

  • Check the process table for [kworker/…] entries whose parent is not PID 2. This is the fastest possible triage and it costs nothing.
  • Search for the file paths above, particularly anything matching /tmp/.gvfsd_ or /tmp/.kw_.
  • Do not wait for the patch to start looking. Exploitation began on 4 September and the vendor has published nothing. Detection is the only thing available.
  • Treat "we are on the latest patch" as irrelevant to this one. The first victim was.
  • Review what your Magento process can write, and whether templated emails need to render with the permissions they currently have. The injection target is files Magento writes itself.
  • Watch Sansec rather than the CVE feed. There is no CVE, so vulnerability scanners have nothing to key on.

What is not established

  • The full exploit chain. Sansec has not published it, deliberately.
  • Whether Adobe Commerce on Cloud is affected.
  • How many stores are compromised. Two are confirmed; the real figure is unknown.
  • Whether the installed backdoors have been used since installation.
  • Who is behind it.
  • Whether the unofficial patches circulating are complete. Nobody has verified them against an unpublished chain.