dinosn

Counting Magento exposure for BlockStrap without overstating it Counting Magento exposure for BlockStrap without overstating it The number and what it means ZoomEye returns 135,083 assets for the query app="Magento". That figure describes hosts whose banners match the Magento application fingerprint. It does not describe hosts that run a version affected by CVE-2026-103849, and it says nothing about whether a store has the October patch, the September hotfix, or neither. The distinction matters because BlockStrap, a second-pass template directive injection rated CVSS 10.0 by Adobe and mapped to CWE-1336 by NVD, is only exploitable on builds from before the 2026-oct release. Assets that answer with a Magento fingerprint include stores on managed hosting that patched on day one, stores on 2.4.7-p10, stores still on the 2026-sep release, headless deployments that put a separate front end in front of Magento, and stale installations that no longer serve sales but keep answering. Why fingerprint counting still helps An inventory number answers a planning question. If an organization owns twelve domains and one of them appears in a Magento exposure set, the domain is worth a ticket. If a hosting provider appears repeatedly, the provider's patch cadence is worth a conversation. What the number should not be used for is a claim about vulnerable stores. Sansec reported no live-store exploitation when it published its analysis on 15 October 2026. The absence of reported attacks is not evidence of successful patching across that population. Building a defensible internal count ZoomEye identifies internet-facing assets. An internal count has to come from configuration management and from the Composer lock file. Start with composer show magento/product-community-edition on each deployment, or the Adobe Commerce package name where the commercial edition is used. Then confirm the patch state in code, not in a deploy log. The October patch adds resolveDeferredDirectives to the template filter, so grep -c resolveDeferredDirectives vendor/magento/framework/Filter/Template.php returning zero means the fix is absent. Sansec recommends the same check, and notes that Composer patch plugins can skip a hunk without failing the build while deploy scripts that end a patch command with || true hide the same failure. Repeat the check against the artifact that serves traffic. A container image built before the patch, or a blue-green pair where only one side has been rebuilt, produces a partial fix that a repository scan will not show. The version ranges to match against Adobe lists affected Adobe Commerce versions as 2.4.9-2026-sep and earlier 2026-sep releases through 2.4.4-2026-sep. Adobe Commerce B2B is affected through 1.5.3-2026-sep. Magento Open Source is affected in 2.4.9-2026-sep, 2.4.8-2026-sep and 2.4.7-2026-sep. The 2026-oct releases and 2.4.10-alpha1 are unaffected. Mage-OS tracks the same framework and is affected up to 3.5.0. Mage-OS 3.6.0, released on 14 October 2026, contains Adobe's fix, and the upgrade is done through the mage-os/product-community-edition metapackage because the change spans the framework and four modules. Magento Open Source 2.4.4, 2.4.5 and 2.4.6 have no public Adobe patch for this issue. Adobe's public October patches cover 2.4.7-p10, 2.4.8-p5 and 2.4.9. Happy Horizon published backported patches for 2.4.4-p18 through 2.4.9; Sansec states it gives no warranty for those third-party patches and recommends upgrading to 2.4.7-p10 or later where feasible. Sequencing the work The patch relationship decides the order. BlockStrap and StyleSmuggler are separate fixes, and the October patch does not include the September hotfix VULN-39341, nor does Adobe's patch registry list it as a prerequisite. Install VULN-39341 first, then the October release or isolated patch, then verify both in code. For stores that cannot complete that sequence within hours, an HTTP-layer rule buys time. Sansec's shield blocks the directive pattern at the request layer. Any equivalent rule needs testing against the guest checkout and payment-failure paths that the public validation lab uses, because a rule tuned to a guessed payload string will miss a differently shaped carrier. Reporting exposure honestly An exposure count belongs in a report next to its definition. Write "135,083 internet-facing assets match the Magento fingerprint" and add what the number excludes: version, patch state, and confirmed vulnerability. The same discipline applies to an internal inventory, where the reliable figure is the count of deployments that fail the code check. Sources - Sansec: BlockStrap RCE - Adobe security bulletin APSB26-153 - NVD record for CVE-2026-103849 - Public BlockStrap validation lab

Detecting and responding to BlockStrap exploitation on a Magento store 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. Sources - Public BlockStrap validation lab - Sansec: BlockStrap RCE - Adobe security bulletin APSB26-153 - BleepingComputer report

