Someone Is Backdooring Magento Stores Through a Door Adobe Hasn’t Locked Yet

The tell is usually a file nobody remembers writing. A four-line PHP script sitting in a media directory that should only ever hold product images, timestamped to some Tuesday at 3 a.m. when the store did roughly no business. By the time an engineer notices it, the interesting work has already happened: the attacker has a foothold, a persistence mechanism, and — on a lot of stores — a card skimmer quietly reading checkout forms.

On September 5, 2026, the Dutch e-commerce security firm Sansec published an advisory that reframed that scene from “unlucky” to “everyone.” They report a zero-day in Magento Open Source and Adobe Commerce that lets an unauthenticated attacker run code on the server. No password. No stolen admin session. No CSRF token to fish out. Just a request to a public-facing endpoint that the platform trusts more than it should. And critically: no patch existed when the exploitation started, and none had been published when the advisory went out.

That last part is the whole story. Everything else is detail.

The door with no lock on it

Think about the difference between a burglar picking a lock and a burglar walking through a doorway that was never fitted with one. Picking a lock takes skill, time, and — usually — some credential to work against. Most vulnerability response is built around that model: rotate the keys, patch the lock, watch the door.

An unauthenticated remote code execution bug is the second case. The doorway is public by design — it faces the open internet because it has to, because that’s how a storefront works. The flaw is that a request coming through it can be shaped so the application does something it was never meant to do: write a file, execute a command, hand back a shell. There is no credential to steal because none is required. Every internet-facing store running the affected code is reachable by anyone with the exploit and a list of targets, and scanning the entire IPv4 space for Magento installs is a weekend project, not a heist.

Sansec’s advisory attributes the exploitation to a public-facing input path — the kind of form-submission or upload handling that a storefront exposes to anonymous visitors by necessity. I’m going to stay deliberately vague on the exact mechanism, because the useful information for defenders is “an anonymous request reaches code execution,” not a working recipe. If you’re building detections, that’s the shape to hunt for: traffic to legitimate front-end endpoints that ends with new files on disk.

What we actually know, and what’s still soft

Here’s where I’ll be honest about the edges of the reporting, because manufactured precision is how bad advisories get people hurt.

• CVE: pending CVE assignment at the time of writing. Don’t wait for the identifier to act — the number is bookkeeping, the exploitation is now.
• Affected products: Sansec names both Magento Open Source and Adobe Commerce. Until Adobe publishes exact version ranges, the safe operating assumption is that any install you haven’t personally confirmed as out of scope is in scope. Scope-narrowing is the vendor’s job; your job today is defense.
• Authentication required: none. This is the part that sets your response clock.
• Patch: not available when the advisory dropped. Treat this as a compensating-controls situation, not a patch-and-forget one.

If those blanks fill in after publication — a CVE lands, Adobe scopes the versions, a hotfix ships — that changes your remediation, not your urgency. Go check now.

How to tell if it already happened

Because the payload plants files, the fastest signal is a filesystem that has grown things it shouldn’t have. Magento’s directory layout works in your favour here: several directories are supposed to contain data, not executable code. A .php file living in pub/media, media, var, or generated is almost never legitimate. That’s your first sweep.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

#!/usr/bin/env bash
# Magento backdoor triage — REPORT ONLY. Deletes nothing.
# Run from the Magento web root, or set ROOT explicitly.
ROOT="${1:-$(pwd)}"
​
echo "== PHP files in data/media directories (should be ~none) =="
find "$ROOT"/pub/media "$ROOT"/media "$ROOT"/var "$ROOT"/generated \
  -type f -name '*.php' 2>/dev/null
​
echo
echo "== Files modified in the last 7 days under web-writable paths =="
find "$ROOT"/pub "$ROOT"/var "$ROOT"/generated "$ROOT"/app/etc \
  -type f -mtime -7 2>/dev/null -printf '%TY-%Tm-%Td %TH:%TM  %p\n' | sort
​
echo
echo "== Common one-liner backdoor signatures =="
grep -RIlE "eval\(|assert\(|base64_decode\(|gzinflate\(|shell_exec\(|passthru\(|\\\$_(POST|GET|REQUEST)\[" \
  "$ROOT"/pub "$ROOT"/var "$ROOT"/generated 2>/dev/null

