A 9.8 in a Magento Plugin Nobody Audits: CVE-2026-45247 Turns a Cache-Warmer Cookie Into Remote Code Execution. CISA Cataloged It June 3. Patch Tonight.
- Patrick Duggan
- 1 minute ago
- 4 min read
On June 3, CISA added CVE-2026-45247 to its Known Exploited Vulnerabilities catalog, and the detail that matters is not the 9.8 CVSS score, though it earns that. The detail that matters is where the flaw lives. It is not in Magento core. It is not in Adobe Commerce's authentication layer or its payment plane. It is in Mirasvit Full Page Cache Warmer — a third-party performance extension that a merchant's developer bolted on years ago to make category pages load faster, and that almost certainly nobody on the security team has thought about since. The vulnerability is an insecure deserialization of untrusted data: an attacker supplies a crafted serialized PHP object inside the CacheWarmer cookie, the extension deserializes it without validation, and that object instantiates into arbitrary PHP execution on the server. A cookie becomes code. On an e-commerce box. Where the payment flow lives. That is the whole attack, and it is already happening in the wild, which is why it is on the KEV and why "next maintenance window" is the wrong answer.
Here is the mechanism in plain terms, because deserialization bugs get hand-waved and they should not. PHP's unserialize() is a known-dangerous primitive: when it reconstructs an object from a string, it can be coaxed into invoking the magic methods of whatever classes exist in the application — __wakeup, __destruct, and friends — and in a sprawling codebase like Magento, with hundreds of loaded classes, an attacker can chain those method calls into a so-called POP gadget chain that ends in code execution or file write. The Cache Warmer extension trusts a cookie it controls, but a cookie is client-supplied data, and client-supplied data is attacker-supplied data the moment someone decides to lie. CVE-2026-45247 is what happens when a performance feature treats a cookie as a private channel instead of a hostile input. The fix on the vendor side is the textbook one — stop deserializing untrusted input, or sign and verify the cookie so a forged object never reaches unserialize() — but the fix on your side is to patch the extension or pull it, tonight.
Now the part we keep saying until it stops being true, which is the shape, not the CVE. This is a soft-surface bleed. The hard perimeter of a modern Magento store is reasonably well-defended: the core gets patched, the admin panel sits behind 2FA, the payment integration is PCI-scoped and audited. The soft surface is the dozen third-party extensions that came in through the marketplace, each one running with full application privilege, none of them in anyone's patch SLA, most of them maintained by small shops on their own release cadence. We have watched this exact asymmetry play out all year on the dependency side — poisoned npm packages, the Shai-Hulud-class supply-chain worms, the runtime and metadata compromises that account for the overwhelming majority of recent incidents at companies whose core was never touched. A Magento extension is the same category of risk wearing a different hat: privileged third-party code inside your trust boundary that your threat model quietly assumes is benign. The attackers stopped assuming that a long time ago. CVE-2026-45247 is them collecting on the assumption gap.
So, the hunt-tonight, because a 9.8 that is already exploited does not respect your change-freeze. First, inventory: determine whether Mirasvit Full Page Cache Warmer is installed on any of your Adobe Commerce or Magento Open Source instances. composer show will tell you, and so will a glance at app/code and the module list — and if you are not sure, that uncertainty is itself the finding, because you cannot patch what you have not enumerated. Second, remediate on the emergency timeline: apply the vendor's patched release if one is available, and if it is not, disable the extension — a slower category page is a survivable problem; remote code execution on your storefront is not. Third, hunt for exploitation, not just exposure: look for unexpected PHP files under your web root and var directories, anomalous outbound connections from the web server, unfamiliar admin users, and — the loud one for this specific bug — inbound requests carrying a CacheWarmer cookie with an unusually long or structured value, because a serialized PHP object payload does not look like a normal cache token. Fourth, block the infrastructure: our STIX feed carries the indicators we have for active e-commerce-skimmer and webshell campaigns at no cost, and our IOC index will answer a cross-correlation query on any IP, domain, or hash you pull off a suspect box. Defenders should not have to buy the thing that stops the thing.
The honest cap, 95% as always: we cannot tell you the public exploitation reporting names every variant of this attack, and deserialization gadget chains are notoriously version-specific — the exact POP chain that works depends on which classes and which Magento version you are running, which means absence of a working public proof-of-concept for your build is not safety, it is just a researcher who has not gotten to your build yet. We cannot promise Cache Warmer is the last marketplace extension to detonate this quarter; it will not be, because the soft surface is wide and almost none of it is in a patch SLA. What we can tell you is that CISA does not catalog things that are not being used, the attack reduces to "a cookie becomes code," and the highest-value ten minutes you will spend tonight is finding out whether that cookie is one your store will deserialize. Patch it, pull it, or hunt it — but do it before the weekend, because the weekend is when they use these.
The threat feed this post is built on
1.14M+ IOCs, STIX 2.1, precursor signals, supply-chain detection. Free API key in 30 seconds.