APSB26-153: October's Magento Patch Closes a Way Around the StyleSmuggler Fix

Adobe's October bulletin, APSB26-153, came out on Tuesday the 13th. Most of it is routine. One line isn't: CVE-2026-103849, an unauthenticated template injection scored 10.0, in the same part of Magento that StyleSmuggler went through last month.

Sansec, who named it BlockStrap, added a note to their StyleSmuggler write-up calling it a bypass of that patch:

Applying the StyleSmuggler hotfix alone does not stop it.

A store that took the September hotfix promptly and stopped there is still exposed. The October patch doesn't contain that hotfix either. From Adobe's release notes:

The hotfix for CVE-2026-75650 is not included in the October Isolated patch file and must be applied separately.

You need both.

CVE-2026-103849 (BlockStrap)

That's the same category, score and vector as StyleSmuggler. Remote, easy, no account, nobody has to click anything. In plain terms, somebody with no login could run their own code on the store's server, and from there reach customer data and the checkout.

Sansec describe BlockStrap as "a second-pass directive injection, like StyleSmuggler". Magento renders email templates in more than one pass, and attacker data that survives the first pass gets read as template code in a later one, where a smuggled {{block}} directive runs. Adobe's fix, in Sansec's words, "replaces that generic rescan with registered placeholders".

We read both patch files to see where each fix sits. The September hotfix (VULN-39341-249.diff) makes BlockFactory check that a class really is a block before creating it, and puts ACL checks on the email and newsletter preview blocks. It doesn't touch the template filter. The October patch does: it adds a DeferredDirectiveRegistry to Framework\Filter\Template and removes the signature-based deferral that has been in stock Magento since at least 2.4.7. Two different layers, which fits Sansec's advice to keep both. We haven't reproduced the attack, so the bypass itself is Sansec's finding, not ours. Adobe's bulletin doesn't connect CVE-2026-103849 to StyleSmuggler at all.

Why we wouldn't wait 30 days

Priority 2 is Adobe's 30-day tier. Their reasoning is that nobody's exploiting it, and as of Sansec's write-up on October 15 that was still true.

We'd apply it this week. StyleSmuggler was being exploited before Adobe had a fix out, so attackers already know this code and have tooling pointed at it. Sansec say they reproduced four different attack routes within 24 hours, and they question the priority 2 themselves. CISA's own assessment on the NVD record, dated October 14, has exploitation as none, automatable as yes, and technical impact as total. It isn't in CISA's Known Exploited Vulnerabilities catalog.

A store that's on the latest -p release and already took July, August and September has the most manageable deployment. How much work it is still depends on your customizations, integrations and infrastructure, so size the testing to match, but don't let that turn into a reason to push the patch back.

Everything in APSB26-153

Eleven CVEs. Five critical, five high, one medium. Four are stored XSS, where somebody saves a script into a form field and it runs later in the browser of whoever opens that record, which in Magento is usually an admin.

The privilege levels come from the PR metric in each CVSS vector, since Adobe's table doesn't say whether "authentication required" means a customer account or an admin one.

If you run B2B, CVE-2026-92909 deserves almost as much attention as the 10.0. It's code execution at 9.8 with no login. Adobe's bulletin marks it B2B, but the patch registry that Adobe's own checking tool reads lists it under the October CE file for every line and under the B2B file. The fix is split between them, so a B2B store needs both. The registry does the same with CVE-2026-91013, listing it under both the CE and EE files, so Commerce stores need the EE file as well.

Affected versions:

• Adobe Commerce 2.4.4 through 2.4.9, each at 2026-sep and earlier
• Adobe Commerce B2B 1.3.3, 1.3.4, 1.4.2, 1.5.2 and 1.5.3, each at 2026-sep and earlier
• Magento Open Source 2.4.6 through 2.4.9, each at 2026-sep and earlier

Fixed versions are the -2026-oct releases, plus 2.4.10-alpha1 and B2B 1.5.4-alpha1.

Magento Open Source is in the same position as last month. The fixed versions stop at 2.4.7, and Adobe's notes say Open Source merchants can only download patches for 2.4.7 and later. There's no October patch for Open Source 2.4.6, which is past the end of its support anyway. Adobe Commerce on 2.4.4 to 2.4.6 does get one, behind Composer keys.