Second sweep: the admin table. A favourite post-exploitation move is to mint a fresh administrator so the attacker keeps access even after the hole is closed. Enumerate admin users and their last-login times and reconcile against your own list. Anything you can’t name is a finding.

1
2
3
4
5

# List admin accounts and creation/login times (adjust creds/socket).
# READ-ONLY select. Compare 'created' timestamps against your change log.
mysql -u magento -p magento -e \
"SELECT user_id, username, email, is_active, created, logdate, failures_num
 FROM admin_user ORDER BY created DESC;"

Third sweep: your web logs. You’re looking for POSTs to front-end endpoints followed, within the same second or two, by requests to a path that isn’t part of the application — the file the attacker just wrote.

1
2
3
4

# Requests to .php files outside the normal front controllers.
# Legit Magento traffic hits index.php / static.php / get.php — little else.
awk '$7 ~ /\.php/ && $7 !~ /(index|static|get|cron)\.php/ {print $1, $4, $6, $7, $9}' \
  /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -50

If any of these light up, treat the host as compromised — full stop. Rotate every credential the box can touch (database, admin, API integration keys, payment gateway tokens), pull the machine for forensic imaging if you can, and assume the checkout flow may have been skimming. A backdoored store isn’t just your problem; it’s your customers’ card numbers.

What to put in front of the hole today

You can’t patch what the vendor hasn’t shipped, so you narrow the doorway instead. In priority order:

1. WAF rule on the exposed endpoint. Your WAF vendor is very likely publishing a virtual patch for this — deploy it, but don’t stop there. Add your own rule that blocks or heavily challenges anonymous requests to the affected input path. A generic rule that flags requests resulting in PHP being written is worth more than a signature that matches one payload variant.
2. Lock the admin panel to known IPs. This won’t stop an unauthenticated storefront exploit, but it kills the attacker’s convenient second stage and cuts credential-stuffing noise. Allowlist your office and VPN egress ranges at the reverse proxy, not in application config.
3. Rate-limit anonymous POSTs. Mass exploitation is a volume game. Aggressive rate limiting on unauthenticated form endpoints raises the cost of spraying your store and buys you detection time.
4. Turn on file integrity monitoring — now, before the patch. A tripwire on pub, media, var, and generated that alerts on any new .php file is the single highest-value control here, because it catches the payload regardless of how the request got in. Make the web-writable directories as non-executable as your stack allows.
5. Watch outbound too. Skimmers and backdoors phone home. Egress filtering and DNS logging on the store’s server turn “we got popped” into “we got popped and here’s who they called.”

When Adobe ships the fix, patch immediately and then re-run the triage sweeps above. Patching closes the door; it does not evict anyone who already walked through it.

The urgency, plainly

This is an immediate, drop-the-sprint-board situation, and I don’t say that lightly. The combination is the worst one there is: no authentication, active exploitation confirmed by a credible source, an internet-facing target, and no patch. Every hour an affected store sits exposed is an hour someone with a scanner and a payload has a clean shot. The stores getting hit aren’t being targeted — they’re being harvested.

So pull the lessons out of the wreckage, because this pattern will happen again to a different platform:

1. Unauthenticated RCE resets your clock to zero. “We rotated the admin passwords” is irrelevant when the flaw needs no login. Sort your inventory by whether a vulnerability requires credentials — that single attribute should reorder your entire response queue.
2. File integrity monitoring is the control that doesn’t care how they got in. Detections tied to a specific payload age out in days. A tripwire on directories that should never hold executable code catches the class of attack, not the instance. If you deploy one thing from this piece, deploy that.
3. “No patch yet” is a plan, not a dead end. WAF virtual patching, endpoint allowlisting, rate limiting, and egress control are all things you own and can move on today. The vendor’s timeline is not your timeline.
4. Assume post-exploitation persistence, not just entry. The rogue admin account and the phone-home channel outlive the hole. Closing the vulnerability without hunting for what’s already inside is how you get re-owned the week after you patch.
5. Storefronts are payment infrastructure wearing a marketing costume. A compromised Magento box isn’t a defaced blog. It’s a live feed of your customers’ card data. Scope your incident response — and your disclosure obligations — accordingly.

Go run the first script. If it comes back empty, you bought yourself the time to deploy the controls calmly. If it doesn’t, you needed to know an hour ago.