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.

On Monday 8 September, Adobe patched it. The flaw is CVE-2026-75650, rated CVSS 10.0, and Adobe confirmed it "has been exploited in the wild targeting Adobe Commerce merchants".

Fixes cover Magento Open Source 2.4.6 through 2.4.9 and Adobe Commerce 2.4.4 through 2.4.9, in the 2026-aug releases, plus B2B 1.3.x through 1.5.3.

The patch is two steps, and the second one is the one people skip

Adobe's remediation is to apply VULN-39341 and rotate the encryption keys.

Both halves are required. The patch closes the door; rotating the keys is what makes the material an attacker may already have taken useless. An estate that installs the update and stops has fixed the vulnerability and kept the consequences.

This is the part that will be under-communicated, because "patched" is a status a dashboard can show and "keys rotated" is work somebody has to do.

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 did not work here. "Are you up to date" is the first question anyone asks after a Magento incident, and for the four days before Adobe shipped, the answer was 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 speed is its own data point. One Magento server run by an e-commerce development platform was compromised 50 minutes after the first confirmed StyleSmuggler report went out at 10:20 p.m. UTC on 4 September. Whatever window existed between disclosure and exploitation, it was under an hour.

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

  • Apply VULN-39341, then rotate your encryption keys. One without the other is half a remediation.
  • 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_.
  • Patching is not clearance. Exploitation ran from 4 to 8 September against stores that were up to date. If yours was reachable in that window, look before you close the ticket.
  • 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.

What is not established

  • The full exploit chain. Sansec has not published it, deliberately.
  • Whether Adobe Commerce on Cloud is affected. Adobe's advisory does not address it.
  • 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.