Mirasvit under active exploitation: CVE-2026-45247

On 2026-06-03, CISA added CVE-2026-45247 to the Known Exploited Vulnerabilities (KEV) catalog. The flaw affects Mirasvit Full Page Cache Warmer, a Magento/Adobe Commerce extension that pre-populates the storefront cache so shoppers hit warm pages rather than cold PHP renders. According to the KEV entry, the extension deserializes untrusted data read from a request cookie named CacheWarmer; an unauthenticated attacker who supplies a crafted serialized PHP object achieves remote code execution against the web tier.

The blast radius is high. Cache warmers run inside the storefront application, share the same PHP process pool as checkout, and hold the database credentials, encryption keys, and payment integration secrets that make an e-commerce install monetizable to an intruder. CISA does not add entries to KEV on theory; the catalog is reserved for vulnerabilities with reliable evidence of exploitation in the wild. The federal Binding Operational Directive 22-01 remediation clock is already running for U.S. federal civilian agencies, and every commercial operator running the extension faces the same deadline.

What the flaw actually is

PHP object injection via unserialize() has been a canonical remote code execution primitive for more than a decade. When application code calls unserialize() on attacker-controlled bytes, the PHP runtime instantiates arbitrary classes already loaded in the request lifecycle and invokes their magic methods (__wakeup, __destruct, __toString, __call) as the object graph materializes and the garbage collector runs. If any reachable class contains a magic method that touches the filesystem, spawns a process, evaluates a string, or writes to a template, an attacker can chain those primitives into code execution. The Magento ecosystem is a rich target for such chains because both the platform and its extensions ship large numbers of loosely-coupled service classes.

The KEV summary is specific about the sink and the vector: the CacheWarmer cookie is the input, and the outcome is unauthenticated RCE. A minimal network probe looks like this:

GET / HTTP/1.1
Host: shop.example.com
Cookie: CacheWarmer=Tzo4OiJzdGRDbGFzcyI6MDp7fQ==
User-Agent: Mozilla/5.0
Accept: text/html

The base64 payload above decodes to O:8:"stdClass":0:{}, a harmless empty object. In a live attack, expect a much larger payload, either raw serialized PHP or base64-wrapped, that instantiates a gadget class chain resolvable in the storefront's autoloader. Two log-side signals stand out. First, requests carrying the CacheWarmer cookie from clients that never received a Set-Cookie from your storefront (the cookie appears on the first request from a source IP with no prior session). Second, CacheWarmer values whose decoded prefix begins with O:, a:, or C:, the PHP serialization type markers for object, array, and custom-serialized object respectively.

Am I affected?

Three questions, in order.

  1. Do you run Magento Open Source or Adobe Commerce with the Mirasvit Full Page Cache Warmer extension installed? Check composer.lock and app/etc/config.php for the module name (commonly Mirasvit_CacheWarmer or a similar namespace). Search the filesystem for CacheWarmer under app/code/Mirasvit/ and vendor/mirasvit/.
  2. Is the module enabled at runtime? Run bin/magento module:status and confirm the module appears under the enabled list. A disabled module still ships code on disk but is not wired into the request pipeline.
  3. Is the storefront reachable from the internet? Cache warmers are sometimes gated to internal cron subnets. If your edge tier blocks requests carrying a CacheWarmer cookie today, you have a partial mitigation, but patch anyway; internal pivot paths are common.

If you answer yes to (1) and (2), assume you are in scope until proven otherwise. If you answer yes to (3), you are exposed and the KEV timer is the operative deadline.

What to do inside the remediation deadline

Under BOD 22-01 the federal due date lands roughly three weeks after the KEV addition. Private-sector security teams should mirror that window. A defensible plan has three tracks running in parallel.

Track one: patch. Upgrade the Mirasvit Full Page Cache Warmer extension to the vendor's fixed release. Extension patches in the Magento ecosystem typically arrive as a version bump in composer.json; run composer update mirasvit/module-cache-warmer, redeploy static content, and re-run bin/magento setup:upgrade and bin/magento cache:flush under the deploy user. Confirm the module version in production with bin/magento module:info Mirasvit_CacheWarmer before you close the ticket.

Track two: virtual patch at the edge. Until every environment is on the fixed version, drop or strip the CacheWarmer cookie at the reverse proxy or WAF. An NGINX example:

map $http_cookie $cachewarmer_stripped {
    default $http_cookie;
    "~*(^|;\s*)CacheWarmer=" "";
}

server {
    listen 443 ssl http2;
    server_name shop.example.com;

    location / {
        proxy_set_header Cookie $cachewarmer_stripped;
        proxy_pass http://magento_upstream;
    }
}

This breaks the extension's legitimate warming flow; accept that trade-off. It removes the RCE primitive at the perimeter and buys time to complete the code-level fix. For production traffic, prefer a WAF rule that blocks requests whose CacheWarmer cookie decodes to a byte sequence starting with O:, a:, or C:.

Track three: hunt for prior exploitation. Assume opportunistic scans predated the KEV listing. Search access logs going back at least 90 days for requests carrying the CacheWarmer cookie from source IPs with no prior session activity, from cloud-provider ASNs outside your normal traffic profile, and for anomalously long cookie values. Search the PHP-FPM slow log and error log for unserialize warnings, __wakeup fatals, and unexpected PHP Notice entries referencing Mirasvit classes. On the host, look for new files under pub/, var/, and generated/ with mtimes that do not correlate with a deployment window; a common post-exploitation move is writing a webshell into a public directory or wiring a magic-method persistence hook into a template. Rotate any secret that lived on affected hosts: database credentials, encryption keys, payment gateway API keys, admin password hashes.

The broader KEV pattern

CVE-2026-45247 did not land in isolation. In the same week CISA also added CVE-2026-0257 in PAN-OS, CVE-2024-21182 in Oracle WebLogic Server, CVE-2022-0492 in the Linux kernel cgroups v1 release_agent path, CVE-2025-48595 in the Android Framework, and two supply-chain compromises in the JavaScript tooling ecosystem tracked as CVE-2026-48027 and CVE-2026-45321. The common thread is that unauthenticated network primitives and package-registry poisoning continue to dominate the exploited-in-the-wild set. If your KEV response process is still purely CVE-list driven, add two lightweight controls: an inventory-side check that flags any extension or npm package appearing in a KEV entry within 24 hours, and a rule that treats any deserialization sink reachable from an unauthenticated HTTP handler as a P1 finding regardless of vendor.

Patch the extension, strip the cookie, hunt the logs. Then close the ticket with evidence, not assurance.

Verifiable security.