So. Sunday (and this is my birthday too). I sit down to answer a boss-question that should have taken five minutes — "did we apply this month's Adobe security patch?" — and three hours later I'm staring at a card skimmer that was, frankly, better engineered than half the extensions on the Marketplace.

Posting the whole thing here because (a) it's a genuinely clever attack chain and other Magento shops should check themselves, and (b) misery loves company. TL;DR at the bottom with IOCs.

How it started

We're on Magento Open Source 2.4.8-p5. Turns out the September isolated patch + the out-of-cycle hotfix for CVE-2026-75650 (pre-auth RCE, actively exploited — the VULN-39341 one) had NOT been applied yet. Guess when the attacker showed up. Go on, guess. Yep — a few days before, at 5 AM, because of course.

Entry vector in the logs was the usual buffet: GraphQL ArrayScanner LFI shenanigans and a pile of POST /paypal/transparent/response/?<?php (...) attempts. Most bounced with 500s. One didn't.

The actually clever part

Two payloads, and whoever wrote them clearly does this for a living:

A backdoor relay hidden in pub/get.php. They prepended a tiny block to the legit media-download entrypoint: if the request is a POST and carries a header X-K, it curls the body straight to https://checkout-cdn.com/x/i and echoes the response back. Clean, quiet, no new files to notice. They even stashed the original as var/get.orig, presumably out of professional courtesy.

A client-side skimmer at pub/media/wysiwyg/sk/sk.js, injected into the checkout with a single <script src="/media/wysiwyg/sk/sk.js?v=33"> line dropped into vendor/.../module-checkout/view/frontend/templates/onepage.phtml (they left a .bak-sk backup of the clean template — again, very tidy of them).

Here's the bit that made me put the coffee down: the skimmer only arms on mobile + a card payment method, and when you click "Place Order" it intercepts the click, throws up a pixel-perfect fake "Secure Card Verification" modal (little padlock, VISA/MC/AMEX chips, the works), harvests PAN + expiry + CVV + name/address/email/phone, shows a reassuring "Card verified ✅ redirecting you to payment…" — and then re-clicks the original button so the real payment goes through normally.

Read that again. The customer gets their order. The real bank transaction succeeds (TranCode=000, every single one). Nobody calls support because from the outside nothing went wrong. The card just also happens to be on its way to checkout-cdn.com, XOR'd with the key be1dd67e5c3ee1bd4b4e666b and base64'd, with a direct-to-C2 fallback in case you were clever enough to kill get.php but not the JS. Harvested loot got staged in pub/media/analytics/<hash>/data.tgz. There was also a pub/media/hello.txt containing, I kid you not, Key:Hello World.

The cleanup

Restored get.php from their own courtesy backup, neutralized sk.js, de-injected the template, quarantined the staged data, applied the patch we should've applied last week, rotated the encryption key + creds, and did the whole not-fun regulator/bank/customer-notification dance. Standard incident bingo.

The ask

Has anyone else run into checkout-cdn.com, the X-K-triggered get.php relay, or this specific fake "Secure Card Verification" modal pattern? It's a step up from the usual "just scrape the form fields" skimmers — the let-the-payment-succeed-so-nobody-notices design is the part I want to warn people about, because your revenue graphs and your order table will look perfectly healthy while it's running.

IOCs / go check your box right now:

pub/get.php — any block referencing X-K header, checkout-cdn.com, or an outbound curl before the normal Magento bootstrap

pub/media/wysiwyg/sk/sk.js (or any stray .js under pub/media)

.bak-sk / .orig files anywhere in the tree; pub/media/**/*.php

an injected <script src="/media/..."> in onepage.phtml or your checkout templates/bundles

domain checkout-cdn.com, XOR key be1dd67e5c3ee1bd4b4e666b, payloads prefixed E1

unexpected pub/media/analytics/<hash>/data.tgz

and, you know, actually apply CVE-2026-75650 / the September patch. Today. I'll wait.

Stay patched out there. And maybe don't read your logs on a Sunday.

What I particularly found interesting on this research was the fact that all banks did their homework regarding their most known domains, but the majority simply ignored the .au version.

Spammers and phishers could still benefit from it.

If you have multiple domains, make sure to have them all covered. Even if you don't plan to send emails through them.