Magento RCE via Extension: CVE-2026-45247 Teardown

Overview of the Vulnerability

A critical remote code execution vulnerability in the Mirasvit Full Page Cache Warmer extension for Magento 2 and Adobe Commerce allowed attackers to execute arbitrary code on affected systems without authentication. CVE-2026-45247 scores 9.8 on CVSS v3.1 and results from unsafe PHP deserialization (CWE-502). The vulnerability is actively exploited, prompting CISA to add it to the Known Exploited Vulnerabilities catalog. Mirasvit released version 1.11.12 with a security fix.

Attackers can exploit this vulnerability by sending a crafted HTTP request containing a malicious serialized PHP object. When the application deserializes this object, it executes the attacker's code with the web server's privileges.

Timeline of Events

The timeline for this vulnerability follows a familiar pattern for extension-based attacks:

1. Vulnerability introduced in the Mirasvit Full Page Cache Warmer codebase through unsafe deserialization handling.
2. Active exploitation begins (timeline unknown, but confirmed ongoing).
3. Mirasvit releases patched version 1.11.12.
4. CISA adds CVE-2026-45247 to the KEV catalog, indicating widespread exploitation.
5. Organizations running unpatched versions remain vulnerable to unauthenticated RCE.

The delay between patch availability and CISA KEV inclusion suggests many organizations were unaware of their compromise until after the fix was released.

Identified Control Failures

Secure Development Practices

The Mirasvit extension deserialized user-controlled input without validation, violating secure coding principles. Developers should avoid deserialization of user input or implement strict allowlisting of permitted classes.

Extension Vetting Before Deployment

Organizations deployed this extension without a security review. Static analysis tools scanning for unsafe unserialize() calls could have flagged this issue. The gap: no security gate between "vendor ships extension" and "extension runs in production."

Runtime Application Security Monitoring

The vulnerability requires no authentication and produces distinctive HTTP patterns. Web application firewalls or runtime application self-protection tools configured to detect deserialization attacks might have blocked attempts. The gap: insufficient visibility into application-layer attacks.

Vulnerability Management for Third-Party Code

Many organizations track CVEs for their core platform but not for extensions. When Mirasvit released 1.11.12, affected organizations needed a process to identify which extensions they were running, map them to CVE announcements, and prioritize patching. The gap: no systematic tracking of third-party component versions.

Privilege Boundaries

The web server user likely had excessive filesystem and database permissions. When attackers achieved code execution, those privileges determined their impact. The gap: insufficient application of least privilege at the OS and database layers.

Relevant Standards and Requirements

PCI DSS v4.0.1 Requirement 6.3.2

"Security vulnerabilities are identified and addressed as follows: [...] Critical or high security vulnerabilities are resolved based on the risk ranking defined in the entity's vulnerability risk rankings."

A CVSS 9.8 vulnerability with active exploitation qualifies as critical. Organizations processing payment card data must have identified this vulnerability and patched it according to their defined timeline (typically 30 days for critical findings, though active exploitation should accelerate response).

PCI DSS v4.0.1 Requirement 6.4.3

"All scripts (for example, scripts run on payment pages and scripts for checkout processes) are managed as follows: [...] The scripts are reviewed to confirm they are necessary and authorized."

Third-party extensions that interact with payment flows require explicit authorization and review. Organizations should maintain an inventory of all extensions, document their business justification, and review their code or obtain security attestations from vendors.

OWASP ASVS v4.0.3 Section 5.5.3 (Level 2)

"Verify that deserialization of untrusted data is avoided or is protected in both custom code and third-party libraries."

This requirement applies to your codebase and to extensions you deploy. When you install a Magento extension, you're accepting responsibility for its security posture. ASVS Level 2 is appropriate for any application handling sensitive data.

ISO/IEC 27001:2022 Annex A.8.31

"Information security requirements shall be identified, documented and implemented for the acquisition, development and maintenance of systems and applications."

Before deploying the Mirasvit extension, your organization should have documented security requirements for third-party code, verified the vendor's development practices, and established a process for tracking security updates.

Action Items for Your Team

Build an Extension Inventory and Update Process

Create a spreadsheet listing every Magento extension in production. Include: extension name, vendor, current version, business owner, last security review date. Set up monitoring for vendor security advisories. When Mirasvit announces a CVE, you need to know within hours whether you're affected.

Implement Pre-Deployment Security Review for Extensions

Before installing any extension, run it through static analysis tools that detect common vulnerability patterns. At minimum, scan for: unsafe deserialization (unserialize() with user input), SQL injection patterns, file upload handling, and authentication bypasses. Tools like Psalm, PHPStan with security rules, or commercial SAST platforms can automate this.

Deploy a WAF with Deserialization Attack Signatures

Configure your web application firewall to inspect POST bodies for serialized PHP objects. ModSecurity with OWASP Core Rule Set includes rules for detecting PHP object injection. This won't prevent all deserialization attacks, but it raises the bar for exploitation.

Segment Your eCommerce Environment

Run your Magento application with a dedicated database user that has only the permissions it needs. Use separate OS users for the web server and any background jobs. When an RCE occurs, these boundaries limit what the attacker can access. This is basic defense in depth, but many eCommerce installations still run with excessive privileges.

Establish a 24-Hour Patch Window for Active Exploitation

Your vulnerability management policy probably allows 30 days for critical patches. Add an exception: when CISA adds a vulnerability to the KEV catalog, you patch within 24 hours or take the affected system offline. CVE-2026-45247 represents the scenario this exception addresses -- a trivial attack that requires no authentication and is actively exploited.

Test Your Incident Response Plan Against This Scenario

Use CVE-2026-45247 as a tabletop exercise. Walk through: How would your team detect this exploitation? Who approves emergency patching? How do you verify the patch worked? What forensics would you collect? If your answers involve phrases like "we'd probably..." or "I think someone would...", you have gaps to document.

The Mirasvit vulnerability demonstrates why third-party code requires the same rigor as your own development. Every extension is a potential RCE waiting for the right deserialization flaw. Your controls need to assume vendor code is hostile until proven otherwise.