APSB26-138: September's Magento Patch Doesn't Contain the Zero-Day Fix

Adobe shipped two Magento security patches in two days. The emergency fix for the StyleSmuggler zero-day went out on Monday the 7th as APSB26-146. The scheduled monthly bulletin, APSB26-138, followed on Tuesday.

Applying one does not apply the other. From Adobe's release notes:

The APSB26-146 hotfix for CVE-2026-75650 is not included in the September Isolated patch file. You must apply the hotfix first, then apply the Isolated patch.

Hotfix, then the monthly patch. A store that took only Tuesday's update is still open to the bug people are actually exploiting.

APSB26-146: the zero-day now has a CVE

The zero-day we wrote about on September 6 is CVE-2026-75650. Adobe published the bulletin the next day at priority 1, the tier that means patch inside 72 hours.

A 10.0 is the top of the scale, and you don't see many. Adobe's vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H: remote, easy, no credentials, nothing for anyone to click, and it escapes the component it starts in.

CISA added it to the Known Exploited Vulnerabilities catalog on the 8th and gave federal agencies until the 11th. Three days. They also marked it for forensic triage under BOD 26-04, a flag that appears on 48 of the 1,703 entries in the catalog.

Which hotfix file you need depends on your patch level:

Adobe widened that coverage after the first release. The note now says the hotfix is "compatible with all the Adobe Commerce and Magento Open Source versions between 2.4.4 - 2.4.7", so for once a store on an old patch level doesn't have to get current before it can take the fix. Below 2.4.4, Sansec's timeline records Scandiweb backporting it to a long list of older releases.

Check it landed with the Quality Patches Tool:

vendor/bin/magento-patches -n status | grep "39341\|Status"

What's in APSB26-138

Eight CVEs. Adobe's vulnerability table marks all eight critical while the summary above it says critical, important and moderate. Trust the table.

Six of the eight need no credentials. The two 9.3s are stored XSS in form fields: somebody submits the script, and it runs later in the browser of whoever opens that record. In Magento that's usually an admin.

Nothing in this set is remote code execution, and Adobe reports no exploitation of any of it. Priority 2, the 30-day tier. We spent a section arguing with that rating last month and we'll let it stand this time. August's headline bug was an account takeover that needed no login. These are a rung below.

Affected versions:

• 2.4.9-2026-aug and earlier
• 2.4.8-2026-aug and earlier
• 2.4.7-2026-aug and earlier
• 2.4.6-2026-aug and earlier
• 2.4.5-2026-aug and earlier
• 2.4.4-2026-aug and earlier

Adobe Commerce B2B 1.3.3 through 1.5.3 sits on the same list at the same patch level.

Those are August's patch levels, not release numbers. Patching last month doesn't take you off the list.

Adobe's two tables don't agree with each other on Open Source. Fixed versions run down to 2.4.4 for Adobe Commerce; for Magento Open Source they stop at 2.4.7, while the affected column goes down to 2.4.6. The download note says the same thing from the other end — Open Source merchants can only fetch patches for 2.4.7 and later. On Open Source 2.4.6, there is no September patch for you.

Applying them: hotfix, then July, August, September

Isolated patches stack. Sam James, in his write-up of this month's release: "Isolated patches stack, so 2026-09-001 will not apply unless 2026-08-001 is already on."

For a Community Edition store on 2.4.6-p15 that means the hotfix, then 246p15-2026-07-001-CE, then -08-001-CE, then -09-001-CE. Enterprise puts its -EE file after each CE file. B2B adds its own after that. All of it assumes you're on the latest -p release for your line, which is the only build Adobe tested any of these against.

The 2.4.6 file moved behind Composer keys this month. In August it was a direct download; the September URL redirects to the authenticated path. When the browser asks, your public key is the username and your private key is the password, the same pair already sitting in auth.json.

Cloud stores get September through the cloud patches package instead. Adobe warns that layering the isolated patch on top of a cloud-patches update that already carries the fix can fail the installation.

Find out what you're actually running

Adobe shipped a tool for this in July and barely mentioned it. The Commerce Version Tool lives at vendor/bin/patch-status and prints what's applied, what's missing, and a per-CVE verdict of PROTECTED, VULNERABLE or UNKNOWN:

