A newly disclosed maximum-severity flaw in Magento and Adobe Commerce, dubbed BlockStrap, lets attackers run arbitrary PHP code on store servers. UK retail and e-commerce teams should treat this as an urgent patch, not a routine item on next month's maintenance list.
View the data behind this chart
| Phase | Starts (week) | Duration (weeks) |
|---|---|---|
| Adobe bulletin published | 0 | 1 |
| Adobe priority-2 SLA (30 days) | 0 | 4 |
| StyleSmuggler exploit risk window | 0 | 1 |
A maximum-severity flaw sitting under a misleadingly calm label
CVE-2026-103849, nicknamed BlockStrap by e-commerce security firm Sansec, affects September versions of Adobe Commerce and Magento Open Source through 2.4.9, plus Adobe Commerce B2B through 1.5.3. Adobe's bulletin, published on 13 October 2026, describes it as an improper neutralisation of special elements in a template engine, leading to arbitrary code execution.
For a UK retailer, that technical phrasing translates to something stark: an attacker who finds a working exploit path could potentially take full control of the application layer behind a checkout page, customer database or payment integration.
Why the 30-day patch clock is the wrong one to watch
Adobe has given BlockStrap a "priority 2" rating, which carries a recommended 30-day patch window. Sansec disagrees sharply with that assessment, arguing the complexity of the attack path doesn't reflect the real-world danger. Researchers identified four distinct potential attack paths involving CVE-2026-103849 in under 24 hours of analysis.
Sansec's comparison point is a prior Magento flaw called StyleSmuggler, which it says went from priority-1 hotfix release to mass exploitation in just three days. The firm believes BlockStrap is of similar complexity and warns that "anyone with an AI agent can reverse-engineer the patch into working exploits in a relatively short time." For buyers, this means the official SLA window and the real exploitation window can be two very different things — a gap that understanding CVE, CVSS, and KEV scoring helps make sense of when prioritising patch queues.
How the BlockStrap exploit path works
Sansec describes BlockStrap as a second-pass template engine directive injection. Attacker-controlled content placed in a child email template gets signed and then processed a second time at the root level, which executes a smuggled {{block}} directive — effectively running attacker code where it shouldn't be trusted.
Crucially, Sansec says BlockStrap exploits a gap that was left open by the earlier StyleSmuggler fix in the same email-template engine. Adobe's remedy replaces the old generic processing logic with registered placeholders to close that loophole properly.
What UK retail and e-commerce teams should check now
Sansec is explicit that a standard Composer update alone will not resolve this. Store operators need to apply either the 2026-oct release or Adobe's isolated patch for BlockStrap, and — separately — keep the September VULN-39341 hotfix for StyleSmuggler in place. The two fixes are independent; missing either one leaves exposure.
- •Confirm your Magento Open Source or Adobe Commerce build number and compare it against the affected ranges listed by Adobe
- •Apply the 2026-oct release or the isolated BlockStrap patch — do not assume a routine Composer install has covered it
- •Verify the September VULN-39341 (StyleSmuggler) hotfix is still applied alongside the new patch
- •Treat this as urgent rather than scheduling it within Adobe's 30-day window, given Sansec's exploitation-speed warning
- •Watch for Sansec's promised update once mass attack waves are detected, which the firm says it expects soon
The wider lesson for UK online retail infrastructure
BlockStrap is a useful case study in how quickly a "patch within 30 days" advisory can become out of date once researchers and threat actors both start probing the same fix. Retail IT teams running Magento or Adobe Commerce, often alongside a patchwork of extensions and legacy hosting, should use this as a prompt to review how fast their vulnerability management services can move from disclosure to deployment.
Stores still running older, harder-to-patch infrastructure in the background — payment gateways, legacy app servers, or hardware nearing vendor end-of-support — carry compounded risk when a flaw like this surfaces, which is why keeping end-of-support servers secure matters as much as the application-layer fix itself. Pairing rapid patching with managed detection & response and a zero trust approach to internal access reduces the blast radius if an exploit does land before the patch is applied.
For retailers juggling third-party platforms, extensions and ageing on-premise kit around their commerce stack, third-party maintenance for your infrastructure and a broader look at our cybersecurity solutions can help close the gap between a vendor advisory landing and a confirmed, tested fix going live across every affected environment.