What Happened
Adobe released a security patch for Magento in February 2022 to address CVE-2022-24086, a critical vulnerability allowing SQL injection or PHP object injection during checkout for unauthenticated users. The patch was insufficient, leading Adobe to issue a second patch (MDVA-43443), which introduced a new sanitization function called sanitizeValue() to properly mitigate the vulnerability, now tracked as CVE-2022-24087. Your ecommerce platform was vulnerable twice: once from the original flaw, and again from the incomplete fix.
Timeline
February 2022: Adobe issues initial patch for CVE-2022-24086
- Vulnerability: SQL injection and PHP object injection at checkout
- Attack vector: Unauthenticated users could exploit the flaw
- Impact: Full database compromise, arbitrary code execution
[Date not specified]: Security researchers identify bypass in the original patch
- The initial remediation failed to comprehensively sanitize user input
- New CVE assigned: CVE-2022-24087
Follow-up patch: Adobe releases MDVA-43443
- Introduces
sanitizeValue()framework function - Provides reusable sanitization across the codebase
- Addresses gaps in original patch
Which Controls Failed or Were Missing
1. Inadequate Input Validation
The original vulnerability existed because Magento failed to sanitize user-supplied data during the checkout process. This is a fundamental application security control that should have been integrated into the framework from the start.
2. Incomplete Patch Validation
Adobe's internal testing didn't catch that the first patch left exploitable code paths. Your patch management process needs to include verification that the fix actually closes the attack vector, not just that it compiles and deploys.
3. Lack of Defense-in-Depth
A properly architected system would have prevented unauthenticated users from triggering database operations that could lead to injection attacks. The checkout flow should have included multiple layers of validation and access controls.
4. Insufficient Code Review of Security Patches
The need for a second patch suggests the initial fix wasn't subjected to rigorous security-focused code review. Patches for critical vulnerabilities deserve the same scrutiny as the original vulnerability.
What the Relevant Standard Requires
PCI DSS v4.0.1 Requirement 6.2.4 mandates addressing common coding vulnerabilities in software development processes. SQL injection is a known, preventable vulnerability class.
Specifically, Requirement 6.2.4 states that software engineering techniques include input validation. The sanitizeValue() function that Adobe eventually introduced is exactly the type of reusable security control this requirement demands. You should have this framework in place before deployment, not after a public CVE.
PCI DSS v4.0.1 Requirement 6.3.2 requires that security patches are installed within one month of release for systems in the cardholder data environment. If you installed the first patch within 30 days, you were still vulnerable. If you waited to see if the patch was stable, you violated the requirement.
OWASP ASVS v4.0.3 Section 5.3.4 requires that data from untrusted sources is sanitized, validated, or escaped before being used in SQL queries. The original Magento code failed this requirement. The first patch failed it. Only the second patch with sanitizeValue() met the standard.
ISO 27001 Annex A.8.8 (Management of technical vulnerabilities) requires you to obtain timely information about technical vulnerabilities and evaluate exposure. When Adobe released the first patch, your team should have tested it against the original attack vector. The fact that a second CVE was issued means either Adobe didn't do this, or you didn't verify their work.
Lessons and Action Items for Your Team
Action 1: Test Patches Against the Original Exploit
Don't just deploy patches and assume they work. If you're running Magento or any ecommerce platform:
- Set up a staging environment that mirrors production
- Obtain or develop proof-of-concept code for the vulnerability
- Verify the patch actually blocks the attack
- Document what you tested and what you found
For CVE-2022-24086, you should have tested SQL injection payloads at the checkout endpoint before and after patching.
Action 2: Implement Defense-in-Depth for Checkout Flows
Your checkout process should include:
- Parameterized queries or ORM frameworks that prevent SQL injection by design
- Web Application Firewall (WAF) rules that block common injection patterns
- Rate limiting on checkout endpoints to slow down automated exploitation
- Monitoring for unusual database queries originating from web requests
These measures would have made exploitation harder and given you visibility into attack attempts.
Action 3: Build a Patch Validation Pipeline
Create a documented process for security patch deployment:
- Review the CVE and vendor advisory
- Identify affected systems in your environment
- Deploy to staging within 48 hours
- Run automated security tests (DAST, SAST if source is available)
- Manually test the specific vulnerability if possible
- Monitor staging for 72 hours
- Deploy to production within the compliance window
- Verify production deployment with the same tests
This pipeline would have caught the incomplete Magento patch before it hit production.
Action 4: Monitor for Follow-Up CVEs
When a vendor issues a security patch, watch for additional CVEs in the same component. The pattern of CVE-2022-24086 followed by CVE-2022-24087 is common: the first fix is incomplete, the second one is comprehensive.
Set up alerts for:
- New CVEs affecting recently patched software
- Vendor security bulletins for products you've patched in the last 90 days
- Security mailing lists discussing bypass techniques for recent patches
Action 5: Adopt Reusable Sanitization Frameworks
The sanitizeValue() function Adobe eventually introduced should have existed from day one. In your own code:
- Build or adopt a centralized input validation library
- Make it mandatory for all user input processing
- Include it in code review checklists
- Run static analysis to flag direct database queries that bypass the framework
If you're using third-party platforms like Magento, audit whether they provide these frameworks and whether your custom extensions use them.
The Bottom Line: An incomplete patch is sometimes worse than no patch at all. It gives you false confidence while leaving you exposed. Your patch management process needs to verify that fixes actually work, not just that they deploy cleanly.
