A CVSS 10.0 in Magento, rated priority 2, with thirty days to patch — and four working routes found in twenty-four hours

Adobe patched CVE-2026-103849 on 13 October in bulletin APSB26-153. It is a template engine injection in Magento and Adobe Commerce email templates, scored CVSS 10.0, and it lets an unauthenticated attacker run arbitrary PHP on the store's server. Sansec, which named it BlockStrap, credits the discovery to a researcher working as vozec.

Adobe rated it priority 2, which in Adobe's scheme means patch within 30 days.

Why the rating and the score disagree

They are measuring different things, and Adobe has said so. Sansec reports that Adobe said in the Magento community Slack that it "reserves priority 1 for vulnerabilities it knows are being exploited".

So the priority is a statement about observed attacks, not about reachability or impact. A flaw can be unauthenticated, remotely triggerable and scored at the top of the scale, and still sit in the thirty-day bucket because nobody has seen it used yet.

That is defensible as a policy and dangerous as a reading instruction, because the gap it leaves is exactly the window attackers work in. Sansec's position is blunt: "Patch now instead of waiting 30 days."

It has an argument rather than a feeling. Within 24 hours of the patch, "we managed to reproduce four different attack routes". Not one proof of concept — four independent ways in, found by people who were not told how the bug worked and had only the patch to study. Sansec expects threat actors to manage the same.

We made a similar point about the three Next.js advisories this week, in the opposite direction: there the scores overstated the exposure for most applications, because the conditions were narrow. Here the score is right and the priority understates the urgency. In both cases the number on its own was the wrong thing to act on.

What the flaw is

Magento's email templates can contain directives that the template engine resolves. The September hardening signed trusted directives so that attacker-supplied content could not introduce new ones.

BlockStrap gets around that. Attacker-controlled data inside a child template can be signed and then rescanned at the root level, and a smuggled block directive placed in that data then runs inside Magento's rendering. The October patch "replaces that generic rescan with registered placeholders", adding a function named resolveDeferredDirectives to the framework's template filter.

This is the second critical flaw in the same email template engine in six weeks, with the same score and the same impact as the one Sansec called StyleSmuggler. Twice in a row, the mechanism has been that content which was never meant to be executable got handed to a renderer that executes things.

The patch you already applied is still load-bearing

This is the part most likely to go wrong in a hurry. The September hotfix, which signs trusted directives, does not block this route — but it must stay in place. The October patch does not include it. Applying the new fix over a system where the old hotfix was reverted leaves a hole.

Affected: Adobe Commerce and Magento Open Source up to and including 2.4.9, Adobe Commerce B2B up to 1.5.3, and Mage-OS up to 3.5.0. Open Source 2.4.6 and older have no public patch at all, and have to move to 2.4.7-p10 or later.

Sansec also warns that patch steps can fail silently, and gives a one-line check: grep -c resolveDeferredDirectives vendor/magento/framework/Filter/Template.php. A result of 0 means the fix is not there, whatever the deployment log said.

What to do

• Apply the October release or Adobe's isolated patch now, and confirm the September hotfix is still present. You need both.
• Verify the patch landed with the grep above rather than trusting the deployment output.
• If you are on Open Source 2.4.6 or older, the upgrade to 2.4.7-p10 or later is the fix. There is no backport.
• Scan for backdoors afterwards, not just for the missing patch. A store that was reachable for days before patching may already have one, and this flaw ends in arbitrary PHP execution.
• If you cannot patch within hours, put something in front of it at the HTTP layer. A thirty-day window is Adobe's policy, not a safety margin.

What is not established

• Whether BlockStrap has been exploited. Sansec says "No exploitation observed yet" on live stores, which is a statement about its own visibility.
• How many stores are unpatched. Nobody has published a figure for this flaw yet.
• Whether Adobe will revise the priority if exploitation appears. Its stated policy implies it would, but nothing has been said.
• Whether the four routes Sansec reproduced are the only ones. Four in a day by one team is a floor, not a ceiling.
• Why the same engine has produced two maximum-severity flaws in six weeks. Neither Adobe nor Sansec has published an assessment of the underlying design.