56% of Vulnerable Magento Stores Hit Within 10 Days

What Happened

Mass exploitation of the PolyShell vulnerability in Magento Open Source and Adobe Commerce began on March 19th. Within days, attackers compromised 56.7% of all vulnerable stores. The attack exploited a critical flaw in Magento's REST API, allowing remote code execution and account takeover. Sansec identified the campaign, noting that attackers deployed a WebRTC-based payment card skimmer in compromised stores.

The exploitation occurred despite Adobe releasing a fix in version 2.4.9-beta1 on March 10, 2026. This patch never reached the stable branch before attackers launched their campaign.

Timeline

March 10, 2026: Adobe releases fix in beta version 2.4.9-beta1
March 10-18: Nine-day gap with patch available only in beta
March 19: Mass exploitation begins
March 19-29 (estimated): 56.7% of vulnerable stores compromised

The critical failure was the delay between beta release and stable branch deployment. Your patch management process must account for this gap. If you manage e-commerce infrastructure, do not wait for stable releases when a critical RCE vulnerability is active.

Which Controls Failed or Were Missing

Vulnerability Management Process

There is no evidence that operators ran vulnerability scans that would have flagged the REST API exposure. The REST API flaw was exploitable remotely without authentication. Basic API security testing would have identified unauthorized access attempts.

Patch Deployment Cadence

The nine-day window between beta patch and exploitation highlights a failure in risk-based patching. Organizations treating beta releases as "not production-ready" left themselves exposed to a known, critical vulnerability with available remediation.

API Security Controls

The REST API lacked:

• Rate limiting on authentication endpoints
• Input validation to prevent malicious payloads
• Monitoring for unusual API access patterns
• Network segmentation to restrict API access

Payment Data Protection

The WebRTC-based skimmer represents an evolution in data exfiltration. Traditional content security policies and script monitoring failed to detect this technique. WebRTC creates peer-to-peer connections that bypass conventional egress monitoring.

What the Relevant Standards Require

PCI DSS v4.0.1 Requirement 6.3.1

"Security vulnerabilities are identified and addressed as follows: New security vulnerabilities are identified using industry-recognized sources... A risk ranking is assigned to vulnerabilities that includes identification of all 'high' and 'critical' vulnerabilities."

A REST API remote code execution vulnerability is critical by any risk ranking. Your documented process must address how you handle patches released in beta when they remediate critical flaws. Waiting for stable releases is not defensible under PCI DSS v4.0.1.

PCI DSS v4.0.1 Requirement 6.3.2

"An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained."

If you cannot answer "are we running a vulnerable Magento version" within 15 minutes, your asset inventory fails this requirement. The speed of exploitation demands real-time awareness of your application stack.

PCI DSS v4.0.1 Requirement 6.4.3

"All payment page scripts that are loaded and executed in the consumer's browser are managed as follows: A method is implemented to confirm that each script is authorized."

The WebRTC skimmer bypassed traditional script authorization. Requirement 6.4.3 became mandatory on March 31, 2025. If you're running payment pages, you need script integrity monitoring that detects new communication channels, not just new script tags.

OWASP ASVS v4.0.3 Section 14.5.3

"Verify that the application monitors for unusual events or activity from a security perspective."

API endpoints processing payment data require monitoring for:

• Authentication attempts from new source IPs
• Bulk data access patterns
• API calls outside normal business hours
• Requests with malformed or unexpected parameters

ISO/IEC 27001:2022 Control 8.8

"Management of technical vulnerabilities: Information about technical vulnerabilities of information systems in use shall be obtained, the organization's exposure to such vulnerabilities shall be evaluated and appropriate measures shall be taken."

Your evaluation process must include: How quickly can we deploy a beta patch? What testing can we compress? What compensating controls can we implement in hours, not days?

Lessons and Action Items for Your Team

Immediate Actions (Next 48 Hours)

1. Verify your Magento version: Run bin/magento --version on every instance. Document every store that hasn't applied the patch. If you don't know your version numbers right now, fix your asset inventory before you do anything else.

2. Deploy the patch: Even if it's beta. A beta patch for a critical RCE vulnerability is more stable than an exploited production system. Your change control process needs an emergency path for this scenario.

3. Check for compromise indicators: Review API access logs from March 19 forward. Look for:

   • POST requests to /rest/V1/ endpoints from unfamiliar IPs
   • Account creation or privilege escalation events
   • New JavaScript files in your checkout pages
   • Outbound WebRTC connections from payment pages

4. Implement API rate limiting: If you haven't already, add rate limiting to authentication endpoints. Start with 10 requests per minute per IP. Adjust based on your legitimate traffic patterns.

Process Changes (Next 30 Days)

1. Revise your patch management policy: Add criteria for deploying beta or pre-release patches. The trigger: any vulnerability with a CVSS score above 8.0 affecting payment processing or authentication. Your policy should specify compressed testing procedures for emergency patches.

2. Add WebRTC to your monitoring: Update your content security policy and monitoring tools to alert on WebRTC connections from payment pages. Block RTCPeerConnection API calls unless you explicitly use WebRTC for legitimate purposes.

3. Test your vulnerability identification process: Can you identify when a critical vulnerability affects your stack within 24 hours of disclosure? If not, you need automated CVE monitoring tied to your asset inventory.

4. Document your API attack surface: Map every API endpoint that touches payment data or authentication. For each endpoint, document: authentication requirements, rate limits, input validation rules, and monitoring coverage.

Architecture Changes (Next 90 Days)

1. Segment your API infrastructure: Payment APIs should run on isolated network segments with restricted egress. A compromised API should not have direct internet access for data exfiltration.

2. Implement runtime application self-protection (RASP): For payment processing applications, consider RASP tools that can detect and block exploitation attempts in real-time, even for zero-day vulnerabilities.

3. Deploy script integrity monitoring: Move beyond static script allowlists. You need runtime monitoring that detects when authorized scripts establish new communication channels or access unexpected APIs.

The PolyShell exploitation demonstrates that the window between patch availability and mass exploitation is shrinking. Your response time must shrink faster.