Magento Stores Face Server Takeover Flaw CVE-2026-45247, Already Under Attack

A plugin for Magento (Adobe Commerce), the software that powers online stores worldwide, contains a flaw that lets attackers take over a shop's server remotely without ever logging in. Tracked as CVE-2026-45247, it carries a severity score of 9.8 out of 10 (critical).

What makes it urgent is that this hole is already being targeted. Security firm Imperva has observed real attacks attempting to exploit it ever since the patch shipped. The U.S. agency CISA has also added the flaw to its Known Exploited Vulnerabilities (KEV) catalog, its list of bugs confirmed to be used in attacks. Mirasvit, the maker of the plugin, released a fix on May 25, 2026, and affected stores are urged to update immediately.

What Are Magento and the Mirasvit Plugin?

Magento is software for building online stores. It bundles everything a shop needs to run on the web—product pages, a shopping cart, checkout (payment), and member management—and countless stores worldwide, from small businesses to large retailers, run on top of it. Since Adobe acquired it, the enterprise edition is also offered under the name "Adobe Commerce."

Magento lets you add features after the fact through "extensions" (plugins). The one at issue here is Mirasvit Full Page Cache Warmer. It pre-warms the "cache" (pre-built page output) to make pages load faster, and stores that care about speed install it. Shoppers never see its name—it quietly works behind the scenes, the unsung helper of the store.

The problem occurs when this plugin "restores data sent from the browser back into the original program objects." That restore step is technically called deserialization, and in the world of PHP (the language Magento uses) and Java, it has long been known as a dangerous, accident-prone operation. The same mechanism was behind the recent server-takeover flaw in the Apache MINA networking library.

What CVE-2026-45247 Does

An attacker can run any program on the server simply by sending the store's site a crafted "cookie." A cookie is a small piece of data the browser exchanges with a site—normally harmless, used for things like keeping you logged in. But with this plugin, sending a cookie whose contents the attacker has freely rewritten causes those contents to be executed on the server. This is called remote code execution (RCE), the most severe class of vulnerability, leading directly to server takeover. No login or account registration is required—anyone who can open the site can attack it.

The attack was first discovered by Sansec, a Dutch firm specializing in e-commerce security. Its scans found roughly 6,000 sites running Mirasvit extensions, and the real figure is likely higher. Like the Palo Alto VPN flaw we covered earlier, this is a no-waiting case where attacks have already begun.

When Shoppers' Card Numbers Are Skimmed Behind the Cart

This is no longer a theoretical concern. Right after the fix shipped, Imperva watched test attacks stamped "PWNED_CVE2026" and reconnaissance probes that deliberately stalled servers for five seconds to gauge a response—worldwide. In other words, attackers are already going store to store, looking for shops they can break into. That is exactly why it helps to picture, in plain terms, who reaches into this hole and what walks out of the shops they breach.

First in line are skimming crews that plant eavesdropping code on a store's checkout page to siphon off card numbers (so-called Magecart), ransomware gangs that encrypt a shop's server and demand a ransom, and initial-access brokers who carve out an entry point and sell it to other criminals. What they want is the credit card number and expiry a shopper types into the payment screen, their name, address, and phone number, order histories, member login passwords, and control of the store's admin panel itself. The moment a single crafted cookie reaches that site, the attacker's program starts running on the store's server, and everything behind the register passes into someone else's hands.

The takeover does not end with one strike. The attacker first plants a back-door program (a web shell) to come and go from the server freely, then quietly rewrites the checkout page's code to embed eavesdropping code that forwards card details to an outside server the instant a customer enters them. Shoppers believe they have made an ordinary purchase, while their numbers are siphoned off in the background. Stolen card and member data is traded on the dark web, and the information harvested there fuels chains of impersonation logins and fraud on other sites. The real terror of this kind of takeover is that the hole in one store's plugin becomes the doorway for thousands of customers who did nothing more than shop there.

And the bill comes back, in the end, to the store operator. If card data leaks, fines for breaching the card brands' security standard (PCI DSS), legally required breach reports and customer notifications, support inquiries, damages, and the customer flight that follows a reputation for "unsafe to pay there" all drag on for a long time. The figure 9.8 only marks the technical ceiling of severity; for the business running the shop, the real loss sits with the halted sales and the customers who walked away. Whether you can check right now if your store uses this plugin, and update it, is what decides which side of that line you end up on.

Which Stores Are Affected

