A critical remote code execution flaw in a widely deployed Magento extension is being actively exploited in the wild, and CISA has made it official. CVE-2026-45247, affecting the Mirasvit Full Page Cache Warmer extension, carries a CVSS score of 9.8 and requires zero authentication to exploit. Attackers are already hitting live stores. If you run Magento and haven't audited your extension stack this week, that needs to change today.
CISA's Known Exploited Vulnerabilities catalog exists for exactly this situation: a flaw that isn't theoretical, isn't sitting in a proof-of-concept repository somewhere, but is being used right now against production systems. CVE-2026-45247 was added to that catalog after confirmed active exploitation across Magento server infrastructure. Every US federal civilian agency has a binding remediation deadline. For enterprises and public-sector organisations in the EMEA region, the KEV listing should be read as a strong operational signal, not a matter for the next quarterly review.
The vulnerability itself is classified as a deserialization of untrusted data issue — specifically PHP Object Deserialization — and it affects every version of the Mirasvit Full Page Cache Warmer extension prior to 1.11.12. The patch landed on 25 May 2026. If your store is running anything older than that, you are exposed to unauthenticated remote code execution from anyone on the internet who knows how to craft a cookie.
Mirasvit Full Page Cache Warmer is a commercial Magento extension with a straightforward performance purpose: it pre-loads pages into Magento's full-page cache so that real visitors get fast responses instead of waiting for cold-cache page generation. To do that work, the extension processes configuration data during its cache-warming operations, and it does so via cookies. That cookie-handling mechanism is the attack vector.
As CybersecurityNews reported, the extension is widely deployed across Magento e-commerce installations. Research by Sansec identified roughly 6,000 stores running Mirasvit extensions, though as The Hacker News noted, that figure almost certainly understates the real number. CDNs like Cloudflare mask the underlying technology stack, so automated scans can't see every deployment. The true install base is likely considerably larger. That matters when you're trying to understand how wide the blast radius of this vulnerability actually is.
PHP's unserialize() function is the root cause here. When the application passes attacker-controlled input to unserialize(), PHP will instantiate whatever object the attacker specifies , it doesn't check whether that object type is expected or safe. On its own, instantiating an object might seem harmless. The danger comes from gadget chains.
A gadget chain attack doesn't require the attacker to inject new code into your server. Instead, it reuses class definitions already present in your application. PHP magic methods , __wakeup(), __destruct(), and similar , execute automatically when an object is deserialised or cleaned up. An attacker who understands the class hierarchy of your Magento installation can craft a serialised object that, when deserialised, triggers a chain of these magic method calls through existing classes, each one passing execution to the next, until the chain terminates in something dangerous: a file write, a shell command, a network callback. The application's own logic becomes the weapon.
This is why no web application firewall can fully block this class of attack. As the source context makes clear, no WAF signature can enumerate every possible gadget chain, because the chains are assembled from legitimate application code. The only reliable fix is to patch the deserialisation point itself, which in this case means upgrading to version 1.11.12. Understanding your full attack surface across every third-party extension you've deployed is what makes the difference between catching this kind of exposure before exploitation and finding out about it from your SIEM at 2 a.m.
Attribution in e-commerce attacks is rarely clean, but the targeting pattern here is specific enough to be actionable. The exploitation activity isn't indiscriminate background noise , it has a shape, and understanding that shape helps you calibrate your response.
According to research cited by The Hacker News, attack activity has primarily targeted gaming and business sites. Those two categories make sense together: gaming platforms often run high transaction volumes and store payment credentials, while "business sites" in this context likely refers to B2B e-commerce operations with established supplier relationships and procurement workflows , exactly the kind of environment where a persistent implant can sit quietly for months, harvesting order data and customer records.
Geographically, the four most targeted countries identified are the United States, the United Kingdom, France, and Australia. Two of those four are in the EMEA region, and France in particular is a significant Magento market. If you're operating or hosting Magento infrastructure in Western Europe, you are squarely in the targeting geography for this campaign. That's not a reason to panic , it's a reason to act before the weekend.
Remote code execution on a web server is not the end goal , it's the entry point. Once an attacker has RCE on a Magento host, the standard playbook involves establishing persistence, moving laterally if the host is networked to databases or internal systems, and then either deploying skimming code to intercept payment card data at checkout or exfiltrating the entire customer and order database.
Magento stores are high-value targets for exactly this reason. They sit at the intersection of customer identity data, payment information, and often direct API connections to ERP and fulfilment systems. A compromised Magento server doesn't just expose your store , it can be a staging point into your wider internal network, particularly in deployments where the Magento host shares network segments with back-office infrastructure. Knowing what indicators of compromise to look for in this specific attack chain is critical for your detection and response capability.
The payloads observed in the wild include attempts at arbitrary command execution on the underlying server operating system, according to Imperva. That means attackers aren't just probing the PHP layer , they're going straight for OS-level access, which suggests they're either after persistent shell access or trying to install tools for lateral movement.
One of the most useful things about having Imperva's analysis available is that it moves this vulnerability from the abstract to the concrete. You can see what the malicious requests actually look like, which means your security operations team can build detection rules around real observed patterns rather than theoretical attack shapes.
The attack arrives via the CacheWarmer cookie. That's the specific HTTP cookie the Mirasvit extension uses to pass configuration data during its warming operations, and it's the input the vulnerable code deserialises without sufficient validation. An attacker sends a crafted HTTP request to your Magento store with a malicious value in that cookie. The extension processes it, calls unserialize(), and the gadget chain executes.
What Imperva observed in active traffic is base64-encoded serialised PHP objects delivered through that cookie. The base64 encoding serves a practical purpose: it allows binary serialised data to travel cleanly in an HTTP header without character encoding issues, and it introduces a minimal layer of obfuscation that might slip past naive string-matching rules. Decode the base64 and you'll find a serialised PHP object structure designed to trigger the gadget chain on deserialisation. As SecurityWeek confirmed, the exploit requires no authentication whatsoever , any unauthenticated HTTP request carrying the right cookie value is sufficient.
This attack pattern has low complexity and no prerequisites. That's precisely why the CVSS score sits at 9.8. An attacker doesn't need stolen credentials, doesn't need to have visited the site before, doesn't need to be on a specific network. They send a request. If your store is unpatched, that request executes code.
Imperva's telemetry identified specific test commands used by attackers to verify that their exploit worked. These included invocations of PHP's system() and current() functions. The use of system() is straightforward: it executes a shell command and returns the output, so an attacker might call system('id') or system('whoami') to confirm they're running as the web server user. Seeing that output in a response confirms RCE. current() is a PHP array function that's occasionally used in gadget chains to probe execution state.
These test patterns matter for detection. If your web application logs, SIEM, or WAF telemetry shows unusual responses tied to CacheWarmer cookie values , particularly base64 strings of significant length , that's a signal worth investigating immediately. Mature cyber threat intelligence programmes will already be processing the Imperva and Sansec data into detection rules, but if you're doing this in-house, the cookie name and the function invocations give you two concrete strings to hunt for across your log estate.
The immediate action is unambiguous: upgrade the Mirasvit Full Page Cache Warmer extension to version 1.11.12. That is the patched release, published on 25 May 2026, and it is the only reliable remediation for CVE-2026-45247. There is no configuration change, no server-side filter, and no WAF rule that substitutes for patching the deserialisation point. If upgrading immediately isn't operationally possible , for instance, if you need a staging environment test cycle first , then consider temporarily disabling the extension entirely until the patch can be applied. A slower store is better than a compromised one.
Beyond the immediate patch, this incident is a prompt to audit every third-party Magento extension in your stack. Commercial extensions from reputable vendors like Mirasvit are professional products, but they still introduce code that runs with the same privileges as your core Magento installation, and they don't always receive the same scrutiny. Check each extension against its vendor's current release notes, look for any pending security advisories, and remove extensions you're no longer actively using. Every piece of code that runs on your Magento host is part of your attack surface.
Review your server-side logging configuration. You want HTTP headers including cookies logged at a level where you can run retrospective searches. If you haven't been logging CacheWarmer cookie values, you cannot perform a thorough retrospective investigation to determine whether your store was probed or compromised before you patched. Go back through your access logs now and look for any requests carrying unusually long or base64-formatted CacheWarmer cookie values. Document what you find.
If you run a web application firewall, submit a rule to inspect and block anomalous CacheWarmer cookie content , specifically base64-encoded strings that, on decoding, resemble serialised PHP object structures (i.e., strings beginning with O: or a: followed by numeric length indicators). This won't catch every possible gadget chain variant, but it will filter opportunistic scanners running known payloads. Treat it as a detection mechanism, not a fix.
Finally, if you have any evidence of exploitation , unusual processes spawned by your web server user, unexpected outbound connections, unfamiliar files in your Magento root or /tmp directory , treat this as a full incident. Isolate the host, preserve forensic images, and begin your incident response process. Don't patch over a compromised system and assume you're clean. Attackers who achieved RCE before you patched may have already deployed persistence mechanisms that survive the extension upgrade.
Based on the observed attack traffic documented by Imperva, the primary technical indicator is the presence of base64-encoded serialised PHP object data within the CacheWarmer HTTP cookie on inbound requests to your Magento store. Legitimate cache warming operations will use structured but far simpler cookie values; an unusually long, high-entropy base64 string in that cookie field is anomalous and warrants investigation.
At the application layer, look for evidence of PHP system() calls appearing in your PHP error logs or in any application performance monitoring output. If your PHP configuration logs warnings about object instantiation during deserialisation, those log entries may reference class names that are unexpected in normal cache-warming flows. Correlate those timestamps against your web access logs to identify the specific requests involved.
At the operating system layer, investigate for web server processes , typically running as www-data, nginx, or apache depending on your stack , spawning unexpected child processes. A web server process calling id, whoami, curl, wget, or bash is a strong post-exploitation signal. Review your process accounting logs or EDR telemetry for the period since the vulnerability was first publicised.
Check your Magento file system for recently modified or created PHP files in locations where user-generated content isn't expected , particularly in the root directory, pub/media, or any cache-related directories. Web shells deposited through RCE frequently masquerade as legitimate Magento files with names like cache.php or config.php. File integrity monitoring that baselines your Magento install against a known-good state will surface these quickly.
Outbound network connections initiated by the web server process to external IP addresses or domains not in your expected third-party service list are another signal , particularly connections on non-standard ports or to recently registered domains. If your server-side firewall policy doesn't restrict outbound connections from your Magento host by default, addressing that as part of your post-incident hardening is worthwhile.
Attacks like this one rarely announce themselves through official channels first. New payloads, active infrastructure, and exploitation techniques circulate in closed forums and private channels well before any public research surfaces them. By the time an incident makes it into a threat report, organisations without early visibility are already behind.
Defendis gives your security team that early visibility. We monitor the dark web, underground forums, and threat actor channels so your team receives relevant intelligence before it becomes breaking news , context about emerging threats matched against your organisation's exposure, without requiring your analysts to spend time in places they should not have to go.
The most direct method is to check your Magento admin panel under Store > Configuration > Advanced > Advanced, where installed modules are listed. You can also inspect your server's file system directly: the extension installs under app/code/Mirasvit/CacheWarmer in a standard Magento 2 directory structure. If you have command-line access, running bin/magento module:status | grep Mirasvit from your Magento root will show whether the module is installed and whether it's enabled. Check the installed version in the extension's composer.json or the module's registration file , anything below version 1.11.12 is vulnerable.
The Common Vulnerability Scoring System rates vulnerabilities on a scale from 0 to 10 based on factors including how complex the attack is, whether authentication is required, and what the potential impact on confidentiality, integrity, and availability is. A score of 9.8 is in the Critical band and reflects that this vulnerability requires no authentication, no user interaction, and no special privileges to exploit , and that successful exploitation gives an attacker full control over the affected system. In practical terms it means that anyone on the internet with the exploit code can run arbitrary commands on your server without knowing any credentials or having any prior access. Very few vulnerabilities score this high, and when they do, patching speed matters enormously.
Patching to version 1.11.12 is the required remediation and closes the specific deserialisation vulnerability. It is the necessary step. But if your store was running a vulnerable version during the period of active exploitation , which begins at least from the date of public disclosure , you should also perform a retrospective compromise assessment before declaring the matter closed. Patching prevents future exploitation; it does not remove any backdoors or web shells an attacker may have already planted. After confirming the patch is applied, review your access logs for anomalous CacheWarmer cookie activity, check for unexpected files in your Magento directory tree, and review outbound network connections from your web server. Additional hardening steps , restricting outbound connections, enabling file integrity monitoring, reviewing PHP configuration to disable dangerous functions where feasible , are good practice regardless of this specific incident.
The Mirasvit Full Page Cache Warmer extension as described in CISA's KEV entry and the supporting research is a Magento 2 extension. The vulnerability is in that extension's code, not in Magento's core. If you're running Magento 1 , which has been end-of-life since June 2020 , you face a separate and serious set of concerns, but CVE-2026-45247 specifically targets the Mirasvit extension as deployed on Magento 2 installations. That said, if you are still operating Magento 1 in production in 2026, the absence of vendor security support for that platform is itself a significant risk that warrants a separate conversation with your security and development teams.
CISA updates the KEV catalog continuously , new entries are added whenever CISA determines that a vulnerability has evidence of active exploitation in the wild. There is no fixed schedule; additions can happen daily. For organisations outside the United States, the KEV catalog carries no binding obligation, but it is one of the most operationally useful free threat intelligence feeds available. Every entry represents a vulnerability that has been confirmed as exploited, not merely theoretical. Monitoring it , either directly via CISA's published JSON feed or through a threat intelligence platform that ingests it , gives your security team early warning of vulnerabilities requiring immediate attention. The gap between KEV addition and widespread exploitation is often very short.
Not inherently. A CDN like Cloudflare sits between your visitors and your origin server and can provide WAF capabilities if you've purchased and configured them. But the exploit payload here is delivered via an HTTP cookie, which CDNs typically pass through to the origin server. Unless you have a specific WAF rule deployed on your CDN that inspects and blocks the malicious CacheWarmer cookie pattern, the request will reach your unpatched Magento installation and the deserialisation will occur. Ironically, as The Hacker News noted, CDNs also mask the true scale of Mirasvit extension deployments because they hide the underlying technology stack from external scanning tools , meaning attackers targeting this vulnerability may have difficulty identifying your store as a target through passive reconnaissance, but anyone conducting active exploitation attempts will still reach your origin if their requests aren't blocked. A CDN is not a substitute for patching.
