CosmicSting is not one victim, which is what makes it worth a page. CVE-2024-34102 was published on 11 June 2024 and raised to critical severity on 8 July. Over the following months, security firm Sansec reported that seven distinct criminal groups used it to break into 4,275 Adobe Commerce and Magento stores.
Sansec put that at around 5% of the entire platform estate, and named stores including Ray-Ban, National Geographic, Cisco and Segway among those found carrying malware. None of those companies confirmed the findings publicly, so treat them as Sansec's reporting rather than as established fact.
Cybercriminals have hacked 5% of all Adobe Commerce and Magento stores this summer.
- Sansec, October 2024
The part that should worry you: patching did not stop it
The attack stole the store's secret encryption key. Applying the patch closed the hole that let the key be taken — but it did not change the key, and a key already in an attacker's hands still worked afterwards.
When stores updated their systems, existing secret keys were not invalidated automatically, leaving the stores vulnerable to unauthorized access.
- Sansec, October 2024
Adobe published guidance on rotating keys manually. Many merchants never did it. The result is a large number of businesses that did the responsible thing, applied a critical patch promptly, believed themselves fixed, and were injected with a skimmer regardless.
None of that is an argument against patching, and it should not be read as one — patch, always, and quickly. It is an argument that server-side vulnerability management is not the same discipline as client-side security. Once the key was gone, the compromise stopped being visible on the server at all. The only place it remained visible was the browser: a script on the checkout page that had not been there before, sending data somewhere new.
The injection was in the CMS, not the codebase
With a valid key the attackers minted API tokens and modified the checkout through CMS blocks — content managed inside the application, not files on disk.
That detail defeats a whole category of defence. File-integrity monitoring across the webroot compares files against what they should be, and every file was exactly as it should be. A code review finds nothing, because the malicious content was never in the code. One group tracked by Sansec, which they named Polyovki, infected more than 650 stores by embedding a script from a host they controlled — so on the page it looked like one more external dependency among many.
What all of it has in common is that it is plainly visible in the browser. A page that loads a script it has never loaded before, or sends checkout data to a host it has never used, is describable regardless of how the change was made or where it was stored. That is what Script Watch and Data Watch are watching.
This is what PCI DSS 6.4.3 and 11.6.1 were written for
The two requirements map onto this campaign almost line by line. 6.4.3 asks you to know and authorise every script on a payment page — an injected CMS block creates a script nobody authorised. 11.6.1 asks for a mechanism that detects unauthorised modification of the payment page as the customer's browser receives it — which is the only vantage point from which this attack was ever visible.
If you are working through those requirements, our PCI DSS Compliance page maps our features onto them, and the PCI DSS guide covers the requirements in full.
How we can help
You don't need a mature Content Security Policy to benefit from our tooling. To use Script Watch or Data Watch, you can start auditing the JavaScript running on your pages, and the destinations receiving data from them, with a single line of code or config.
Once that is deployed we establish a baseline for your site, and then alert you to anything that changes. The most damaging feature of a Magecart attack is rarely its sophistication — it is how long it runs before anybody notices. Reach out to sales@report-uri.com if you would like a demo or a trial with no commitment.