Affected are Magento 2 stores running a version of Mirasvit Full Page Cache Warmer older than 1.11.12. The trouble is that no special configuration or admin login is needed to attack it. To quote Sansec's writeup: "any storefront request carrying a crafted CacheWarmer cookie reaches PHP's native unserialize() on attacker-controlled data, with no authentication, no admin session and no config toggle required." If you have it installed, it is safest to assume you are exposed.

You can check whether your store is affected with the table below. If your version is older than 1.11.12, updating is the top priority.

"I can't say off the top of my head which extensions my store has" is not an unusual situation. Magento runs by pulling in many external components (open-source libraries), and this attack abuses a mechanism inside that very pool of components. The idea of inventorying which software carries which parts is laid out in our piece on scanning the open-source supply chain.

What Is Happening Technically

At the core is how PHP's unserialize() function is used. To warm the cache, the plugin issues the browser a cookie named "CacheWarmer" and stores state inside it. The problem is that when that cookie comes back to the store, the plugin fed its contents straight into unserialize() without restricting which kinds of objects may be restored. Because the cookie's contents can be freely rewritten by the user (the attacker), malicious data can be planted there.

CVE-2026-45247: PHP Object Injection That Starts With a Cookie

Merely passing crafted data through unserialize() does not yet run a program. That is where a technique called a "gadget chain" comes in: it stitches together legitimate program parts that already exist inside Magento and its components, in an order other than intended, to finally reach command execution. According to Imperva's analysis, the observed attacks abused parts of the well-known logging library "Monolog," such as SyslogUdpHandler and BufferHandler, as these stepping stones. In other words, the plugin itself contains no attack code; the takeover succeeds by combining parts already present in the store's system.

The root cause—trusting data that arrives from outside and processing it as-is—is shared with the recently reported unauthenticated code execution in Samba and the takeover of the home network monitor Pi.Alert. Only the entry point differs—a cookie, a file, or a config value—but the failure pattern of "turning untrusted input into something executable" is the same.

Attacks Have Already Begun

What sets this apart from other vulnerabilities is that attacks were already observed by the time the patch shipped. The timeline below traces the path from Sansec's discovery to its listing in CISA's catalog of exploited bugs.

← Swipe to move

According to Imperva's observations, most attacks seen so far have been early-stage probes that "first verify vulnerability presence." Attackers appear to be screening which stores they can break into, ahead of a full intrusion. That makes now—before the attacks turn from probing to the real thing—the moment to update. We also keep tracking the CISA KEV catalog this flaw was added to on our Japanese-language dashboard.

How to Check Whether Your Store Is Being Targeted

Alongside updating, you'll want to check whether you've already been attacked. According to Sansec, the traces of an attack remain in the "CacheWarmer" cookie value that reaches the server. Exploit data is usually carried in an encoding called "base64," and because its prefix becomes a specific string, you can tell it apart.

Specifically, Sansec notes that if a CacheWarmer cookie value has the form CacheWarmer:(Tz|Qz|YT) (beginning with Tz, Qz, or YT), it is a strong indicator of an exploitation attempt. Search your web server's access logs for "CacheWarmer" and look for these suspicious values. In case an attack has succeeded, it is also safest to check whether unfamiliar PHP files have appeared in web-accessible directories, and whether the checkout page's code has been altered.

What to Do Right Now

The fix is simple: update Mirasvit Full Page Cache Warmer to 1.11.12 or later. The official changelog states that this version fixed "PHP Object Injection in session cookie deserialization." Since the attack needs no admin login, rather than putting it off with "we're probably fine," raising the version to close the hole itself is the fastest and surest move.

If you can't update right away, an interim defense is to use a Web Application Firewall (WAF—a wall that screens out malicious requests) to block those suspicious CacheWarmer cookies. But that only buys time; fundamentally, you need to update. Even after updating, it is recommended to preserve logs and investigate for intrusion, on the assumption that you may already have been breached. As a vulnerability in the permission layer of a web app, this is, like the arbitrary code execution in the WordPress plugin WPCode, a textbook case of "an add-on that supports the site quietly carrying a hole."

Frequently Asked Questions

References

• ▸NVD - CVE-2026-45247 Detail
• ▸Sansec - Critical vulnerability in Mirasvit Cache Warmer for Magento
• ▸Imperva - Customers Protected Against CVE-2026-45247
• ▸Mirasvit - Full Page Cache Warmer changelog (1.11.12)
• ▸VulnCheck - Mirasvit Cache Warmer for Magento PHP Object Injection
• ▸GitHub Advisory Database - GHSA-rg8p-9rpg-r32p
• ▸Cyber Security News - Critical Magento Cache Plugin Vulnerability
• ▸CISA - Known Exploited Vulnerabilities Catalog