Skip to main content
6,000 Stores, One Cookie: The Mirasvit RCE BreakdownIncident
5 min readFor Security Engineers

6,000 Stores, One Cookie: The Mirasvit RCE Breakdown

What Happened

An unauthenticated attacker can execute arbitrary PHP code on Magento stores running the Mirasvit Cache Warmer extension by sending a malicious cookie. CVE-2026-45247, a PHP object injection vulnerability with a CVSS score of 9.8, allows remote code execution without any authentication. CISA added this vulnerability to its Known Exploited Vulnerabilities catalog after confirming active exploitation. Approximately 6,000 stores run Mirasvit extensions, making the attack surface substantial.

The vulnerability exists in how the extension deserializes PHP objects from user-controlled input. An attacker crafts a cookie containing a serialized PHP object with a magic method that triggers code execution during the deserialization process. No login required. No user interaction needed. Just a cookie.

Timeline

May 25, 2026: Mirasvit releases patches for CVE-2026-45247.

CISA KEV Addition: CISA confirms active exploitation and adds the vulnerability to the Known Exploited Vulnerabilities catalog, triggering mandatory patching requirements for federal agencies within 21 days.

Current Status: Sansec's analysis confirms ongoing exploitation attempts targeting unpatched Magento installations.

The gap between patch availability and exploitation discovery remains unclear, but the CISA KEV listing indicates attackers moved quickly.

Which Controls Failed or Were Missing

Input Validation: The extension accepted and deserialized untrusted data from cookies without validation. This violates the principle that all user input is hostile until proven otherwise.

Secure Deserialization Practices: PHP's unserialize() function executed on attacker-controlled data. The extension should have used safer alternatives like JSON encoding or implemented object whitelisting before deserialization.

Dependency Security Monitoring: Organizations running this extension lacked processes to identify when third-party code introduced critical vulnerabilities. The 6,000 affected stores suggest many teams don't maintain an accurate inventory of their Magento extensions or monitor vendor security advisories.

Patch Deployment Velocity: The time between patch release (May 25) and CISA's KEV addition indicates many organizations failed to deploy available fixes before exploitation began.

Web Application Firewall Rules: Properly configured WAFs should detect unusual cookie patterns or suspicious deserialization attempts. The successful exploitation suggests either absent WAFs or insufficient ruleset coverage.

What the Relevant Standard Requires

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 defined in the entity's targeted risk analysis." For payment processing environments, a CVSS 9.8 vulnerability demands immediate action. Your targeted risk analysis should classify any unauthenticated RCE as critical, requiring patching within days, not weeks.

PCI DSS v4.0.1 Requirement 6.3.3: "An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained." If you don't know you're running Mirasvit Cache Warmer, you can't patch it. This requirement exists precisely for scenarios like this one.

OWASP Top 10 2021 - A08:2021 Software and Data Integrity Failures: Deserialization of untrusted data sits squarely in this category. Your code review process should flag any use of unserialize() on user input. If you're accepting third-party Magento extensions, you need a security review process that catches these patterns before deployment.

OWASP ASVS v4.0.3 Section 5.5.3: "Verify that deserialization of untrusted data is avoided or is protected in both custom code and third-party libraries." Level 2 applications (which should include any e-commerce platform) must implement controls around deserialization. Accepting a cookie and passing it directly to unserialize() fails this verification.

NIST 800-53 Rev 5 SI-2: "Organizations identify system vulnerabilities and take corrective action within organization-defined time frames." For federal agencies, CISA's KEV listing sets that timeframe at 21 days maximum. Your organization should define similar SLAs based on CVSS scores and exploit availability.

Lessons and Action Items for Your Team

Build an Extension Inventory Today: Create a spreadsheet of every Magento extension, WordPress plugin, or third-party library in your production environment. Include version numbers, vendor names, and who approved each addition. Update it whenever you deploy changes. This isn't optional for PCI DSS compliance, and this incident shows why.

Subscribe to Vendor Security Advisories: For every extension in your inventory, find the vendor's security notification mechanism. For Mirasvit, that means monitoring their security page and release notes. Add these feeds to a central monitoring system that your security team reviews daily.

Implement CISA KEV Monitoring: Even if you're not a federal agency, CISA's KEV catalog provides high-signal vulnerability intelligence. When CISA adds a vulnerability, it means active exploitation is confirmed. Set up automated alerts for new KEV additions and cross-reference them against your asset inventory within 24 hours.

Audit PHP Deserialization Patterns: Search your codebase and third-party extensions for unserialize() calls. Any instance that processes user input (cookies, POST data, headers) requires immediate review. Replace with JSON decoding where possible, or implement strict object whitelisting using allowed_classes parameter.

Define Patch SLAs by CVSS Score: A CVSS 9.8 vulnerability with public exploits should trigger emergency patching within 72 hours. Document these SLAs in your vulnerability management policy. When patches drop on a Friday (as they did here on May 25), your team needs clear authority to deploy over the weekend for critical issues.

Test Your WAF Detection: If you run a WAF in front of your Magento installation, test whether it would detect this attack. Send test requests with serialized PHP objects in cookies to a staging environment. If your WAF doesn't alert, update your rulesets to catch deserialization attempts.

Require Security Reviews for Extensions: Before deploying any third-party Magento extension, run it through static analysis tools that flag dangerous PHP patterns. At minimum, grep for unserialize(), eval(), and assert(). Better yet, require vendors to provide security assessment documentation before you'll consider their products.

The Mirasvit incident proves that your third-party code is your code from a security perspective. The attacker doesn't care whether you wrote the vulnerable extension or bought it from a vendor. Your customers' data gets compromised either way, and your compliance obligations remain the same.

Topics:Incident

You Might Also Like