Most web-skimming stories start with a stolen login or a hacked supplier. This one starts with a flaw that could do one thing: read a file. No code ran on the server and no password was guessed. The file it read was enough.
The flaw is CVE-2024-34102, named CosmicSting by the e-commerce security firm Sansec. It affected Magento Open Source and Adobe Commerce, the software behind a large share of independent online shops. By the autumn of 2024 Sansec had counted 4,275 stores with a payment skimmer on the checkout page, about 5% of all Magento and Adobe Commerce stores, among them the shops of Ray-Ban, National Geographic, Cisco and Segway. Some of those stores had installed the fix before the skimmer arrived.
Step 1: a request any visitor could send
Magento's web API turns the JSON in a request into PHP objects. It does this by itself: it looks at what type a field should be, builds an object of that type, and if that object has fields that are objects too, it builds those as well, as deep as the request goes.
The researcher Sergey Temnikov found that this nesting let a request reach classes that were never meant to be filled from outside. One of them was PHP's own XML class, which parses whatever XML it is given, including external entities. That is a classic XXE (XML external entity) flaw, reached through a side door. The endpoint that accepted such a request belongs to the guest checkout, so it needed no login. Adobe rated it CVSS 9.8.
Affected: 2.4.7, 2.4.6-p5, 2.4.5-p7, 2.4.4-p8 and everything older.
Step 2: one file, `app/etc/env.php`
An external entity can point at a file on the server, and the parser will fetch it and include it. Attackers asked for app/etc/env.php. Every Magento store has it. It holds the database password, and it holds the store's encryption key (the crypt/key value).
Magento uses that key to encrypt saved secrets such as payment gateway credentials. In current versions it also uses it for something a store owner would not guess: it signs the tokens (JWTs) that the API accepts as proof of a login.
Step 3: a token the store believes
Whoever has the signing key can write their own token that says "I am an administrator", and the store has no way to tell it from a real one. There is no login event, no failed password and no second factor, because no login takes place. The attacker now has the full REST API with admin rights: customers, orders, and content.
Step 4: a few lines added to a CMS block
Magento stores are built from CMS blocks: pieces of HTML that an admin edits in the back office, such as the footer or a banner. Blocks may contain script tags. That's a feature, and shops use it for chat widgets and tracking.
Through the API, the attackers listed the store's blocks and appended a short script to one that appears on the checkout. From then on the store itself served the skimmer to every shopper. No file on the server changed. The addition lived in the database, where a file-integrity scan doesn't look.
Step 5: seven groups, one checkout
Sansec identified seven separate groups using the same route and gave each a name. Their methods show how hard a skimmer is to spot by eye:
• One hid its loader in invisible Unicode whitespace that is decoded into JavaScript at run time, and only acted on checkout pages.
• One added a single script tag pointing at a domain that looked like a static-file CDN, and infected more than 650 stores with it.
• One loaded the skimmer over a websocket, so the code never appeared as a file in the browser's network list.
• One built fake payment forms to match the payment provider each large shop used, country by country.
• One sent the stolen data out through other, smaller hacked shops, so the destination looked like an ordinary store.
• Several groups often fought over the same shop. Sansec saw stores with three different skimmers at once.
In late August one group chained CosmicSting with CNEXT (CVE-2024-2961), a bug in the C library that PHP runs on, to go from reading files to running code on the server, and hid backdoors in background processes.
Timeline: priority 3, then 2, then 1
• 11 June 2024: Adobe releases the fix in a regular security update. Sansec's timeline notes it was given the lowest of Adobe's three priority ratings.
• 18 June: Sansec warns that 75% of stores haven't updated.
• 23 June: the researcher publishes details. Sansec sees the first attacks.
• 26 June: a full technical write-up is published and working exploits appear on GitHub. Adobe raises the rating.
• 27 to 28 June: Adobe releases a stand-alone patch for stores that can't take the whole update.
• 8 July: Adobe raises the rating to critical. By then, Sansec says, automated attacks had been running for a while and thousands of keys were already gone.
• 12 July: mass attacks on well-known stores. Around this time Sansec counts three to five stores hit an hour (reported by heise).
• 21 August: Adobe ships a hotfix that makes old encryption keys stop working.
• 4 September: Cisco's merchandise store is hit.
• October and November: new groups breach 2,000 stores in a few hours, then 1,200, then nearly 3,000.
Sansec's judgment on the window: a store that hadn't updated by 25 June should assume its key was stolen.
Why patching wasn't enough
The fix closed the file read. It did nothing about a key that had already been read. A store that updated on 1 July, after its key was copied on 28 June, was patched and still wide open: the attacker's forged tokens kept working, with no further need for the bug.
Adobe told merchants to rotate the encryption key after patching. Here the case has a second trap:
1. Rotating added a new key but kept the old one. Magento keeps earlier keys so it can still read data encrypted with them. Until Adobe's August hotfix, tokens signed with the old key were still accepted. Merchants who rotated in July believed they were done.
2. Rotation does not re-encrypt what was saved under the old key, so the old key stayed in the file for a reason.
3. Rotation does not cancel API tokens stored in the database. An attacker who had used their forged admin token to create an integration of their own kept that access.
4. The same file gave away the database password and anything else written in it.
A patch fixes the software. It doesn't take back what the bug already gave out.
Controls that break each step
Treat "no login needed" as urgent, whatever the label says
• The fix was public for twelve days before the first attacks and 75% of stores hadn't applied it. Adobe's first rating suggested there was time.
• Read the description, not the priority: a flaw in a shop platform that works before authentication goes in this week, not this quarter.
• If the full update is risky for your shop, ask your agency for the vendor's stand-alone patch. That option existed from 27 June.
After a file-read flaw, replace what the files held
• List what your configuration file contains: encryption key, database password, payment and shipping API keys, mail credentials. If the flaw was open while it was being used, each of those is known to someone else.
• Replace the encryption key and confirm the old one is refused, on the current patch level. Don't stop at "a new key was added".
• Reset admin passwords, review the list of admin users, and delete API integrations you don't recognise.
• This holds for any platform. A WordPress wp-config.php or a .env file is the same kind of file.
Look where the skimmer lives
• Review CMS blocks and pages for script tags, and for long runs of blank-looking characters. Compare with a database backup from before June if you still have one.
• In the access log, Sansec's indicator is a POST to the guest-cart estimate-shipping-methods API.
• Remember the limits of file scanning: here the malicious code was in a database row.
Limit what a script on the checkout can do
• A Content-Security-Policy on the checkout that lists the hosts scripts may load from and the hosts the page may send data to stops most of the loaders above: the look-alike CDN, the websocket, the exfiltration to another shop.
• Run it with reporting, so a blocked script tells you instead of failing silently. osec CSP Reports collects those reports and shows which new hosts your pages tried to load, without a change to your DNS.
• PCI DSS 4.0.1 has required this kind of control on payment pages since 31 March 2025: an inventory of every script with a reason for it (6.4.3) and a check that alerts on changes to the page as the browser receives it (11.6.1).
• A payment form hosted by your payment provider in an iframe keeps card fields out of your page. It helps, and it isn't complete: one of the seven groups replaced the form with a fake one.
Keep the admin API away from the open internet where you can
• The storefront needs the guest and customer API. The admin routes are used by a handful of systems: your ERP, your fulfilment partner. Allow those addresses and refuse the rest at the web server.
• Sansec's stop-gap for unpatched stores was exactly this for one route: refuse outside requests to the CMS block API. It didn't stop the file read, and it did stop the skimmer.
The lesson for a small shop
You may not run Magento. You almost certainly run something with a configuration file full of secrets and a page where customers type card numbers or passwords. CosmicSting is a reminder to ask two questions after every security update: what could this flaw have given away before I patched, and have I replaced it? And to watch the page your customers see, because that's where the damage shows up, not in your files.
Related reading: British Airways 2018, where 22 lines added to one script cost £20 million, and Polyfill.io, when a script tag sites already trusted changed hands.
osec CSP Reports collects your site's Content-Security-Policy reports and shows each new script host and blocked request, so a script you didn't add to your checkout doesn't go unseen. Paste one header, no DNS move.
Watch your scriptsSources: Sansec: CosmicSting attack and defense overview (timeline, attack stages, fixes); Sansec: CosmicSting fallout, 4,275 stores and seven groups; Assetnote (Searchlight Cyber): Why nested deserialization is harmful, Magento XXE CVE-2024-34102 (26 June 2024); Adobe security bulletin APSB24-40; Adobe knowledge base: APSB24-40 revised to include the isolated patch for CVE-2024-34102, and key rotation; heise: security experts observe many attacks on Adobe Commerce; The Hacker News: Adobe Commerce and Magento stores under attack from CosmicSting.