Karvin Ong

Let’s talk

,

BlockStrap and APSB26-153: check your patch actually applied

Five weeks after StyleSmuggler, Adobe’s October bulletin APSB26-153 fixed BlockStrap (CVE-2026-103849): a CVSS 10.0, unauthenticated code execution flaw in the same template engine, and effectively a bypass of the September fix. No attacks have been reported yet, but researchers reproduced four attack routes within a day. The bigger lesson is about checking that your patches actually applied.

Key takeaways

  • CVE-2026-103849, CVSS 10.0, unauthenticated: a bypass of the September StyleSmuggler fix.
  • Apply APSB26-153 (the 2026-oct builds) and keep VULN-39341.
  • No attacks reported yet, but researchers reproduced four attack routes within a day.
  • Verify the deployed code with the checks below; patch tools can skip hunks silently.

What BlockStrap is

The September hotfix protected Magento’s template engine by signing trusted template directives. BlockStrap showed that attacker-controlled data in a child template could still end up signed and rescanned at the top level, where a smuggled {{block}} directive is executed during rendering. Adobe’s October patch removes the generic rescan and replaces it with registered placeholders, a structural fix rather than another filter.

What else is in APSB26-153

The bulletin (13 October 2026, Priority 2) fixes 11 vulnerabilities, five of them critical. Alongside BlockStrap they include an authorisation flaw allowing unauthenticated code execution in B2B (CVE-2026-92909, CVSS 9.8) and stored cross-site scripting issues leading to privilege escalation (including CVE-2026-91013 and CVE-2026-100133, CVSS 9.3). Fixed builds are the 2026-oct releases for 2.4.4 to 2.4.9, with public Magento Open Source patches for 2.4.7, 2.4.8 and 2.4.9, and Mage-OS 3.6.0.

Important: BlockStrap and StyleSmuggler are separate fixes. Keep the September VULN-39341 hotfix in place when you apply October’s update.

The real problem: patches that silently don’t apply

Many Magento projects apply security patches through Composer patch plugins or deployment scripts. These can skip a patch, or part of one, without failing the build, especially with a pattern like patch ... || true or when a file has drifted from what the patch expects. The pipeline goes green, and the store is still vulnerable.

So I don’t treat “the patch is in composer.json” as done. I check the code that is actually deployed:

# October fix present? 0 = missing
grep -c resolveDeferredDirectives vendor/magento/framework/Filter/Template.php
# (Mage-OS: vendor/mage-os/framework/Filter/Template.php)

# September hotfix still applied? (Adobe Commerce / quality patches tool)
vendor/bin/magento-patches -n status | grep "39341\|Status"

# Email address fix included? Run against Magento's EmailAddress.php
# validator; 0 = apply the follow-up patch
grep -c QUOTED_LOCAL_PART_PATTERN path/to/EmailAddress.php

For 2.4.8-p5, the original isolated patch missed the change for CVE-2026-91013. A corrected file and a follow-up patch were published, which is exactly the kind of detail a “patch applied” checkbox hides.

Two things that look alarming but aren’t

  • An empty file with a long hexadecimal name in the Magento root is created by the October patch, not by malware.
  • Requests calling back to bxss.me come from a vulnerability scanner, and Twig payloads using registerUndefinedFilterCallback are not BlockStrap.

How I’d roll it out

  1. List every store with its exact version and current patch level.
  2. Apply the October update on staging; make the build fail if any patch hunk doesn’t apply.
  3. Run the verification checks above against the built code, then deploy.
  4. Re-run the checks against production, and scan for backdoors.
  5. If a store can’t be patched quickly, put WAF protection in front of it until it can.

Sources

Platform: , ,