php vendor/bin/patch-status

No such command means you don't have it yet. It ships inside the July 2026 isolated patch, starting with the Community Edition file for your line, so July is on your list either way.

Run it against production. A local checkout tells you what somebody meant to deploy.

Test these paths on staging

Sam James found three behavior changes in this month's patch that don't announce themselves:

• Guest PayPal Express. Where the quote in play isn't the session quote and the customer isn't signed in, setPayPalQuoteId now gets skipped silently. Put a guest order all the way through.
• GraphQL on multi-website setups. Tokens that worked before can come back as an anonymous context on website-scoped accounts when the Store header isn't handled right.
• Backup rollback. Magento_Backup::rollback is a new ACL resource and has to be granted. Custom admin roles lose rollback until somebody ticks it.

Add email to that list yourself. The hotfix changes how template directives are handled, so transactional emails, admin template previews and any custom code that renders a template are where this one bites.

Mage-OS gets it as one release

Mage-OS 3.5.0 landed on September 8 with the lot in a single version bump: Adobe's hotfix, the APSB26-138 content, four unrelated bug fixes, and hardening Adobe didn't ship. A deny list checked when a {{block}} directive instantiates a class. Resolved directive output neutralized, so a later filtering pass can't re-read it as template code. A SecurePathValidator anchoring include paths to the application root.

One composer update instead of four patch files, then. The release notes also list what the hardening breaks:

• Email template previews now require Magento_Email::template, Magento_Newsletter::template or Magento_Newsletter::queue as an explicit ACL resource.
• Custom transactional templates using unusual block classes may render as empty directives.
• Custom filters that depend on re-parsing directive output stop working.
• Templates rendered from outside the application root need moving.

If your store was reachable between September 4 and 7

Sansec's first confirmed exploitation was September 4 at 22:20 UTC. Adobe's fix went out on the 7th at 20:20 UTC. Friday night to Monday evening, which is an awkward three days to need somebody watching.

Patching now doesn't settle what happened then. Adobe's guidance on that is blunt:

Rotating the encryption key alone does not invalidate credentials that may already have been exposed. Rotate all associated credentials at their source (for example, at the payment gateway or third-party service), not only within Commerce.

The sequence Adobe publishes: maintenance mode, cron off, hotfix applied, then the encryption key, every admin password, all REST/SOAP/GraphQL integration tokens, OAuth client secrets, payment gateway credentials at the provider, database credentials, SSH and deploy keys, and third-party API keys for shipping and tax. Cloud stores redeploy at the end to pick up the new database credentials.

Scan before you start and after you finish. The indicators Sansec published are in our zero-day post. The implant has been renamed twice since — [kworker/u:8:0], then fc-cache, then chronyd — so match on the cron entry and the behavior instead of the filename.

What to do this week

Apply the hotfix. Today, if it isn't on. It's the only part of this month with anybody actively exploiting it.

Then work forward through the isolated patches. July, August, September, in order, on the latest -p release.

Run php vendor/bin/patch-status against production and keep the output.

Test guest checkout, GraphQL and transactional email on staging before any of it goes near production.

Decide whether the store was exposed between September 4 and 7. If you can't rule it out, rotate the credentials.

On a store that's current, all of that is about a day. If nobody can tell you this morning what patch level production is on, start there instead — patch-status answers it in under a minute, and you need July's patch to get the tool.

Emyrix does Magento security work and ongoing support, including patch management, compromise investigation and cleanup, and Adobe Commerce work on stores that have fallen behind. If you want someone to apply this month's patches properly, or to check whether StyleSmuggler reached you, get in touch.

Sources: Adobe Security Bulletin APSB26-138 · Adobe Security Bulletin APSB26-146 · Release notes: September 2026 security update (APSB26-138) · Release notes: urgent update for CVE-2026-75650 (APSB26-146) · NVD: CVE-2026-75650 · CISA Known Exploited Vulnerabilities catalog · Sansec: StyleSmuggler 0-day under active attack · Sam James: StyleSmuggler and September's isolated patch · Mage-OS 3.5.0 emergency security release · Adobe severity and priority rating definitions