Magento BlockStrap (CVE-2026-103849): detection, patch checks and response

An unauthenticated route to code execution

A write-up on dev.to walks through how to detect and respond to exploitation of BlockStrap, an unauthenticated remote code execution flaw in Magento tracked as CVE-2026-103849. The bug lets an anonymous attacker arrange for a {{block}} directive to be resolved while Magento renders an email; when a usable block and method line up, that resolution runs PHP with the web server's permissions.

The attack chain

According to the write-up, the payload travels through routine guest GraphQL operations: create an empty cart, attach a guest email address, submit a billing address whose formatting fields contain the payload, then provoke a declined Payflow Pro response so Magento generates a payment-failure email. The nested address formatting keeps the directive inert and signs it at submission time, and it is the later email pass that resolves it and executes the code.

Where to look for evidence

Guest GraphQL sessions that set a billing address and follow with a declined payment are normal during checkout, so their presence alone proves nothing. The tell-tale sign is a block or template directive embedded in an address format field, a name field, or any other string destined for email rendering.

Because the payload runs at the moment the failure email is built, outgoing mail can expose the compromise. The author's clearest proof is a value in a delivered email that no client request ever contained — the rendering engine, not the sender, produced it.

Log analysts should also expect decoys. Twig payloads calling registerUndefinedFilterCallback, along with callbacks to bxss.me, come from scanners probing a template engine Magento does not ship; the post stresses these are not BlockStrap and should be filtered out to keep the real signal visible.

File and process indicators

The public validation lab cited in the article documents a side effect that needs no exploit gadget: dispatching the stock Magento\Backend\Block\Widget\Grid\Extended block and invoking getCsvFile() drops a randomly named 32-hex-character .csv file into var/export/, containing the four bytes EF BB BF 0A, before failing for lack of a collection. Monitoring should therefore flag tiny, unexplained new files in that directory that match no admin export.

Signs of full command execution are broader: unexpected child processes running as the PHP-FPM pool user, outbound connections from the web tier, new files under pub/media or var/, changes to app/etc/env.php, and cron entries nobody scheduled. Where admins also have SSH access, the write-up suggests matching process start times against payment-failure email timestamps.

Confirming the fix actually landed

The October patch introduces resolveDeferredDirectives into vendor/magento/framework/Filter/Template.php — on Mage-OS, the same check applies to vendor/mage-os/framework/Filter/Template.php — so a grep -c resolveDeferredDirectives against that file returns a non-zero count only when the fix is installed.

Two further checks are needed. The September StyleSmuggler hotfix is not folded into the October patch and is not listed by Adobe's patch registry as a prerequisite, so it must be confirmed separately through vendor/bin/magento-patches -n status. And on Magento Open Source 2.4.8-p5, the first zip omitted an EmailAddress.php change for CVE-2026-91013; Adobe replaced the file on 14 October 2026 and shipped the missing change as 248p5-2026-10-002-CE. If grep -c QUOTED_LOCAL_PART_PATTERN on vendor/magento/framework/Validator/EmailAddress.php returns zero, that second file is still needed.

Incident responders should also expect one harmless oddity: the October patch names lock files after the SHA-256 hash of the lock name, so /var/.regenerate.lock appears as 976bc24c08055e67a58cf491401c8b2f3d48ff55b8092f1ede196bac4756a228 in the Magento root. Every patched store has this empty file, and it is not an indicator of compromise.

Containment and patching order

Where execution is confirmed, containment takes priority over forensics: rotate database credentials, payment gateway keys and admin passwords from a machine outside the store, and preserve web-tier logs before rebuilding. Sansec recommends its eComscan tool for flagging the missing patch and hunting backdoors.

Traffic should stay closed until patching is done. The vendor's priority 2 rating nominally allows 30 days, but Sansec — cited in the write-up alongside Adobe's bulletin APSB26-153 and reporting by BleepingComputer — argues that timeline understates reality: the firm reproduced four working attack routes within a day of the patch dropping, even though no live-store exploitation had been observed at publication time.

Why it matters

BlockStrap needs no credentials, hides inside ordinary checkout traffic, and fires from a subsystem — transactional email — that every store runs. Its traces sit in unusual places: message bodies, var/export/, and process tables rather than obvious webshell files. Remediation is also not a single zip, since the October patch, the September StyleSmuggler hotfix and the reissued 2.4.8-p5 file each require independent verification. For merchants, the vendor's 30-day window should be treated as an outer bound rather than a plan.