Getting the patch: isolated files, not Composer

An isolated patch is a diff against the files in vendor/, not a new Magento version. Adobe's release notes say the October fixes are published only in that form and that not shipping Composer packages is intentional. Mage-OS's mirror of Adobe's packages shows no new magento/framework release since 2.4.9, so on an on-premises store composer update doesn't get you October.

For the keyed downloads, your Marketplace public key is the username and the private key is the password.

Each zip holds one file per component. The 2.4.9 one has 249-2026-10-001-CE.patch, 249-2026-10-001-EE.patch and 153-2026-10-001-B2B.patch. The order is the one Adobe gives every month: you must be on the latest -p release for your line, every earlier monthly patch has to be on already, and within a month CE goes first, then EE, then B2B. For a 2.4.8-p5 Commerce store that took September, that's 248p5-2026-10-001-CE, then 248p5-2026-10-001-EE, then B2B if you run it. The B2B file name follows your B2B version, not your Magento one; the 2.4.7-p10 zip carries 152p5- and 142p10- files for B2B 1.5.2 and 1.4.2. The StyleSmuggler hotfix stays where it is.

Adobe Commerce Cloud stores get both fixes through the cloud patches package: 1.1.21 applies the StyleSmuggler hotfix and 1.1.22, released October 13, applies APSB26-153. Adobe warns that applying the isolated patch where cloud patches already delivered the fix can break the install.

2.4.8-p5 has a second CE file

Adobe's registry lists two October CE patches for 2.4.8-p5. 248p5-2026-10-001-CE changes 21 files. 248p5-2026-10-002-CE changes one, framework/Validator/EmailAddress.php, fixes CVE-2026-91013, and requires -001 first. Sansec flagged it too.

The 2.4.8-p5 zip on repo.magento.com, as we downloaded it on October 16, contains a single -001-CE file of 22 files, with the EmailAddress.php change folded in. Its checksum doesn't match the -001 in the registry. So whether a 2.4.8-p5 store already has the CVE-2026-91013 fix depends on which -001 it applied.

Don't apply -002 blindly. Check first:

grep -c QUOTED_LOCAL_PART_PATTERN vendor/magento/framework/Validator/EmailAddress.php

Anything above 0 means the change is there, and -002 will fail as already applied, which can stop a build that treats a failed patch as fatal. A 0 means you need -002. patch-status reports the same thing per CVE.

Applying it so it stays applied

Patching files in vendor/ by hand isn't a deployment. The next composer install puts the old files back, and the next build ships them. Add the patch files to whatever already manages patches in your project (cweagans/composer-patches, vaimo/composer-patches, or the m2-hotfixes directory on Cloud) and commit them, so every build applies them. Adobe's release notes point to its guide for applying a composer patch.

Before it goes into the build, a dry run from the project root shows whether every hunk applies without touching anything:

patch -p1 --dry-run --fuzz=0 < 249-2026-10-001-CE.patch

Sansec's warning belongs here: composer patch plugins can skip a hunk without failing the build, and deploy scripts that run patch … || true ignore failed hunks. Either way you get a green deploy with the fix half on.

Then the running application has to pick the patch up. There are three layers, and each can lag behind the one before it:

• The files. The patched code is in vendor/. This is all patch-status and the greps below can see.
• Generated code and configuration. The October CE patch adds new classes, two new plugins (RestrictedFieldsPlugin and AllowPersistentCustomerGuestCart) and DI configuration. In production mode, Magento doesn't use any of that until generated/ and the config cache are rebuilt.
• The running processes. With OPcache timestamp validation off, PHP-FPM keeps serving the old files until it's reloaded or OPcache is reset. Queue consumers are long-running PHP processes too, and keep the old code until they restart.

On-premises, use the steps your deployment already runs for a code change. For most stores in production mode that means setup:di:compile and a cache flush, then a PHP-FPM reload or OPcache reset where timestamps aren't validated, and a consumer restart. On Cloud, the build and deploy phases rebuild generated code and caches when you push.

