Adobe published APSB26-146 on Monday, September 7, 2026, confirming that a CVSS 10.0 unauthenticated code-execution flaw in Adobe Commerce and Magento Open Source is being exploited — and the remediation it names is a hotfix, not a version.
What happened
Adobe published security bulletin APSB26-146 on September 7, 2026 — a US federal holiday, and the day before its regularly scheduled September release. The summary reads, in full: “Adobe has released a security update for Adobe Commerce and Magento Open Source. This update resolves a critical vulnerability that could result in arbitrary code execution.”
The vulnerability is CVE-2026-75650. Adobe’s vulnerability details table gives the category as “Improper Neutralization of Special Elements Used in a Template Engine” (CWE-1336), the impact as arbitrary code execution, the severity as Critical, and “Authentication required to exploit” as No. Adobe scored it 10.0, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, priority rating 1 — its most urgent tier.
On exploitation, the bulletin says one sentence: “Adobe is aware of CVE-2026-75650 being exploited in the wild.” That is the vendor confirming active exploitation in its own words — not an attacker claim, and not a researcher inference.
The affected list is broad. Adobe Commerce is listed at every branch from “2.4.4-2026-aug and earlier” through “2.4.9-2026-aug and earlier,” on all platforms. Adobe Commerce B2B covers 1.3.3 through 1.5.3 on the same pattern, and Magento Open Source covers 2.4.6 through 2.4.9. In practice that is every supported branch of both products.
The NVD record went live the same evening, published at 2026-09-07T21:17:30.863, vulnStatus Received, assigner [email protected], with exactly one reference: the Adobe bulletin. Two retrievals using different URL forms returned no cisaExploitAdd, cisaActionDue, cisaVulnerabilityName, or cisaRequiredAction. As of this writing the CVE is not in CISA’s Known Exploited Vulnerabilities catalog, and no federal remediation deadline exists for it.
Then there is the fix. Adobe’s solution table has one row, and its “Updated Version” column does not contain a version. It contains the string “Hotfix for CVE-2026-75650.” NVD renders the same thing: every branch listed affected, and the unaffected entry given as the literal text “Hotfix available.” There is no 2.4.9-2026-sep, no p-level, no build number that means “fixed.”
The researcher trail runs ahead of the bulletin. Sansec, a Netherlands-based firm that specializes in Magento security, published a writeup titled “StyleSmuggler: Magento and Adobe Commerce 0-day RCE (CVE-2026-75650) under active attack.” Its page metadata carries a published timestamp of September 5, 2026 and a last-modified timestamp of September 7, 2026 at 8:50 p.m. UTC, while BleepingComputer and Security Affairs both date the writeup to September 7. Those dates conflict, and we have not resolved which is original. The article body did not render through this session’s fetch path.
What follows is therefore attributed to Sansec via secondary coverage, not read from Sansec directly. Both outlets report Sansec first recorded exploitation on September 4, 2026, and both describe a two-stage mechanism: attacker-controlled PHP is smuggled into Magento’s template system through a styles property, then executed later when the store renders an ordinary failed-payment notification email. The payload is a compact Rust backdoor that hides behind borrowed Linux process names, persists through cron, and beacons over traffic shaped to resemble NTP; specifics are in the checklist below. Security Affairs adds that Sansec saw second-wave actors dropping PHP into product-image cache directories on already-compromised stores, and that a store on 2.4.6-p15 with the July and August 2026 patches was still exploitable. Before Adobe shipped anything, the reported mitigation was disabling GraphQL.
One number needs care. Figures around 160,000 Magento and Adobe Commerce sites are circulating in coverage. That is an installed-base estimate, not a count of compromised stores. No confirmed victim count appears in anything reviewed here.
Why it matters
A 10.0 is rare, and the scope flag is why this one earns it. S:C is Adobe asserting that successful exploitation reaches beyond the vulnerable component. Strip that one metric out and the same vector scores 9.8. The gap between 9.8 and 10.0 here is not urgency theater; it is the vendor saying the blast radius does not stop at the PHP process.
The more consequential problem is the shape of the remediation. When the fix is a hotfix rather than a release, the version string on the host does not change, which breaks the whole class of tooling that answers “are we patched?” by comparing a version to a range. This site has documented the same failure three times in a week: IBM’s Operational Decision Manager 9.8, where interim fixes leave every install red in a scanner forever, patched or not; SonicWall’s SMA1000 pair, whose CNA records carried no fixed version at all; and now Adobe, where both the vendor’s “Updated Version” column and NVD’s “unaffected” field read as prose instead of a number.
The failure mode is not one false positive. It is that the finding never clears. A control that is permanently red teaches the people who read it to stop reading it, and it does so on exactly the assets that most need watching. Version-based verification cannot confirm this hotfix; someone has to record its application out of band — a change ticket, a file hash, a deployment log — and treat that record, not the scanner, as the source of truth.
A second record wrinkle compounds it. APSB26-146 carries a standing note: “Effective August 11, 2026, Adobe may assign a single CVE identifier to internally discovered vulnerabilities with the same severity rating and CWE category when a release includes systemic fixes.” That is defensible noise reduction, and it also means one Adobe CVE ID can stand for more than one defect. Pair it with a fix that has no version number and the record loses resolution in both directions: you cannot tell from the identifier how many flaws were closed, or from the version whether any of them were.
The timing is its own signal. Exploitation was public by September 5 at the latest, and Adobe’s next scheduled release was already set for September 8. Shipping out of band on Labor Day afternoon, with the NVD record landing after 5 p.m. Eastern, means Adobe judged that waiting one more day was worse than publishing into a holiday evening. That judgment is a more honest read of how bad this is than the score.
Finally, the KEV gap. Vendor-confirmed exploitation of an unauthenticated 10.0 in a widely deployed platform is the standard profile of a KEV addition, and until CISA adds it, federal civilian agencies have no directive-derived deadline. BOD 26-04, which replaced BOD 22-01 on June 10, 2026, derives its remediation bands from internet exposure, KEV listing, exploit automation, and whether technical impact is total or partial — and a CVE absent from the catalog is missing one of those four inputs outright. Private-sector operators need not wait for a catalog entry, and payment-card exposure makes waiting expensive in a second way.
What to do
- Apply Adobe’s hotfix for CVE-2026-75650 now. It is the only remediation Adobe names, linked from the bulletin as “Release Notes for hotfix on CVE-2026-75650.” There is no fixed release version to upgrade to instead.
- Do not use version-based scanning to confirm remediation. The hotfix does not move the version string. Record its application yourself and verify at the file level.
- Do not assume a later 2.4.x build carries the fix because it is newer. Adobe’s next scheduled release is September 8, 2026; confirm rather than infer.
- Treat any internet-facing store unpatched on or after September 4, 2026 as potentially compromised. A hotfix closes the door; it does not evict anything already inside.
- Hunt for the indicators Sansec is reported to describe — unexpected
[kworker/u:8:0],fc-cache, orchronydprocesses; files under~/.cache/fontconfig/; cron entries on a 30-minute interval; outbound UDP 123 to hosts that are not your NTP servers; stray PHP in product-image cache directories. Verify them against Sansec’s own writeup before building detections, because this page did not read them from the source. - Disabling GraphQL was the pre-patch mitigation and is superseded by the hotfix.
- If you take card data, involve whoever owns your PCI DSS obligations now, rather than after a forensic finding sets the clock for you.
Sourcing note
Checked: Adobe security bulletin APSB26-146 (helpx.adobe.com/security/products/magento/apsb26-146.html), retrieved three times with different URL forms; the NVD API record for CVE-2026-75650, retrieved twice with different URL forms, both returning no CISA KEV fields; Adobe’s Commerce and all-products bulletin indexes; and CISA KEV addition announcements through September 4, 2026.
Could not reach: the body of Sansec’s “StyleSmuggler” writeup at sansec.io/research/stylesmuggler-0day. Four retrievals across three URL forms returned page metadata and section headings only. Every exploitation detail attributed to Sansec on this page therefore comes from BleepingComputer and Security Affairs reporting Sansec, not from Sansec directly. Those two accounts agree with each other on every point above; they disagree with Sansec’s own page metadata on the publication date, September 7 versus September 5, 2026.
Unresolved: the acknowledgements block on APSB26-146 credits researchers against five CVE identifiers — CVE-2026-76200, CVE-2026-76201, CVE-2026-76202, CVE-2026-77108, and CVE-2026-77109 — that do not appear in the bulletin’s vulnerability details table, which lists CVE-2026-75650 alone. That may be a template artifact, a credit carried from a sibling bulletin, or CVEs Adobe intends to publish on September 8. None of those identifiers is used as evidence here.
Not asserted: any attribution. Neither Adobe nor the reporting reviewed here names an actor behind the initial exploitation, and this page does not either.