Why the BlockStrap attack path runs through checkout and a failed payment email
The carrier is ordinary traffic
BlockStrap, CVE-2026-103849, executes inside Magento's email rendering. To reach that rendering without an account, an attacker uses flows the store offers to every visitor. The public validation lab documents one such path end to end using only guest operations.
The sequence is create an empty cart, set a guest email address on it, submit a billing address whose address format fields carry the payload, then post a declined Payflow Pro response. The decline triggers the payment failure email, and generating that email runs the template filter that resolves the smuggled directive.
None of those steps requires stolen credentials. Each of them exists because a store has to support guest checkout and has to tell a customer when a payment fails.
Why the payload survives the first pass
The billing address fields are formatted recursively. That recursion reaches a nested base filter pass, which cannot process a {{block}} directive and returns the text unchanged. The vulnerable engine wraps that text, including the attacker's directive, in a signature that marks it as trusted.
Later, when the payment failure email is rendered, a second filter pass shares the request signature and rescans the signed text. The root filter dispatches blockDirective(), and code the attacker shaped runs in the web server context.
The lab's non-destructive probe asks the stock Magento\Framework\View\Element\Text block to run getCacheKey() over a fresh nonce. The transformed value appears only after the block executes, which is how the lab proves the primitive without command execution.
What that means for a store
The channel matters for two reasons. First, it is unauthenticated, so rate limiting and bot defence are the only pre-conditions an attacker has to satisfy. Second, the trigger is a failure, which means the store generates the exploitable email during a transaction that did not complete. Orders, revenue and customer records show nothing unusual.
For defenders, that changes where to look. The web tier logs the guest requests. The mail system holds the rendered message. The two together reconstruct the event, and neither alone does. The lab pays attention to exactly this: the fresh success value must be absent from every HTTP request and appear only in the captured email.
Noise that looks like the attack
Two patterns show up in Magento access logs and get mistaken for this flaw. Requests carrying Twig payloads with registerUndefinedFilterCallback target a template engine Magento does not use. Requests with a callback to bxss.me come from the Acunetix scanner. Neither indicates BlockStrap, and treating them as confirmations leads to the wrong incident.
The real signal is a block or template directive inside a field that later renders into an email, together with a payment failure in the same session.
Reducing the exposure
Patching is the fix. Adobe's October 2026 release and the isolated patch in bulletin APSB26-153 replace the generic rescan with a registry of deferred directives, so attacker text from a child template stays inert. NVD records the vendor description, CWE-1336, and a CVSS 3.1 vector of AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H at 10.0.
The September VULN-39341 hotfix stays installed, because the October patch does not include it and Adobe does not list it as a prerequisite. Verify both in code: resolveDeferredDirectives in the template filter for BlockStrap, and vendor/bin/magento-patches -n status for the hotfix.
Where patching has to wait, an HTTP-layer rule tested against the real guest checkout and payment-failure path is the interim control. Sansec shield blocks the pattern and states its rules are live for covered stores. A rule written against a guessed payload string is not the same thing.
Top comments (0)