CVE-2026-45247 is a PHP unserialize() call on a cookie value in a Magento cache warmer extension. The vulnerability is technically simple—the code takes a CacheWarmer cookie and passes it directly to unserialize(). The severity, however, is not calculable from the flaw alone. What elevates this from a medium-rated deserialization bug to a critical is the attack surface it anchors into: Magento's full object graph. You're not exploiting a single component; you're detonating the entire class hierarchy of a platform that sits between payment gateways and customer databases, processing payment cards, PII, and inventory in the same memory space. The gadget chains available in Magento and its dependencies aren't theoretical—they exist, they're documented, and they turn this unserialize() call into a master key for one of the most sensitive e-commerce stacks in production. The unauthenticated access vector compounds this: no credentialed foothold required, you're reaching the deserialization handler directly from the network. The cache warmer context adds another dimension. This extension is designed to crawl, fetch, and process URLs at scale. The server was already primed to handle incoming requests and map application state—meaning an attacker doesn't need to enumerate your application; they're using your own cache warmer to do reconnaissance and lateral movement. That's a built-in attack capability handed to the attacker pre-compromised. The CVSS 9.8 paired with an EPSS of 0.27546 warrants attention. The EPSS likely reflects opportunistic scanning frequency, not whether sophisticated actors are already exploiting this. When a technique is automated and weaponized into mass-scanning tooling, the 'probability' metric becomes nearly meaningless for prioritization—the exploit isn't waiting to be discovered, it's being deployed. Assume active exploitation in any mass-scan campaign and prioritize accordingly. Your operational priorities: verify whether the CacheWarmer cookie is set by the extension's own crawler logic (which would require a prior request cycle to establish state) or directly controllable by unauthenticated clients. If it's the latter, treat this as unauthenticated RCE and patch immediately. If it's the former, you still have a serious vulnerability—but the exploitation path is multi-step rather than immediate. Regardless, the fix is unambiguous: remove the unserialize() call entirely, replace with json_decode() or a whitelisted class approach, and audit any other cookie or input handling in the extension. Given that this pattern has been documented as catastrophic since 2009 and the attacker's tooling has been commoditized via phpggc and gadget chain catalogs, treat the absence of this flaw in your deployment as a control gap, not a fortunate absence.
CVE-2026-45247
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedMirasvit Full Page Cache Warmer for Magento 2 before version 1.11.12 contains a PHP object injection vulnerability that allows unauthenticated attackers to achieve remote code execution by supplying a crafted serialized PHP object in the CacheWarmer cookie. Attackers can exploit the unrestricted call to PHP's native unserialize() function combined with gadget chains available in Magento and its dependencies to execute arbitrary code on the server.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceMirasvit Full Page Cache Warmer for Magento 2 before version 1.11.12 has a PHP Object Injection vulnerability where the application calls unserialize() on the CacheWarmer cookie without validation. Unauthenticated attackers can inject crafted serialized PHP objects and leverage gadget chains present in Magento and its dependencies to achieve remote code execution.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
NVD · CPE data< 1.11.12CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Verify Mirasvit Full Page Cache Warmer extension is installedCheck for the extension by searching for 'Mirasvit_CacheWarmer' in vendor directory: ls -la vendor/mirasvit/module-cache-warmer/ or check composer.json for mirasvit/module-cache-warmer entryAffected if The extension directory or composer entry exists in the Magento 2 installation
-
Determine installed version of the extensionCheck composer.lock for mirasvit/module-cache-warmer version, or run: composer show mirasvit/module-cache-warmer 2>/dev/null | grep versionAffected if The version shown is less than 1.11.12 (e.g., 1.11.11, 1.10.x, etc.)
-
Locate the vulnerable CacheWarmer cookie handlerSearch the codebase for 'CacheWarmer' cookie handling: grep -r 'CacheWarmer' app/code/vendor/mirasvit or grep -r ' unserialize' vendor/mirasvit/module-cache-warmer/ | grep -i cookieAffected if Code exists that reads a 'CacheWarmer' cookie and passes it to unserialize() without validation
-
Check if the warmer functionality is accessibleTest if the cache warmer endpoint is reachable by examining router configuration in vendor/mirasvit/module-cache-warmer/etc/frontend/routes.xml or di.xmlAffected if The extension's router is configured and the controller handling the cookie-based request is active
If the Mirasvit Full Page Cache Warmer extension version is below 1.11.12 and the CacheWarmer cookie handling code using unserialize() is present in the codebase, the installation is affected by this vulnerability.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scoped1.11.12
Upgrade to version 1.11.12 or later. As an interim control, consider deploying WAF rules to block or sanitize the CacheWarmer cookie, or temporarily disable the extension if upgrade is not immediately feasible.
1.11.12
- Verify current installed version of Mirasvit Full Page Cache Warmer extension using composer show mirasvit/module-fpc-warmer or via Magento admin
- Backup the Magento database and files before proceeding
- Run composer update mirasvit/module-fpc-warmer to upgrade to version 1.11.12
- Clear Magento cache after upgrade: php bin/magento cache:clean && php bin/magento cache:flush
- Verify the new version is installed: composer show mirasvit/module-fpc-warmer
Generated from the published advisory — verify against the referenced sources before acting.
- Consultation4.0 h
- Implementation8.0 h
- Testing6.0 h
- Review / QA3.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $5,888.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-45247 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesCVE-2026-45247 is a PHP unserialize() call on a cookie value in a Magento cache warmer extension. The vulnerability is technically simple—the code takes a CacheWarmer cookie and passes it directly to unserialize(). The severity, however, is not calculable from the flaw alone. What elevates this from a medium-rated deserialization bug to a critical is the attack surface it anchors into: Magento's full object graph. You're not exploiting a single component; you're detonating the entire class hierarchy of a platform that sits between payment gateways and customer databases, processing payment cards, PII, and inventory in the same memory space. The gadget chains available in Magento and its dependencies aren't theoretical—they exist, they're documented, and they turn this unserialize() call into a master key for one of the most sensitive e-commerce stacks in production. The unauthenticated access vector compounds this: no credentialed foothold required, you're reaching the deserialization handler directly from the network. The cache warmer context adds another dimension. This extension is designed to crawl, fetch, and process URLs at scale. The server was already primed to handle incoming requests and map application state—meaning an attacker doesn't need to enumerate your application; they're using your own cache warmer to do reconnaissance and lateral movement. That's a built-in attack capability handed to the attacker pre-compromised. The CVSS 9.8 paired with an EPSS of 0.27546 warrants attention. The EPSS likely reflects opportunistic scanning frequency, not whether sophisticated actors are already exploiting this. When a technique is automated and weaponized into mass-scanning tooling, the 'probability' metric becomes nearly meaningless for prioritization—the exploit isn't waiting to be discovered, it's being deployed. Assume active exploitation in any mass-scan campaign and prioritize accordingly. Your operational priorities: verify whether the CacheWarmer cookie is set by the extension's own crawler logic (which would require a prior request cycle to establish state) or directly controllable by unauthenticated clients. If it's the latter, treat this as unauthenticated RCE and patch immediately. If it's the former, you still have a serious vulnerability—but the exploitation path is multi-step rather than immediate. Regardless, the fix is unambiguous: remove the unserialize() call entirely, replace with json_decode() or a whitelisted class approach, and audit any other cookie or input handling in the extension. Given that this pattern has been documented as catastrophic since 2009 and the attacker's tooling has been commoditized via phpggc and gadget chain catalogs, treat the absence of this flaw in your deployment as a control gap, not a fortunate absence.
Practitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-45247 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data