Incident response · 2026-06-30

Anatomy of a Magento Hack: CosmicSting → Card Skimmer → ClickFix

In June 2026 our team cleaned a compromised, end-of-life Magento 2.3 store. It wasn't a single backdoor — it was a full intrusion kit: a server-side card decryptor, a credential harvester, multiple webshells, an OS-level reverse shell persisted via cron, rogue admin accounts, and a public-facing ClickFix fake-CAPTCHA that served malware to the store's own visitors. The entry point was almost certainly CosmicSting (CVE-2024-34102), the same critical Magento bug mass-exploited across the world since 2024.

This is the full anatomy of that attack — who's at risk, what the malware can do, the exact patch that closes the door, and how to clean up without taking the store down. Names and indicators are anonymised; the techniques are exactly as found.

Not sure if you're exposed? Run a free MageArgus scan — it checks your version against CosmicSting's fixed patch levels and looks for web-reachable signs of compromise.

The attack chain, step by step

Modern Magento attacks are rarely "one and done." Here's how this one unfolded — a pattern you'll see again and again on unpatched stores:

Who is impacted

You should treat your store as at risk if any of these is true:

• You run Adobe Commerce / Magento Open Source below the CosmicSting fixed patch level for your branch (see the table below).
• You run an end-of-life branch (2.3.x or earlier) — these receive no security patches at all and are permanently exposed.
• You patched late — if your encryption key leaked before you patched, attackers can still forge admin access until you rotate it.
• You've never rotated the encryption key, admin passwords or API tokens since the store launched.

What this malware can do

Which patch fixes the entry point

CosmicSting (CVE-2024-34102) is fixed in these patch levels — anything below your branch's fixed level is vulnerable. Check with bin/magento --version:

Patch and rotate the key — patching alone is not enough if the key already leaked:

composer require magento/product-community-edition=2.4.7-p1 --no-update
composer update --with-dependencies
bin/magento setup:upgrade && bin/magento setup:di:compile
bin/magento encryption:key:change   # rotate the (already-exposed) key
bin/magento cache:flush

Full walkthrough in our how to apply a Magento security patch guide and the CosmicSting deep-dive.

Can't upgrade today? A stop-gap for EOL stores

EOL branches (2.3 and older) get no patch, and big upgrades take time. As a temporary shield, you can neutralise the XXE at the PHP layer with an auto_prepend guard that disables external-entity loading and blocks XXE payloads to the API — no core files modified. The MageArgus module ships this as a one-command mitigation:

bin/magento mageargus:shield:cosmicsting install
bin/magento mageargus:shield:cosmicsting status

This is a stop-gap, not a cure: it stops future exploitation, but you must still rotate the already-stolen key and plan the upgrade off EOL Magento.

How to clean a store that's already hit

1. Contain. Enable maintenance mode (or take checkout offline). Snapshot the server first for forensics.
2. Remove web backdoors. Delete every PHP file under pub/media / pub/static (none should execute there), all adminer.php / DB clients, and any polyglots — match the whole filename, not just the extension (.php8, .php., .php_00.png).
3. Kill persistence. Inspect crontab -l, ~/.bashrc, ~/.profile and ~/.config for base64 -d | bash, gs-dbus or [kcached]; remove the line, kill the process, delete the dropped files.
4. Restore core files. Re-install Magento packages from clean releases so any injected core/vendor file is overwritten.
5. Purge rogue admins & tokens. Delete unknown admin_user rows and integration tokens, especially any created around the exposure window.
6. Clean the database. Search cms_block, cms_page and core_config_data (header/footer/Misc HTML) for injected <script>, data: URIs, clipboard or powershell strings — that's where ClickFix and skimmers hide.
7. Rotate everything. Encryption key, all admin passwords, DB password, SSH credentials, and every gateway/SMTP/cloud key the harvester could have touched. Verify ~/.ssh/authorized_keys for unknown keys.
8. Patch the entry vector and re-scan to confirm clean.

If you've found indicators, follow the full Magento hacked recovery plan.

Why a free remote scan can't promise "clean"

The most dangerous part of this case was the cloaking. The ClickFix payload only rendered for real browsers, so a quick "view source" or basic scanner saw nothing. On-disk webshells and database-level skimmers are invisible from outside entirely. A remote scan is great for catching version/CVE exposure and web-reachable indicators — but a definitive "clean" answer needs a file + database scan on the server. That's exactly the gap the MageArgus module fills.

Frequently asked questions

Which Magento versions are affected by CosmicSting (CVE-2024-34102)?

Any Adobe Commerce / Magento Open Source below the fixed patch levels 2.4.7-p1, 2.4.6-p6, 2.4.5-p8 or 2.4.4-p9 (APSB24-40). End-of-life branches like 2.3.x are permanently vulnerable because Adobe ships no patch for them.

If I patch CosmicSting, am I safe?

Patching stops future exploitation, but if your encryption key was already stolen the attacker can keep forging admin access. You must also rotate the key with bin/magento encryption:key:change and audit for rogue admins, tokens and planted files.

What is the ClickFix fake-CAPTCHA malware?

ClickFix is an injected overlay that copies a Windows PowerShell or mshta command to a visitor's clipboard and social-engineers them into running it (Win+R, paste, Enter), installing an info-stealer or RAT. It is often cloaked so it only shows to real browsers, making it invisible to many remote scanners.

Was credit card data stolen?

In this incident the attacker deployed a card decryptor and credential harvester, so any card data the store processed must be treated as compromised. Stores that offload payment to a hosted/iframe gateway (PayPal, Amazon Pay, hosted Stripe) and never store PANs are far less exposed — but the breach must still be reported to your PSP/acquirer.

Related reading

• CosmicSting (CVE-2024-34102): The Magento XXE Bug Explained
• Magento Vulnerabilities You Can't Ignore in 2026 (CVE List)
• Magecart Skimmers: How Card-Stealing Malware Hides in Magento Checkouts
• My Magento Store Was Hacked — Here's the Exact Recovery Plan

Scan your store free →