Detecting and responding to BlockStrap exploitation on a Magento store
Start from the request, not the file
BlockStrap, CVE-2026-103849, gives an unauthenticated attacker a way to have a {{block}} directive resolve inside Magento's email rendering. Where a usable block and method exist, that resolution runs PHP in the web server context. Detection therefore has two layers: the request that carries the payload, and the effect that follows.
The public validation lab is useful for building both. It shows an unauthenticated carrier built from guest GraphQL operations: create an empty cart, set a guest email, submit a billing address whose format fields hold the payload, then trigger a declined Payflow Pro response so the payment failure email is generated. The nested address formatting leaves the directive inert and signs it, and the later email pass resolves it.
What to look for in requests and logs
Guest GraphQL traffic that sets a billing address and then posts a declined payment response in the same session is ordinary during checkout. What is not ordinary is a request body containing a block or template directive inside an address format field, a name field, or any string that later renders into an email.
Log review should target the payment failure path. In the lab the payload executes when the failure email is generated, so the mailbox becomes an observation point. A transformed value that appears in a message but never in any request is the signature the lab relies on: the engine produced it, the client did not send it.
Access logs also carry noise that looks related. Twig payloads using registerUndefinedFilterCallback, and callbacks to bxss.me, come from scanners and from a template engine Magento does not use. Neither is BlockStrap. Filtering them out keeps the real signals visible.
File and process indicators
The lab documents a bounded side effect that requires no gadget: dispatching the stock Magento\Backend\Block\Widget\Grid\Extended block and calling getCsvFile() creates a random 32-hex .csv file under var/export/ containing the four bytes EF BB BF 0A, then fails because there is no collection. In a monitoring rule this means new files in var/export/ that are tiny and do not correspond to an admin export.
Command execution leaves broader traces: unexpected child processes under the PHP-FPM pool user, outbound connections from the web tier, new files under pub/media or var/, modified app/etc/env.php, and cron entries that no one scheduled. On a store that also has admin access via SSH, correlate process times with the payment-failure email timestamps.
Verification after patching
A patched store should be verified in code. The October patch adds resolveDeferredDirectives to vendor/magento/framework/Filter/Template.php, so grep -c resolveDeferredDirectives vendor/magento/framework/Filter/Template.php returns a non-zero count when the fix is present, and zero when it is missing. On Mage-OS the same check applies to vendor/mage-os/framework/Filter/Template.php.
The September StyleSmuggler hotfix must be verified separately. vendor/bin/magento-patches -n status reports it, and the October patch does not include it. Adobe's patch registry does not list it as a prerequisite either, so a store that applies only October still carries the older gap.
On Magento Open Source 2.4.8-p5, check a second function. The first zip of that patch omitted an EmailAddress.php change for CVE-2026-91013, and Adobe replaced the file on 14 October 2026 under the same name, publishing the missing change as 248p5-2026-10-002-CE. If grep -c QUOTED_LOCAL_PART_PATTERN vendor/magento/framework/Validator/EmailAddress.php returns zero, the second file is still needed.
Expect one misleading file. The October patch names lock files after the SHA-256 hash of the lock name, so /var/.regenerate.lock becomes 976bc24c08055e67a58cf491401c8b2f3d48ff55b8092f1ede196bac4756a228 in the Magento root. It is empty, every patched store has one, and it is not an indicator of compromise.
Response order
Containment comes before analysis on a store that shows execution. Rotate database credentials, payment gateway keys and admin passwords from a host that is not the store, then preserve logs from the web tier before rebuilding it. Sansec recommends running eComscan to flag the missing patch and to check for backdoors, which is a reasonable starting point for the integrity pass.
Patching comes before reopening traffic. The vendor's priority 2 rating allows 30 days, and Sansec argues that window does not reflect the practical risk: it reproduced four attack routes within 24 hours of the patch, and no live-store exploitation had been observed at publication time. Absence of reported attacks shortens the detection window, not the response.
Top comments (0)