Adobe's Magento Hotfix for CVE-2026-75650 Is Step 1 of 15, and the Patch Was Never the Problem

Adobe shipped an emergency hotfix for CVE-2026-75650 on Monday, September 7, a day ahead of its own scheduled security release, for a Magento and Adobe Commerce flaw rated CVSS 10.0 that attackers had already used to plant a Rust backdoor on live stores. Adobe states in its knowledge base that it is "aware that CVE-2026-75650 has been exploited in the wild targeting Adobe Commerce merchants." CISA added the CVE to its Known Exploited Vulnerabilities catalog the following day, September 8, with a federal civilian remediation deadline of September 11.

Every wire story this week ends at the same instruction: apply the hotfix. That instruction is correct, and it is the smallest part of the job.

Three things the coverage mostly leaves out. There is no single hotfix, because Adobe ships seven different patch files keyed to your exact version, and the widely linked VULN-39341-composer-patches.zip is the right file for only one band of them. Adobe itself concedes you cannot easily tell whether the fix took. And the patch is step 1 of a 15-step credential rotation in which Adobe warns, in its own words, that rotating the Commerce encryption key does not invalidate credentials that were already exposed. Meanwhile the finding that came out of the first week of this campaign has not aged at all: the store that fell 50 minutes after the first observed exploitation was fully current, and a Sansec Shield customer besides.

Adobe Ships Seven Patch Files, Not One

There is no single StyleSmuggler hotfix. Adobe's Commerce knowledge base for bulletin APSB26-146 carries a version-to-patch table with seven distinct files. The composer zip that has circulated in most write-ups covers the current release plus the -2026-aug and -2026-jul bands and recent patch levels. Separate files exist for 2.4.8-p3 and p2, for 2.4.8-p1 and 2.4.8, for 2.4.7-p8 and p7, for 2.4.7 through 2.4.7-p6, for 2.4.6-p13 and p12 with their 2.4.5 and 2.4.4 equivalents, and for 2.4.6 through 2.4.6-p11 with its equivalents. Download the headline zip against the wrong version and you have patched nothing.

Adobe confirms the affected ranges as Adobe Commerce 2.4.4 through 2.4.9, Adobe Commerce B2B 1.3.3 through 1.5.3, and Magento Open Source 2.4.6 through 2.4.9. That is effectively every supported line.

Then there is the verification problem, and it is Adobe's own admission rather than an outside criticism: "it isn't possible to easily determine if the issue was patched." Its remedy is the Quality Patches Tool, running vendor/bin/magento-patches -n status and looking for the VULN-39341 entry to read Applied. Adobe scopes that note to Commerce on Cloud merchants. A flaw where the vendor tells you visual inspection will not settle whether you are exposed is a fair argument for treating this as a vulnerability management problem with a verification step, not a patch you tick off a list.

Fifty Minutes, and Patch Level Did Not Matter

The earliest exploitation anyone has timestamped is September 4 at 22:20 UTC, per The Hacker News. Fifty minutes later, at 23:10 UTC, the first of two stores handled by Dutch Magento host Disrex Group was breached. That store ran Magento Open Source 2.4.8 and was a licensed, enabled Sansec Shield customer, hit hours before Sansec's first blocking rules for this flaw went live. A second Disrex store, running 2.4.7-p2, a patch level Adobe's version history dates to August 2024 and eight levels behind current, was breached at 00:55 UTC on September 5. Sansec's own account of the first confirmed victim describes a store on 2.4.6-p15 with Adobe's July and August 2026 updates applied, the latest patch level Adobe offered for that line.

Rick Bouma of Disrex put it to The Hacker News plainly: "Patch status was irrelevant here, which is the part merchants most need to hear." Both stores fell inside the window between first observed exploitation and the existence of any defence at all. This is the second time in ten days that a flaw with no vendor fix has been exploited across every version of a product, after the PaperCut all-versions zero-day, and it is why the zero-day vulnerability case keeps arriving as a coverage problem rather than a patching one.

My read: the notable thing about StyleSmuggler is not that a fix was missing for three days. It is that patch currency, the single metric most merchants actually have, gave no signal in either direction. The current store and the two-year-stale store had the same day.

Timeline of the StyleSmuggler campaign, September 4 to September 11, 2026. Two windows are marked: the gap between first exploitation and the first blocking rules, which both breached stores fell into, and the roughly three days before Adobe's emergency hotfix existed. Sources: Sansec, Disrex Group, Adobe APSB26-146, CISA KEV.

A Vendor Scanner Reported the Store Clean With 1,728 Cron Lines On It

The most transferable failure in this incident has nothing to do with Magento. On September 5 at 10:00 UTC, roughly 11 hours after the implant first ran, Sansec's eComscan ran against the first Disrex store and reported it clean. At that moment the store carried 1,728 malicious cron lines. Disrex attributes the miss to scan scope rather than to the scanner itself: the scan was pointed at the document root, and the implant installs under the account home directory at ~/.local/share/.gvfsd/, one level above. Disrex says it will confirm the eComscan build number separately. This is a third party's account of another vendor's product, and it should be read that way.