For Magento 2.4.4 to 2.4.6 stores, BlockStrap leaves a hard upgrade decision For Magento 2.4.4 to 2.4.6 stores, BlockStrap leaves a hard upgrade decision The gap Adobe's October 2026 security release fixes CVE-2026-103849 in the 2026-oct releases for 2.4.9, 2.4.8 and 2.4.7. Magento Open Source installations on 2.4.4, 2.4.5 and 2.4.6 fall outside that set. Adobe's public patches cover 2.4.7-p10, 2.4.8-p5 and 2.4.9. The vendor patches for 2.4.4-p18, 2.4.5-p17 and 2.4.6-p15 require an Adobe Commerce license. That leaves three practical paths for an Open Source store on an older branch: upgrade to 2.4.7-p10 or later, apply a third-party backport, or accept risk with compensating controls. What the flaw does CVE-2026-103849 is a second-pass template directive injection in Magento's email rendering. Attacker-controlled data in a child template cannot process a {{block}} directive and returns it unchanged; the engine signs that text as part of the nested render; the root filter rescans the signed text and dispatches the directive. NVD records the vendor description, CWE-1336 and a CVSS 3.1 base score of 10.0 with the vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Execution requires a pre-authentication input path into the email pipeline and a deployable block gadget. Sansec reproduced four routes to code execution within 24 hours of the patch and reported no attacks on live stores at the time of writing. The upgrade path Adobe's own guidance is the 2026-oct release in the supported branches. For 2.4.4 to 2.4.6, the supported destination is 2.4.7-p10 or later. That is a version jump that changes PHP requirements, dependency versions and often the theme and extension set, which is why it does not happen on the day a bulletin ships. Plan it as a project rather than a patch. Stage the target release with the extension set, run the store's own regression tests against checkout, email, payment and admin workflows, and keep the rest of the security backlog in view: jumping two minor versions carries other changes that must be read, not just installed. The backport path Happy Horizon published backported APSB26-153 patches for Magento 2.4.4-p18 through 2.4.9, split per Composer package for use with cweagans/composer-patches. Sansec states it gives no warranty for these third-party patches and recommends upgrading to 2.4.7-p10 or later as the alternative. Backports are a reasonable bridge for a store that cannot move quickly, with conditions. Review the patch content against the vendor fix. Verify the result in code rather than in the deploy log, using the resolveDeferredDirectives check in vendor/magento/framework/Filter/Template.php. Record who approved the exception and when it expires. The compensating-control path Where neither path is available within the exposure window, an HTTP-layer rule reduces the chance that a carrier reaches the template engine. Sansec Shield blocks BlockStrap at the request layer and has rules live for its stores. Any in-house rule needs to be tested against the guest GraphQL and payment-failure path the public validation lab documents, and against the store's own checkout flow, because a rule that blocks legitimate orders creates a different incident. Compensating controls do not change the vulnerable code. They narrow the window between publication of the patch and installation, and they assume the attacker uses the shape the rule was tested against. Sequencing all three Whatever path a store chooses, the September hotfix comes first. BlockStrap and StyleSmuggler are separate fixes, the October patch does not include VULN-39341, and Adobe's patch registry does not list the hotfix as a prerequisite. A store that applies October only still carries the older StyleSmuggler gap. Then verify. Check resolveDeferredDirectives in the template filter, check the hotfix with vendor/bin/magento-patches -n status, and on 2.4.8-p5 check QUOTED_LOCAL_PART_PATTERN in vendor/magento/framework/Validator/EmailAddress.php for the corrected patch file Adobe published on 14 October 2026. Sources - Sansec: BlockStrap RCE - Adobe security bulletin APSB26-153 - NVD record for CVE-2026-103849 - Public BlockStrap validation lab

