What Happened
On July 2, 2019, Snyk published CVE-2019-10744, a prototype pollution vulnerability affecting every version of lodash. This library, used by 4.35 million projects on GitHub and downloaded over 80 million times monthly, had a critical flaw allowing attackers to inject properties into JavaScript object prototypes. The lodash maintainer released version 4.17.12 with a fix, and Snyk opened thousands of automated pull requests to patch affected repositories.
The vulnerability existed in lodash methods that merged or zipped objects without proper validation. An attacker controlling input to these methods could modify Object.prototype, affecting every object in the application's runtime.
Timeline
Pre-July 2, 2019: All lodash versions contained the vulnerability, leaving millions of applications exposed.
July 2, 2019: Snyk disclosed CVE-2019-10744 publicly after coordinating with the lodash maintainer. Version 4.17.12 shipped with the fix.
Post-disclosure: Snyk initiated automated remediation, opening fix pull requests across its user base. The race began: would organizations patch faster than attackers could exploit the CVE?
Which Controls Failed or Were Missing
No dependency vulnerability scanning in CI/CD. Most affected projects lacked an automated mechanism to detect the vulnerable lodash version. Your pipeline built and deployed code with a known CVE because nothing checked.
Missing Software Composition Analysis (SCA). Organizations tracked their first-party code but ignored dependencies. You can't patch what you don't inventory.
No automated patching workflow. Even after Snyk published the fix, most teams relied on manual updates. Your security team knew about the CVE, but your 47 microservices still ran lodash 4.17.11 three months later because nobody owned the update process.
Inadequate input validation. The vulnerability exploited methods that accepted untrusted input without sanitization. Your application let user-controlled data flow into merge operations because you trusted the library to handle edge cases.
No runtime application self-protection (RASP). Applications had no visibility into prototype pollution attempts at runtime. An attacker could probe for the vulnerability without triggering alerts.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates identifying security vulnerabilities using reputable sources and assigning a risk ranking to newly discovered vulnerabilities. Lodash appeared in your dependency tree, but you had no process to match it against CVE feeds.
Requirement 6.4.3 requires automated mechanisms to prevent or detect web-based attacks. Prototype pollution enables injection attacks that violate this control. You needed input validation at the application boundary, not just inside lodash.
OWASP Top 10 2021: A06:2021 – Vulnerable and Outdated Components directly addresses this failure. The standard notes that you're vulnerable if you don't know the versions of all components you use, if the software is unsupported or out of date, or if you don't fix or upgrade the underlying platform in a risk-based, timely fashion.
NIST 800-53 Rev 5 Control SI-2 (Flaw Remediation) requires installing security-relevant software updates within organization-defined time periods. "Eventually" isn't a time period. Neither is "when we have a maintenance window."
ISO/IEC 27001:2022 Annex A.8.8 (Management of Technical Vulnerabilities) requires timely information about technical vulnerabilities, evaluation of exposure, and appropriate measures to address the risk. Your ISMS documentation claimed you had this process. The lodash incident proved you didn't.
Lessons and Action Items for Your Team
Implement SCA in every pipeline. Add a tool that fails builds when dependencies have known CVEs above your risk threshold. Set that threshold at CVSS 7.0 or higher for production code. Run it on every pull request, not just weekly scans.
Create a dependency update policy with SLAs. Critical vulnerabilities (CVSS 9.0+) in production: 7 days. High (7.0-8.9): 30 days. Document who approves exceptions and under what circumstances. A library with 80 million monthly downloads and 4.35 million dependent projects demands automation, not committee meetings.
Enable automated dependency updates. Tools like Dependabot, Renovate, or Snyk can open pull requests when patches ship. Your team reviews and merges them — the tool handles detection and proposal. Snyk opened thousands of fix PRs after lodash 4.17.12 released. If you weren't a Snyk user, you found out about the CVE from a penetration test six months later.
Inventory your dependencies. Generate a Software Bill of Materials (SBOM) for every application. You can't patch lodash if you don't know which services use it. Export the SBOM in CycloneDX or SPDX format and store it in your asset inventory.
Validate input at application boundaries. Don't assume libraries handle malicious input safely. If your API accepts JSON that flows into object merge operations, validate the structure and reject unexpected properties. Prototype pollution exploits trust in data shape.
Monitor for prototype pollution at runtime. Add checks that detect modifications to Object.prototype or other built-in prototypes. Log and alert when these occur outside application startup. Consider this a critical security event, not a code smell.
Test your patching speed. Measure time-to-patch for the last three critical CVEs in your dependencies. If the answer is "we don't track that," start now. Your incident response plan should include dependency vulnerabilities, not just infrastructure breaches.
The lodash vulnerability wasn't sophisticated. It was ubiquitous. Your exposure wasn't technical complexity — it was operational blindness. You can't patch what you don't see, and you can't see what you don't inventory. Fix the visibility problem first. The rest follows.