Two scoping corrections follow from it. Point scheduled scans above the web root, not at it. And hash the running process from /proc/<pid>/exe as well as the file on disk, because on one store those were different builds.

A third correction comes from the hunt guidance itself. Sansec's published check searches var/report/ for a marker string. Disrex says both of its infections were poisoned through var/log/system.log instead and would have been missed, and that the marker drifted within a single day. Search both directories, and match the shape of the marker rather than a literal string.

Blocking the Address in the Advisory Stops Under a Quarter of It

Disrex recorded 26 distinct source addresses across its two stores, deduplicated from its own nginx logs after an earlier count of 28 turned out to include two of its own verification servers. Two were hosting infrastructure; the rest was a residential proxy pool sending two to six requests each. Blocking the single attacker address named in Sansec's advisory would have stopped less than a quarter of the traffic Disrex actually saw. That is the clearest argument you will get this month for treating indicators of compromise as hunt material rather than as a control.

Used that way, the published indicators are worth having. A process presenting as [kworker/u:8:0] but owned by a non-root user is the implant, since a real kernel thread is owned by root and has no resident memory. Look for ~/.local/share/.gvfsd/gvfsd-user, lock files matching .gvfsd_<8 hex>.lock in that directory and in /tmp, and files matching /tmp/.kw_. Cron entries invoking either path on a five-minute schedule are the persistence. The download host Sansec named is 247.cdnflare[.]xyz.

One conflict is worth carrying unresolved. Sansec lists a download host and a command server; Disrex saw no outbound traffic at all on one store, across two packet captures over 200 MB each, only 28 connections to the store's own Redis reading Magento session storage. Neither party has reconciled that, and neither account should be discarded.

The Order to Work In

Sequenced, and the first three are new since Adobe patched:

1. Get the right patch file, not the famous one. Use Adobe's version-to-patch table and match your exact version. Seven files exist.
2. Verify the patch applied. vendor/bin/magento-patches -n status, and look for VULN-39341 reading Applied. Adobe says you cannot tell by looking.
3. Treat the encryption key as attacker-held and rotate at the source. Any store running before September 7 should assume it. Adobe's procedure runs from hotfix through maintenance mode, cron disable, crypt key rotation, every admin password, every REST, SOAP and GraphQL integration token, OAuth client secrets, then payment gateway API credentials at the provider, database credentials, SSH and deploy keys, third-party shipping and tax keys, cache flush, cron re-enable, and a Cloud redeploy. Adobe's warning is the load-bearing line: rotating the key does not invalidate credentials already exposed.
4. Look for the email. The cheapest early warning costs nothing: an unexpected "Payment Transaction Failed Reminder" in which the template variables never resolved, a body full of raw tags, a customer address on a .invalid domain, a total of zero. One of Disrex's two compromises surfaced exactly this way, forwarded by the merchant, with the implant found inside the hour.
5. Search both log locations and match the pattern, not the string. As above.
6. Set two server-level controls. Add proc_open to PHP's disable_functions, because at one store four of the six functions the dropper tried were already disabled and proc_open was not. Mount /tmp, /var/tmp and /dev/shm noexec. Disrex notes that open_basedir did nothing to contain the child process.
7. Add the process check for a bracketed kernel-thread name owned by a non-root user. Write it against the command line, not the comm field, which will not match.
8. Widen scanner scope above the document root and hash from /proc.
9. If infected, order matters. Preserve evidence first. Remove the cron entry before killing the process, because the process restores it. Do not reboot, since the copy under /proc may be the only remaining binary. Do not run composer install to clean up, because it overwrites the timestamps showing what was touched.
10. If you genuinely cannot patch yet, Sansec's interim advice for non-Shield stores is to disable GraphQL temporarily. That is free for most classic and Hyva storefronts and an outage for headless and PWA ones, so price it before you do it.

One caveat belongs in the open. Much of the operational detail above comes from Disrex's public incident repository, and that repository warns about itself: its README says it was written with AI assistance during a live incident in a few hours, has not been reviewed, its Apache rules were never run against a live Apache server, and most cleanup commands were written rather than executed. Disrex's own guard was tested on a harness rather than inside a running store, and Disrex says it is not a complete fix by itself. Useful, published fast, and not a substitute for testing in your own environment.

For where this sits in the site's Magento coverage: the earlier Mirasvit plugin RCE was a third-party extension problem. This one is the platform.

No source has said how many stores are compromised, and none has named the attackers. Previdian's honeypots logged 12 attempts from two addresses since September 7, all unsuccessful, which tells you the campaign is still probing and nothing about its real-world hit rate. Do not read either figure as scale.

Primary Documents

• Adobe Commerce knowledge base: Urgent Action Required, Critical Security Update Available for Adobe Commerce (APSB26-146)
• Sansec: StyleSmuggler, Magento and Adobe Commerce RCE (CVE-2026-75650) under active attack
• CISA: Four vulnerabilities added to the Known Exploited Vulnerabilities catalog, September 8, 2026
• The Hacker News: Adobe patches Magento zero-day exploited to deploy Rust backdoor and PHP web shell (September 8, 2026)
• Disrex Group: StyleSmuggler mitigation and incident response repository