PHP2Shell, October 2026: two critical flaws in PHP itself (CVE-2026-109618 and CVE-2026-109619) were fixed on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Any site running on PHP needs the server updated. See our PHP2Shell Resource Center.
Magento, now split between Adobe Commerce and Magento Open Source, is the platform where the two worst properties for security meet: it is self-hosted, so nobody patches it unless you do, and it sits directly in a payment flow, so compromising it pays immediately.
That combination has made it the primary target of card-skimming campaigns for years. Attackers are not defacing these sites or sending spam from them. They are quietly injecting JavaScript into the checkout to copy card details as customers type them, and the entire objective is to remain unnoticed for as long as possible.
Skimming is the threat model
The pattern generally known as Magecart works like this: gain write access through any available route, inject a small script into a page in the checkout flow, and exfiltrate form field contents to an attacker-controlled endpoint. The store keeps working. Orders keep completing. Nothing is broken from the customer's point of view or from yours.
This has three consequences worth internalising.
You will not notice from the front end. Detection has to come from file integrity monitoring, from watching what scripts your checkout actually loads, or from your acquirer telling you that your store is the common point of purchase in a fraud pattern. The last of those is the most common and the most expensive.
The injection point is often not Magento itself. It is frequently a third-party extension, a compromised admin account, or a tag pulled in through a marketing tool. Any of them puts script on the payment page.
The liability is real. A skimming compromise is a card data breach with acquirer, PCI and disclosure consequences attached, not just a cleanup job. See PCI DSS 4.0 requirements, which now specifically address payment page scripts for exactly this reason.
Version support and patching
Magento 1 reached end of life in June 2020 and receives no security fixes. Stores still running it are unpatched against everything discovered since, and they remain a standing target precisely because attackers know some are still out there. If you are on Magento 1, migration is not a roadmap item, it is the finding.
On Magento 2 and Adobe Commerce, Adobe publishes security bulletins and patches on a regular cadence, with occasional out-of-band releases for critical issues. As with Drupal, publication is the starting gun: exploitation of Magento vulnerabilities after disclosure has historically been fast. Patching needs to be an obligation with an owner and a target time, not a quarterly task.
Two-factor authentication for the admin panel has shipped as a core capability since Magento 2.4 and should never be disabled. Where a store has turned it off for convenience, that is usually the shortest path to the problem described above.
Extensions and the admin panel
Magento extensions are code with full application privileges, frequently written for a single client and never updated afterwards. Treat the installed extension list as a security inventory with owners and update dates, not as a features list. See the plugin and app supply chain.
Move the admin panel off the default path, restrict it by IP or VPN where the business allows, and enforce 2FA on every account. None of these is sufficient alone; together they remove the easy routes. Also review admin accounts for people who left, which on commerce teams with agency involvement is a persistent problem. See access control and 2FA.
Monitor what the checkout loads
The single most valuable Magento-specific control is knowing exactly which scripts execute on your payment pages and being alerted when that set changes. A content security policy that restricts script sources, combined with change detection on the checkout, turns a silent skimmer into an alert. This is also now a compliance expectation rather than merely good practice.
Alongside that, run file integrity monitoring on the codebase, keep off-server backups, and have an incident response plan that accounts for the possibility of card data exposure, because that scenario has notification obligations attached and is not a decision to make under pressure.
If the operational burden here is beyond what the business can staff, a managed commerce platform genuinely removes most of it. See Shopify, BigCommerce, or the comparison in website security by platform.