Mage-OS and BlockStrap: the same framework, a different release train Mage-OS and BlockStrap: the same framework, a different release train Why Mage-OS is in scope Mage-OS distributes a community build of the Magento framework. When the framework carries a template engine flaw, the derivative build carries it too. That is what happened with CVE-2026-103849, the BlockStrap second-pass directive injection that NVD maps to CWE-1336 and scores 10.0 under CVSS 3.1. Sansec states that Mage-OS is affected up to 3.5.0. Mage-OS 3.6.0, released on 14 October 2026, contains Adobe's fix. The upgrade is a metapackage change Because the fix spans the framework package and four modules, upgrading a single package is not enough. Sansec's recommended sequence uses the community edition metapackage so Composer resolves the set together: composer require mage-os/product-community-edition 3.6.0 --no-update composer update The --no-update step pins the metapackage version before resolution, which keeps composer update from choosing a different combination of framework and modules. The same pattern applies on Adobe Commerce, where the fix arrives with the 2026-oct release or the isolated patch rather than as a standalone framework bump. What the flaw does on a Mage-OS store The mechanism is identical to the Adobe Commerce case. Attacker-controlled data in a child email template cannot process a {{block}} directive and returns it unchanged. The engine signs that text during the nested render, and the root filter rescans it, dispatching the directive. The September VULN-39341 hotfix closed an earlier route in the same engine but not this one. Sansec reproduced four routes to code execution within 24 hours of the vendor patch and reported no attacks on live stores when it published its analysis on 15 October 2026. The public validation lab documents an unauthenticated carrier built from guest GraphQL operations and a stock file side effect, and is explicit that it does not demonstrate a stock full chain in the tree it examined. Verification on Mage-OS paths The verification command changes path, not logic. On Mage-OS, check vendor/mage-os/framework/Filter/Template.php for resolveDeferredDirectives with the same grep -c approach Sansec recommends for the Adobe path. A zero means the fix is missing. Two further checks matter. Confirm the StyleSmuggler hotfix VULN-39341 is still installed, because the October fix does not include it and Adobe's patch registry does not list it as a prerequisite. And confirm which artifact serves traffic, since a container image or a blue-green pair can carry a patched build on one side and an unpatched one on the other. The wider scheduling question Mage-OS releases on its own cadence, and that cadence may not match a merchant's maintenance window. When a derivative distribution ships a critical fix days after the upstream vendor, administrators face the same trade-off they face on the vendor release: patch on the vendor's timeline, or accept risk with an HTTP-layer control in front of the application. Sansec offers its own shield product as an interim control and states its rules are live for covered stores. Any equivalent rule needs testing against the store's checkout flow, because a rule that blocks legitimate guest orders is its own outage. Sources - Sansec: BlockStrap RCE - Adobe security bulletin APSB26-153 - NVD record for CVE-2026-103849 - Public BlockStrap validation lab

Why the BlockStrap attack path runs through checkout and a failed payment email 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. Sources - Public BlockStrap validation lab - Sansec: BlockStrap RCE - Adobe security bulletin APSB26-153 - NVD record for CVE-2026-103849

#PHP2shell is the Octoberfest for security researchers and the hottest topic right now. wiz.io dinosn/php-cve-2026-10961x-lab-poc php2shell.evilbit.de

Adding this to the lab, github.com/dinosn/php-cve-2026-10961x-lab-poc/blo… , this will work on stock, official php:8.4.26-apache image, no php.ini change, single-worker prefork, display_errors=Off . Default has the 128M allocation, not the 8M that is on labs. All work in progress. I don't see realistic scenario though without spamming heavily and for long time servers.

CVE-2026-109618 and CVE-2026-109619 Are Two Directions Through the Same Pre-RINIT Window Leak hit HN 2026-10-20 15:20Z. PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 fix both CVEs. Mechanism: php_request_startup() calls php_hash_environment() (multipart parse, the session.upload_progress callback, php_session_initialize() on the process-wide BG(serialize)/BG(unserialize)) one line before zend_activate_modules() runs basic's RINIT, which is what zeroes them. CVE-2026-109618 is the exit direction: an OOM longjmp out of the serializer leaves partial state and mod_php runs shutdown anyway. CVE-2026-109619 is the entry direction: the next request on the same worker dereferences that state before RINIT. The 8.5.12 patch adds php_basic_early_rinit(), a PS(in_rfc1867_update) flag that forces incomplete_classes_only inside the window, and removes zend_bailout() from the OOM path. The ordering is unchanged. The post_bytes_processed UAF theory behind most of the 70+ GitHub repos does not fire: the cached array's refcount walks 2 to 1 and never reaches 0 on instrumented 8.2.34 through 8.5.12 (xuehuolll audit, dinosn lab). Three paths survive 8.5.12: the var_destroy re-entry UAF, the serialize_handler mismatch, and upload-progress session injection. Labs: dinosn/php-cve-2026-10961x-lab-poc and xuehuolll/php2shell-CVE-2026-109618-109619

Releasing my lab as well PHP RCE dinosn/php-cve-2026-10961x-lab-poc , use it as a guidance and further reference for work upon. Patches are available at this moment PATCH! t.co

@jedisct1 This is a 4th variation and similar to my pre-existing PoC dinosn/php-8.5.5-var_destroy-uaf