The Adobe Commerce zero-day patched on September 7 is the rare case where applying the patch is the easy half of the job. CVE-2026-75650 carries a CVSS base score of 10.0, needs no login, and Adobe states it was already being used against merchants before a fix existed. Every Magento Open Source and Adobe Commerce install on 2.4.4 through 2.4.9 is in scope. A Hyvä frontend does not change that.
What Adobe shipped on September 7 and 8
Adobe published two Commerce security bulletins one day apart, covering nine CVEs between them. The first, APSB26-146, went out of band on September 7 for a single vulnerability. The second, APSB26-138, landed on September 8 as the regularly scheduled monthly update with eight more.
CVE-2026-75650 is the one that matters this week. The Zero Day Initiative's September review records it as a template-engine injection scoring 10.0, the maximum, and confirms Adobe's finding that it was exploited in the wild. Unauthenticated remote code execution on a storefront means an attacker reaches the application before any login check runs. The affected range is wide: Adobe Commerce and Magento Open Source 2.4.4 through 2.4.9, plus Adobe Commerce B2B 1.3.3 through 1.5.3, in each case up to and including the August 2026 releases.
APSB26-138 is the ordinary month. Eight CVEs, a highest score of 9.3, a deployment priority of 2, and the usual mix of arbitrary code execution, privilege escalation and security feature bypass. On any other week it would be the headline.
APSB26-146 vs APSB26-138: same week, opposite handling
These two bulletins are not interchangeable and the install order is fixed: the APSB26-146 hotfix goes on first, then the APSB26-138 isolated patch. Adobe's knowledge base is unambiguous on the sequence, and it exists because the hotfix addresses a flaw under active exploitation while the monthly patch does not.
The hotfix is tracked as VULN-39341. You confirm it landed with the Quality Patches Tool rather than by trusting your deploy log, running vendor/bin/magento-patches -n status and checking that 39341 reports as applied. Both September releases ship as isolated security fixes, meaning patch files rather than Composer packages, which is a meaningful operational difference if your pipeline only knows how to bump a version constraint.
The larger gap between the two is what happens after the code is patched. For APSB26-138, patching is the whole remediation. For APSB26-146 it is step one of twelve. Adobe's guidance runs through maintenance mode, disabling cron, rotating the encryption key, rotating every admin password, regenerating integration tokens, rotating OAuth secrets, rotating payment gateway credentials at the provider, rotating database credentials, rotating SSH and deploy keys, rotating third-party API keys, then flushing cache and reversing the maintenance steps. Adobe is explicit that rotating the encryption key on its own leaves already-stolen credentials working.
Why a fast frontend gives you nothing here
Hyvä, Luma and headless storefronts are equally exposed, because the vulnerability sits in the Magento application layer that all three sit on top of. Theme choice is not a security control. We spend most of our e-commerce work arguing for Hyvä on performance and maintenance grounds, and none of those arguments apply to an unauthenticated RCE in the platform underneath.
What theme choice does affect is how fast you can act. A store with a lean, well-understood frontend and a small extension surface can take a patch, run a smoke test and ship inside a morning. A store carrying forty third-party modules of unclear provenance cannot, because nobody is confident what the patch will break, so the patch waits for a testing window that lands next week. That delay is the actual risk, and it was bought years earlier when the extension list grew.
The credential-rotation half compounds the same problem. Rotating payment gateway credentials and integration tokens is trivial if those values live in environment configuration with a documented owner. It is a multi-day archaeology project if they are scattered across the admin UI, a legacy module's config table and someone's local env.php. This is the unglamorous case for treating configuration as infrastructure rather than as settings, which is most of what our automation work is actually for.
What we would change this quarter
Patch today, then assume the store was reached and work the rotation list. The reasonable reading of a maximum-severity unauthenticated RCE that was exploited before disclosure is that absence of evidence is not evidence of absence. Check for admin accounts nobody created, integrations nobody registered, and file modification times that do not line up with a deploy. If you cannot answer those questions from logs, that is itself the finding.
Then fix the thing that made this expensive. Write down where every credential class lives and who rotates it, because you will need that list again. Get the extension inventory to a number you can regression test in a day. Put the Quality Patches Tool status check into your deploy pipeline so patch level is asserted on every release rather than remembered. None of that is interesting work and all of it converts the next Patch Tuesday from a project into a task.
One more thing worth saying plainly to founders weighing platforms. This bulletin is not an argument that Magento is uniquely unsafe. It is an argument that a self-hosted application with a large extension ecosystem transfers a standing operational duty to you, and that duty has a real cost that belongs in the total cost of ownership next to licence fees and hosting. Decide that on purpose.
Where to dig deeper
- Adobe's APSB26-146 announcement for the hotfix, the affected version table and the full rotation checklist.
- The APSB26-138 knowledge base article for the September monthly update and the hotfix-first install order.
- Zero Day Initiative's September 2026 review for the CVE counts and CVSS scores across both bulletins.