What Happened
CVE-2026-71362 allows attackers to hijack customer accounts on Adobe Commerce and Magento platforms without authentication. Adobe released patches for this vulnerability along with fixes for six other issues, four of which are high-severity. Although Adobe's advisory stated no known exploits existed, Sansec reported their Shield WAF was already blocking active exploitation attempts.
Timeline
Here's what we know about the incident:
- Patch release: Adobe published security updates addressing CVE-2026-71362 and six other vulnerabilities.
- Detection begins: Sansec's WAF starts logging exploitation attempts.
- Public disclosure: Adobe issues an advisory claiming no known exploits; Sansec contradicts this with blocking data.
The gap between "no known exploits" and "we're blocking attempts" is significant. It suggests exploitation started before most teams could apply patches.
Which Controls Failed or Were Missing
Patch application speed. The period between patch availability and deployment is when you're most vulnerable. If your e-commerce platform operates on a monthly patch cycle, you're giving attackers weeks to exploit the vulnerability.
Pre-authentication input validation. CVE-2026-71362 works without credentials, meaning the application processed untrusted input before verifying the sender. Your authentication layer should reject malformed requests before they reach business logic.
WAF deployment. Organizations without a properly configured WAF had no early warning system. Sansec's customers received telemetry showing exploitation attempts; others were unaware.
Isolated patch process. Adobe released isolated patch files, but many teams struggle to apply these quickly. If your deployment pipeline only handles full version upgrades, you can't respond to critical fixes without significant engineering work.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.3 mandates deploying critical security patches within 30 days of release. For e-commerce platforms handling cardholder data, that's your compliance ceiling, not your operational target. A vulnerability bypassing authentication should trigger your emergency patch process.
Requirement 6.4.2 requires maintaining an inventory of bespoke and custom software to facilitate patching. If you've customized your Adobe Commerce installation, know exactly what you've changed to test patches without breaking functionality.
OWASP ASVS v4.0.3, Section 4.1 covers access control architecture. Specifically, 4.1.1 requires enforcing access control at a trusted service layer. The application should validate authentication before processing any business logic. CVE-2026-71362 represents a failure of this principle.
NIST CSF v2.0, PR.IP-12 addresses vulnerability response: "A vulnerability management plan is developed and implemented." Your plan needs to distinguish between routine patches and critical authentication bypasses. The response timeline should scale with severity.
Lessons and Action Items for Your Team
Build a sub-30-day patch pipeline for critical fixes. Don't wait for your monthly deployment window. Set up a separate process for security patches that can run in days, not weeks. Test in staging, deploy to production, and verify the fix.
Configure your WAF to block, not just alert. If you're running a WAF in detection-only mode, you're collecting data but not stopping attacks. Switch to blocking mode for known attack patterns, especially for pre-authentication endpoints. You might block legitimate traffic initially; tune your rules based on false positives, but start from a blocking posture.
Map your authentication boundaries. Identify every endpoint that processes input before checking credentials. These are your highest-risk surfaces. Apply extra scrutiny to input validation here. Consider rate limiting, input length restrictions, and schema validation before authentication occurs.
Test your isolated patch process now. Don't wait for the next CVE. Download Adobe's isolated patch files and run through your application process with a non-critical fix. Time how long it takes. Document the blockers. Fix the process before you need it under pressure.
Separate patch testing from feature testing. Security patches need faster validation than feature releases. Build a focused test suite that verifies core authentication, checkout, and payment flows. You're not testing whether the shopping cart works perfectly; you're testing whether the patch broke anything critical.
Monitor for exploitation attempts, not just successful breaches. If your logging only captures successful account takeovers, you're missing the reconnaissance phase. Log failed authentication attempts, malformed requests to auth endpoints, and unusual parameter patterns. Sansec knew about exploitation attempts because they were watching for them.
Question vendor advisories. Adobe said no known exploits; Sansec was blocking attempts. When a vendor claims no active exploitation, verify it independently. Check your own logs, talk to your WAF provider, and monitor security forums. "No known exploits" might mean "we haven't looked yet."
Document your customizations. If you've modified Adobe Commerce, you need a clear record of what changed. Create a diff between your codebase and the stock installation. Tag custom code in your repository. When patches arrive, you'll know immediately whether they conflict with your changes.
The gap between patch availability and deployment is where incidents happen. CVE-2026-71362 shows that gap can be measured in days, not weeks. Your patch process needs to match that timeline.
