Another Maximum-Severity Magento RCE — So How Does This One End?

The webshell usually has a boring name. media.php. index2.php. Something that blends into a directory nobody audits. By the time someone notices, the card skimmer has been live for three weeks, the customer database has been dumped to a server in a country you can’t extradite from, and the forensics bill is larger than the revenue the site made that quarter.

I’ve sat through this postmortem more than once. The names change, the CVE numbers rotate, but the breach pattern doesn’t. So when BleepingComputer reports a maximum-severity flaw in BlockStrap — CVE-2026-103849 — allowing unauthenticated remote code execution on Magento and Adobe Commerce servers, I already know roughly how this story goes. The only open question is who reads the advisory before the attackers do.

Here’s what’s confirmed in the reporting: it’s rated maximum severity, it’s an unauthenticated path to arbitrary PHP execution, and it rides in through BlockStrap — a component sitting on Magento/Adobe Commerce storefronts. Unauthenticated matters more than any CVSS decimal. It means no stolen admin session, no phished credential, no foothold required. A request to a reachable endpoint and the attacker is running your code as your web user. On a typical Magento box that user can read app/etc/env.php, which hands over your database credentials, your crypt key, and your payment gateway config in one file.

What I’m not going to do is quote you affected version ranges and a patch build number I don’t have. The initial reporting doesn’t include confirmed fixed versions, and manufacturing guidance from speculation would get someone breached while they wait for a release that doesn’t exist yet. Go to the Adobe Security Bulletin and the BlockStrap advisory for the exact affected and fixed versions before you touch production. Everything below assumes you’ve done that.

Find out if you’re holding the bag

You can answer “am I exposed” in about five minutes from a shell on the box. All read-only:

1
2
3
4
5
6
7
8
9
10
11
12
13

# Magento/Adobe Commerce edition and version
php bin/magento --version
​
# Is BlockStrap installed, and at what version?
composer show 2>/dev/null | grep -i blockstrap
grep -i blockstrap composer.lock
​
# Enabled modules — is the component actually active?
php bin/magento module:status | grep -i blockstrap
​
# Look for a webshell that's already there (report only)
find pub/ var/ media/ -name '*.php' -newermt '-30 days' -type f 2>/dev/null \
  | grep -vE '/(get|static|cron)\.php$'

If the module is installed and enabled and your storefront is internet-facing, treat yourself as exposed until the vendor advisory tells you otherwise. Then check whether the endpoint is actually reachable from outside, not just present on disk:

1
2
3

# From an external host, not localhost. Replace the path once the
# advisory names the vulnerable route. HEAD only — do not send a payload.
curl -sS -I -A "exposure-check" https://store.example.com/ | head -n1

What to do before the PoC drops

No confirmed active exploitation is in the reporting yet — “exploitation could be imminent” is a forecast, not an IOC. Don’t let anyone tell you the SOC is on fire when it isn’t. But Magento RCEs have an ugly habit of going from advisory to mass-scanning in days, and this one is unauthenticated, which is exactly the profile that gets weaponized first.

1. Patch to the vendor’s fixed version. The moment Adobe/BlockStrap publishes it, that’s your fix. Nothing below replaces it.
2. If you can’t patch today, disable BlockStrap. php bin/magento module:disable the component, flush cache, and confirm the storefront still functions. A missing feature beats a breach.
3. Put a WAF rule in front of the endpoint once the advisory names it. Block or sharply rate-limit unauthenticated POSTs to that route. This buys hours, not safety.
4. Lock down /admin and backend paths to an allowlist or VPN. Won’t stop an unauthenticated storefront bug, but it shrinks what a foothold can reach next.
5. Rotate secrets assuming compromise if the module was exposed before you patched — DB password, crypt key, payment API keys. The file they’d read first contains all three.

The lesson, again

Every one of these incidents traces back to the same three failures. You don’t know what components are installed, so you can’t act on an advisory in minutes. Your storefront runs as a user that can read every secret you own. And your detection for a new PHP file in a public directory is “a customer complained.” Fix those and the next max-severity Magento RCE — there will be one — is a Tuesday patch instead of a postmortem.

The webshell still gets a boring name. You just won’t be the one who finds it six weeks too late.