Magento 2 Security: Patch, Detect and Block ClickFix, PolyShell and CosmicSting

Magento 2 and Adobe Commerce stores are a permanent target for automated exploitation campaigns. Every new 2.4.x release ships a batch of security patches, and attackers reverse-engineer those patches within days to build working exploits against stores that have not yet updated. This article describes the most relevant threats observed in recent months, how to recognise the traces they leave on a server, and the practical steps to remove them and prevent the next intrusion.

Why unpatched 2.4.x installations are the primary target

Adobe publishes security bulletins for Magento Open Source and Adobe Commerce on a regular cadence, and each bulletin lists the vulnerabilities fixed in that release. The gap between the publication of a patch and the appearance of a public proof of concept is now measured in hours rather than weeks. A store that stays on an older patch level is effectively running published, weaponised vulnerabilities. The first countermeasure is therefore always the same: update the core to the latest secure version and apply every official patch and hotfix released for your branch.

ClickFix: the fake human verification checkbox

ClickFix is a social engineering technique that does not exploit Magento directly, but abuses the trust visitors place in a familiar interface. On a compromised store the checkout or the landing page is modified to display a fake Cloudflare 'verify you are human' widget. The visitor clicks the checkbox exactly as on a legitimate challenge page, and a script is silently written to the clipboard. Nothing harmful happens at that moment, and the page may even appear to continue normally.

The danger arrives in the second step. The fake page instructs the visitor to open a terminal window on macOS or Windows and paste the copied content to complete the verification. If the visitor complies, the pasted command downloads and executes a second-stage payload on the client machine. The rule for users is simple and absolute: never paste commands from a web page into a terminal. The rule for administrators is to find the injected script, remove it, and close the entry point that allowed the modification.

Server-side compromise: PolyShell, CosmicSting and env.php

Several families of vulnerabilities have dominated Magento 2 incident reports. PolyShell abuses unrestricted file uploads through the REST API to place polyglot files that are valid images and valid PHP at the same time. CosmicSting targets the template engine and can lead to unauthenticated remote code execution. StyleSmuggler and BlockStrap follow similar patterns of template injection and filter bypass. In the most severe cases the attacker reads env.php, extracts the cryptographic keys stored there and forges valid administrator tokens, which grants persistent backend access even after the vulnerable path has been closed.

Searching for obfuscated code in app, vendor and cache

Malicious code is rarely obvious. Attackers hide it inside standard .phtml templates, inside core modules and inside generated files in the cache and var directories. A plain text search for common keywords often returns nothing, because the payload is assembled at runtime from base64 strings or from several fragments concatenated together. A recent case involved an infected .phtml file inside the vendor folder that had been modified only slightly, with the malicious string split across several variables.

Compare your installation against a clean copy of the same version. Use a file integrity check, review modification timestamps and inspect any file that differs from the official package. When you find an infected file, do not simply delete the payload: restore the original version from the official archive, then upgrade or block the vulnerable path that allowed the write.

pub/media should never contain PHP

The media directory is designed to store images, PDFs and other static assets. There is no legitimate reason for a .php, .php7, .phtml or .phar file to exist under pub/media. Attackers nevertheless upload them constantly, and the favourite hiding places are pub/media/custom_options/ and pub/media/custom_options/quote/, where uploaded option files are stored. Scan these directories recursively, remove every executable file you find and verify that the upload configuration rejects unexpected extensions.

Blocking at the edge with Cloudflare, Nginx and Apache

Cleaning the server is not enough if the entry point stays open. Block the vulnerable paths before the request reaches Magento. In Cloudflare you can create a WAF rule that denies requests to /pub/media/custom_options/ and similar directories, or challenge any request that tries to reach a PHP file inside the media path. On the origin server, add equivalent rules in Nginx or Apache so that the protection still works when traffic bypasses the CDN.

Remember that a rule at the edge only stops the requests you already know about. Combine it with the patch, with file monitoring and with a periodic audit of the codebase.

Remediation checklist

Conclusion

Magento security is a cycle, not a single task. Patch quickly, verify the integrity of your files, keep executable code out of the media directory and block the paths you do not need. If you suspect a ClickFix injection, warn your customers immediately: the fastest way to stop the damage is to make sure nobody pastes anything into a terminal.