Rollback is simple. None of the October CE, EE or B2B files we read for 2.4.7-p10, 2.4.8-p5 and 2.4.9 touch Setup/ or db_schema.xml, so there's no database change to undo and no setup:upgrade to run. Reverting is a code revert. Take your usual backup first anyway.

Custom code can cancel the fix out. A module that sets its own <preference> for one of the patched classes keeps running its own version, and a plugin on them may break once the patch is on. This only reads files:

grep -rnE --include=di.xml 'Magento\\(Framework\\Filter\\Template|Email\\Model\\Template\\Filter|Framework\\Validator\\EmailAddress|Framework\\Lock\\Backend\\FileLock)"' app/code vendor | grep -v '^vendor/magento/'

Anything it prints needs a developer to look at it before October goes on.

How to check the October patch is applied

php vendor/bin/patch-status

That's Adobe's Commerce Version Tool. We read its source: it downloads Adobe's patch registry and each patch from repo.magento.com, checks them against your files with patch --dry-run forwards and in reverse, and prints applied patches, missing patches and a per-CVE PROTECTED, VULNERABLE or UNKNOWN. The registry has entries for the StyleSmuggler hotfix as well, so CVE-2026-75650 shows up in the same report.

What it needs:

• The July 2026 isolated patch. The tool was introduced with it. If the command isn't available, verify your July patch installation and deployment process separately.
• Network access to repo.magento.com, with a three-second timeout. A production server with no outbound access will report UNKNOWN.
• Marketplace keys for the keyed patches (2.4.4 to 2.4.6, some B2B lines), from the environment or auth.json.
• The patch binary on the server.

Treat UNKNOWN as "not checked". And remember what PROTECTED means: the patched code is in the files on disk. It can't see whether generated/ and the config cache were rebuilt, or whether PHP-FPM is still serving the old files from OPcache. Run it after the deploy has finished, against production.

For CVE-2026-103849 on its own, Sansec suggest:

grep -c resolveDeferredDirectives vendor/magento/framework/Filter/Template.php

The October patch adds that method, so 0 means the BlockStrap fix isn't there. We confirmed it's in the 2.4.7-p10, 2.4.8-p5 and 2.4.9 CE files. It says nothing about the other ten CVEs. On Mage-OS the file is at vendor/mage-os/framework/Filter/Template.php.

Neither check touches the running application. One request can give you a signal from it, by exercising a plugin the patch adds. It's a search, so it's meant to be read-only, but it goes to the production API, so it should be run by someone authorized to test that API, with an admin or integration token that's allowed to read customers. Search customers by the confirmation field:

curl -sg -H "Authorization: Bearer $TOKEN" "https://your-store.example/rest/V1/customers/search?searchCriteria[filterGroups][0][filters][0][field]=confirmation&searchCriteria[filterGroups][0][filters][0][value]=x"

From our reading of the patch, a store running the October code should refuse this with "The search criteria filter field is invalid." We haven't run it against a patched store ourselves. If the search succeeds instead, even with an empty list, that suggests the October restriction isn't active, whatever patch-status said, and stale generated/ code or config cache is the first thing to look at. Don't read any other response as a pass. An authentication or authorization error, a custom API layer in front of Magento, or any other error tells you nothing about the patch. And even a clean refusal only covers this one API restriction, not the rest of the October patch.

Adobe Commerce Cloud stores can also use the Quality Patches Tool, which Adobe documents for checking the hotfix on Cloud only:

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

After patching you'll find an empty file called 976bc24c08055e67a58cf491401c8b2f3d48ff55b8092f1ede196bac4756a228 in the Magento root. Sansec spotted it, and the patch explains it: FileLock now names lock files by the SHA-256 of the lock name, and that's the hash of /var/.regenerate.lock. It's Magento's own regenerate lock under a new name. It isn't malware and there's nothing to clean up.

What the patch changes that you might notice

We read through the 22 files in the 2.4.9 CE patch. Most of it is invisible. These parts aren't:

