British Airways spent the start of this week explaining how roughly 380,000 payment card details walked out of their website and app between late August and the 5th. No catchy name. No logo. No dedicated website with a clever pun and a download link for the proof-of-concept. Just a quiet, nasty bit of skimming script lifting card numbers, CVVs and all, straight off the payment page as people typed them.
I keep coming back to the contrast, because we've trained ourselves over the last few years to pay attention to the wrong things. A vulnerability with a logo and a website gets a fortnight of headlines, a flurry of patching, and a thousand blog posts. A breach like this one, which is closer to how people actually get robbed, gets a day of coverage and a press release about taking customer security "extremely seriously".
The mechanics here aren't exotic. The reporting points at attacker-controlled JavaScript running on the payment flow, the same family of attack people have started calling Magecart: compromise a script the site loads, and you don't need to touch the server-side card handling at all, because the card data is right there in the browser before it's encrypted to anyone. If you control any script on the page, you control the form. That's the whole game.
What makes it worse is how mundane the failure is. Most sites pull in a pile of third-party JavaScript: analytics, tag managers, chat widgets, the lot. Every one of those is a script you've invited onto your most sensitive page and largely stopped thinking about. You don't need a zero-day in TLS to skim cards. You need one neglected third-party include and a site that loads it onto the checkout.
There are defences, and they're not new. Subresource Integrity pins the hash of a script so a swapped file simply won't run. A tight Content Security Policy stops the page from exfiltrating to wherever the attacker fancies. Just not loading half a dozen marketing scripts onto the page where people enter card numbers would help most of all. None of it is glamorous, none of it has a logo, and that's exactly why it doesn't get done.
So here's the uncomfortable bit. The branded vulnerabilities, the ones with the marketing, are genuinely useful for getting budget and attention onto a class of problem. I've used them that way myself, waving a logo at a manager to get a patch window approved. But they've quietly skewed our sense of risk. The thing most likely to cost your customers actual money this year isn't the named CVE everyone tweeted about. It's a forgotten script tag on a checkout page, doing exactly what it was told, for someone else. No name. No website. Just your card details, gone.