One cookie to your storefront homepage is shell. CVE-2026-45247 has a Saturday deadline.

An anonymous visitor loads your storefront homepage. No login, no admin token, no special endpoint. The request carries a cookie named CacheWarmer, and that cookie is a base64-encoded PHP object. Your server unpacks it and runs whatever command it carries, as the web-server user. That’s the whole attack. CISA added it to the KEV catalog on June 3 with a federal remediation deadline of June 6, an unusually short three-day window. If you run a Magento or Adobe Commerce store with this extension, the operational question isn’t “should I schedule this.” It’s “can I patch before Saturday.”

What changed

CVE-2026-45247 is an unauthenticated remote code execution flaw in the Mirasvit Full Page Cache Warmer extension for Magento 2 and Adobe Commerce, scored 9.8 on CVSS 3.1 and 9.3 on CVSS 4.0 by NVD (CWE-502, deserialization of untrusted data). The extension reads the CacheWarmer cookie on ordinary storefront requests and feeds the raw bytes straight into PHP’s unserialize() with no class allowlist. That’s enough to trigger a PHP object-injection gadget chain and run OS commands. Sansec disclosed it on May 26. Mirasvit had already shipped the fix in version 1.11.12 on May 25, a day ahead of the public advisory.

You don’t need to understand the gadget chain to act on this, and this desk isn’t going to walk you through it. The one thing worth carrying: the cookie fires on every page load, so there’s no authentication gate and no narrow endpoint to watch. Any publicly reachable affected store is directly exploitable by an anonymous request.

What it means for your environment

If you run Magento Open Source or Adobe Commerce, this is a today problem, because the two share the codebase and the extension doesn’t distinguish editions. If you don’t run Magento, skip to the last section for the one transferable lesson. There’s no point pretending this advisory is universal.

The blast radius for affected stores is the worst kind. Command execution as the web-server user means access to database credentials in env.php, stored payment tokens, customer PII, and a foothold for lateral movement. This is a storefront component, internet-facing by default, so the vulnerable path is reachable from the open internet without anyone logging in.

Two wrinkles change who’s actually exposed, and both work against you.

First, you may be running this without knowing it. Imperva flagged that Cache Warmer can ship bundled inside other Mirasvit packages, so a store can have it installed without anyone choosing it as a standalone product. The “we don’t use that extension” answer in your change ticket is not the same as “Composer confirms we don’t have it.”

Second, the version range has no floor. NVD and Sansec both state it only as “before 1.11.12” with no named lower bound. Treat the entire pre-1.11.12 history as vulnerable. There’s no “we’re on an old-but-safe build” exception to reach for.

For scale: Sansec’s passive scans found roughly 6,000 stores running Mirasvit extensions, and noted the real number is higher because CDN and WAF fronting hides the fingerprint. So the visible exposure is a floor, not a ceiling.

What you need to do

Run this from your Magento root to settle whether you’re affected. The Admin UI does not reliably surface third-party extension versions, so Composer is the authoritative check:

composer show mirasvit/module-cache-warmer

If the package is present and the version is below 1.11.12, or if it shows up inside another Mirasvit bundle, you’re exposed. Inspect composer.lock for the package and its version if composer show is ambiguous.

Question	Answer
Was I exposed?	composer show mirasvit/module-cache-warmer (or check composer.lock) shows any version before 1.11.12. The Admin UI won’t tell you.
Patch	composer update mirasvit/module-cache-warmer to 1.11.12, released May 25.
Can’t patch today?	Block or strip the CacheWarmer cookie at the edge before it reaches PHP. Failing that, disable the extension and eat the cache-warm performance cost.
Detect	Look in HTTP logs for a CacheWarmer cookie whose value matches CacheWarmer:(Tz|Qz|YT)[A-Za-z0-9+/=]*. Those three prefixes are serialized PHP objects, per Sansec.

The patch is the real fix. The changelog describes 1.11.12 as fixing a PHP object-injection vulnerability in session-cookie deserialization. One honest caveat: the vendor didn’t publish a diff, so whether the fix removes unserialize() outright or gates it behind an allowed-classes list isn’t confirmed from a primary source. It fixes the bug either way; just don’t assume more about the mechanism than the changelog states.

If you genuinely can’t deploy before the window, the edge block is your bridge. The regex above is a reliable WAF signature, and both Imperva and Sansec offer blocking layers that intercept these payloads. A bridge is not a patch. Update as soon as the window allows.

Then check your logs, because patching doesn’t tell you whether you were already hit. Imperva observed early payloads using validation commands like echo PWNED_CVE2026_$(date +%s) and sleep 5 to confirm execution before any follow-on. A CacheWarmer cookie of the shape above is an attempt; one of those probe commands landing in your logs is a sign the attempt worked. If the patch lagged, Sansec advises scanning pub/ for webshells as a post-compromise check.

The window

The federal deadline is June 6, three days from the June 3 KEV listing. KEV listing means CISA has confirmation of real-world exploitation, not just a proof of concept. You’re probably not a federal civilian agency, but the deadline reflects how fast this moved, and an internet-facing unauthenticated RCE under active exploitation does not respect your maintenance freeze. This one moves to the front of the queue.

Be precise about what’s confirmed, because it shapes how loud the alarm should be. Sansec found and fixed-flagged the bug; its write-up is a discovery-and-detection document, not an exploitation witness. The in-the-wild evidence comes from Imperva, which documented an attack wave of serialized-object payloads shortly after disclosure, characterizing the early activity as mass scanning to confirm RCE, hitting gaming and business sites across the US, UK, France, and Australia. What’s documented is opportunistic RCE confirmation at scale. There’s no confirmed linkage to skimming, card theft, or ransomware yet, and no named threat-actor attribution as of June 5. That’s not reassurance. Mass RCE confirmation is exactly the reconnaissance that precedes a skimmer drop, and the web-skimming economy specifically hunts this surface.

Which is the part worth keeping if you don’t run Magento at all. An internet-facing application that calls unserialize() on attacker-controlled input is game over, every time. This is the same lineage that produced SessionReaper and CosmicSting; the constant is deserialization of untrusted input plus gadget chains living in the platform’s own dependency tree. The newer twist is the supply chain: third-party extensions widen the attack surface faster than anyone audits them. Most merchants run dozens of barely-reviewed extensions, and Sansec found backdoors across 21 extensions from three vendors that sat dormant since 2019 before activating. The transferable question for any platform you run, e-commerce or not: which of your add-ons can take attacker-controlled input, and when did you last actually inventory them?

If you run a Magento storefront, the deadline is Saturday and the check is one Composer command. If you don’t, the lesson is that your third-party extensions are an under-watched supply chain, and the day you find out which one deserializes input shouldn’t be the day it’s in the KEV catalog. PatchDay Alert exists to flag the cookie-to-shell ones before they hit your Monday queue, so the deadline doesn’t surprise you.