Adobe told Commerce merchants to rotate their payment gateway keys. The coverage stopped at the patch.

Adobe broke its own monthly cadence on Sunday evening to publish APSB26-146, an out-of-band bulletin for CVE-2026-75650 in Adobe Commerce and Magento Open Source. The bulletin went out at 20:20 UTC on 7 September with Adobe’s highest priority rating.

The sentence that matters is in Adobe’s knowledge base article, and it is not hedged:

“Adobe is aware that CVE-2026-75650 has been exploited in the wild targeting Adobe Commerce merchants.”

The National Vulnerability Database record, published at 21:17 UTC the same evening, carries a CVSS 3.1 base score of 10.0 with the vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, and the score is assigned by Adobe’s own PSIRT rather than by NVD analysis. Network reachable, low complexity, no privileges, no user interaction, and a scope change. It is a template engine injection that gives arbitrary code execution.

Every supported branch is affected: Adobe Commerce 2.4.4 through 2.4.9, Commerce B2B 1.3.3 through 1.5.3, and Magento Open Source 2.4.6 through 2.4.9, in each case the 2026-aug release and everything earlier.

What is affected, and what Adobe actually tested the fix against

Product	Affected branches	The hotfix was tested against
Adobe Commerce	2.4.4, 2.4.5, 2.4.6, 2.4.7, 2.4.8 and 2.4.9, in each case the 2026-aug release and earlier	The 2026-aug releases only. Unverified on older point releases.
Adobe Commerce B2B	1.3.3, 1.3.4, 1.4.2, 1.5.2 and 1.5.3, in each case the 2026-aug release and earlier	The 2026-aug releases only. Unverified on older point releases.
Magento Open Source	2.4.6, 2.4.7, 2.4.8 and 2.4.9, in each case the 2026-aug release and earlier	The 2026-aug releases only. Unverified on older point releases.

That is the part the coverage got right. Here is the part it stopped short of.

Adobe did not say “apply the patch”

Adobe’s own remediation, at the length Adobe published it

The hotfix is step one. Adobe then lists seven credential rotations, and explains why in a sentence every merchant should read twice:

“Rotating the encryption key alone does not invalidate credentials that may already have been exposed.”

And the reason that matters:

“The encryption key is used to encrypt integration tokens, payment gateway credentials, and system-privileged automation tokens.”

An attacker who reached the encryption key reached everything the key wrapped. A patch closes the door. It does not un-disclose a secret that is already copied.

The step people will skip is step five, because it is the only one that cannot be done inside Commerce at all. Adobe is explicit:

“Rotate all associated credentials at their source (for example, at the payment gateway or third-party service), not only within Commerce.”

Adobe names Stripe, Braintree, Adyen and PayPal. Rotating those inside your own admin panel achieves nothing, because the credential that was exposed is the one the provider holds.

The patch level you are on is not a defence

Sansec, which detected the campaign it calls StyleSmuggler, published its analysis on 5 September and has been updating it since. Two findings in it are worth more than the bulletin.

The first is that a store running 2.4.6-p15 with the July and August 2026 security patches applied, and reporting a clean patch status, was compromised. Being current was not protection, because until Sunday there was nothing to be current with.

The second is a limitation Adobe’s own testing carries. Adobe tested the hotfix against the 2026-aug releases. In Sansec’s words: “Older versions in those branches are affected too, but the patch is unverified there.” If you are running an older point release, you should still apply it, and you should verify the result yourself rather than assume it.

Sansec also declines to claim something it cannot evidence, which is worth noting because it cuts against its own commercial interest: “So far, we have no indication that the backdoor has been weaponized.” The implant was deployed. Whether it was used for anything is not established. That distinction is the difference between an urgent remediation and a panic, and it is the sort of qualifier that disappears in aggregation.

On timing, the arithmetic is straightforward. Sansec records the first confirmed exploitation at 22:20 UTC on 4 September. Adobe published at 20:20 UTC on 7 September. Seventy hours, over a weekend, for an out-of-band fix to a 10.0. That is fast by any reasonable standard, and it still left three days.

The catalogue has not moved since Friday

Three critical CVEs, and one catalogue that has not moved

CISA’s Known Exploited Vulnerabilities catalogue was at version 2026.09.04 when we checked it at 11:10 UTC this morning, with 1,695 entries. Its most recent addition was made on 4 September, which is before any of the three records above existed.

Adobe’s is not in it. Neither is CVE-2026-86218 in N-able N-central, scored 10.0 by its assigning CNA and published on 6 September. Neither is CVE-2026-67276 in MikroTik RouterOS, scored 9.2 and assigned by CERT Polska, published on 5 September.

We have drawn the exploitation evidence as three different things on purpose, because it is three different things. Adobe states it in its own bulletin in language that cannot be read two ways. The MikroTik claim reaches us through CERT Polska rather than through the vendor. The N-able position is genuinely unclear: the two statements attributed to the company contradict each other on whether exploitation has been confirmed, and we were not able to reach N-able’s own documents to resolve it, so we are not going to assert either version. Reporting all three as equally confirmed would repeat the error we are describing.

None of this is a criticism of the catalogue. KEV exists to bind United States federal civilian agencies under a binding operational directive. It is deliberately conservative, it requires evidence CISA is willing to stand behind, and a British retailer is not its constituency. It is a floor.

The criticism is of how it gets used. A great many organisations, in this country included, have quietly wired KEV into their prioritisation as a trigger: it appears in the catalogue, the change goes to the front of the queue. On any given week that trigger is several days behind the vendor’s own bulletin, and this week it has not fired at all since Friday. If your process was waiting for a KEV entry before treating a 10.0 with vendor-confirmed exploitation as urgent, it has been waiting since before the bulletin existed.

What to do

The position

The interesting thing about this bulletin is that Adobe published something that made it look worse. It did not have to spell out that the exposed encryption key wrapped payment gateway credentials, and it did not have to tell merchants to go and rotate secrets at Stripe. That paragraph is an admission that an affected store should be treated as compromised down to its card processing, and it invites exactly the headline a legal team would fight.

It was the right call, and it is the reason this is a fixable incident rather than a slow one. The failure is downstream: a remediation Adobe wrote as eight steps has been reported as one, and the seven that were dropped are the seven that determine whether the attacker still has access after the patch.

The catalogue will catch up. Adobe’s bulletin is the thing to act on, and it has been actionable since Sunday evening.