• Email templates get stricter on save. A new Magento\Email\Model\Template\Validator rejects any {{...}} directive inside an HTML attribute or a CSS url() that resolves to an absolute external address: http:, https: or //. Magento already blocked a directive placed after the host in src, href and action. The new check covers every attribute, CSS url() and the template's styles field as well. A custom transactional template with something like style="background:url(https://cdn.example.com/{{var store.code}}.png)" will now fail to save with "Content field contains restricted HTML elements". It still renders. The error shows up the next time somebody edits it, so open your custom templates on staging and save each one.
• Admin email previews run the same check on the submitted text and styles before rendering.
• Customer searches can't filter on secrets. password_hash, rp_token and confirmation are refused as filter or sort fields on the customer repository over REST, SOAP and GraphQL. An integration that looked customers up by confirmation to find unconfirmed accounts will start getting an InputException.
• Email addresses with a quoted local part are rejected, such as "john smith"@example.com. Rare, but it's a valid address under the RFC, so a registration or checkout could fail on one.
• Guest cart endpoints and persistent carts. July's patch added GetGuestCart, which only lets guest-cart endpoints load carts that belong to guests. October adds a plugin in Magento_Persistent that lets a guest-cart request read a cart belonging to a remembered customer, but only when cart persistence is on, nobody's logged in, and the persistent session belongs to that customer. Our reading is that this undoes a side effect of July's change, so if persistent carts misbehaved after July, October may fix them. Either way, put a remembered-but-logged-out customer through checkout on staging.
• The WYSIWYG validator catches more patterns, including empty HTML comments like <!--> and NUL bytes. CMS content pasted from odd sources may need cleaning before it'll save.

Commerce's EE file touches one renderer in the Reward module, and B2B's touches Company and the Purchase Order Rule authorization plugins. If you run purchase order approval rules, test an approval and a rejection.

Mage-OS: upgrade to 3.6.0

Mage-OS 3.6.0 came out on October 14 with Adobe's 2.4.9 patch ported in, plus seven bug fixes:

composer require mage-os/product-community-edition 3.6.0 --no-update
composer update

Mage-OS say there's no single-package workaround, because the fix spans the framework and the Email, Customer, Persistent and Catalog modules. 3.5.0 reached end of life with this release. If you built on the extra hardening 3.5.0 added, read their notes for integrators. Signature-based deferral is gone, and SignatureProvider is deprecated for deferral. The same advice about generated code and caches applies after the upgrade.

If StyleSmuggler is still open on your store

Then that's the first job. The hotfix, the files for your patch level and the credential rotation Adobe asks for are in our September post. Take the hotfix and July through September in order, then October on top.

Sansec sell an HTTP-layer firewall, Shield, and say it blocks BlockStrap while you schedule the patch. We haven't tested that against this bug. We have no commercial relationship with Sansec, and our write-up of their tools explains where we've used them.

What to do this week

Confirm the StyleSmuggler hotfix is on. patch-status reports CVE-2026-75650 alongside the October CVEs.

Add October's isolated patch to your patch management for your line: CE, then EE, then B2B. On 2.4.8-p5, check for the EmailAddress.php change before deciding about -002. Cloud stores, update cloud patches to 1.1.22.

Check your custom code for preferences and plugins on the patched classes.

Deploy it as a code change, so generated code, caches and PHP-FPM all pick it up.

Run patch-status, the BlockStrap grep and the REST check against production afterwards, and keep the output. Chase down any UNKNOWN.

Open and save each custom email template on staging, and put a guest order, a persistent-cart order and any B2B approval flow through before it goes live.

If you're on Magento Open Source 2.4.6, there's no patch to apply. The choice is an upgrade to 2.4.9 or a move to Mage-OS.

Emyrix does Magento security work and ongoing support, including patch management and compromise investigation, and Adobe Commerce work on stores that have fallen behind. If you want this month's patch applied and checked, or need to know whether a store missed September's, get in touch.

Sources: Adobe Security Bulletin APSB26-153 · Release notes: October 2026 security update (APSB26-153) · Adobe patch registry · Release notes: Magento Cloud Patches · NVD: CVE-2026-103849 · CISA Known Exploited Vulnerabilities catalog · Sansec: BlockStrap, Magento and Adobe Commerce RCE · Sansec: StyleSmuggler 0-day under active attack · Mage-OS 3.6.0 release notes · Adobe Security Bulletin APSB26-146 · Release notes: urgent update for CVE-2026-75650 (APSB26-146) · Adobe severity and priority rating definitions