Equifax, Log4Shell, and MOVEit Transfer: real incidents where the CVE was public, the patch existed, and the tools in place still missed it. Here is exactly why.
The most uncomfortable pattern in major security breaches is not that the vulnerabilities were unknown. It is that the CVEs were public, patches were available, and the monitoring systems in place had specific, documentable blind spots that let them through. Equifax in 2017. Log4Shell in 2021. MOVEit Transfer in 2023. Different years, different CVEs, different attack methods. the same underlying detection gap. Here is what each one actually looked like from the inside.
On March 8, 2017, the National Vulnerability Database published CVE-2017-5638: a critical unauthenticated remote code execution vulnerability in Apache Struts 2, specifically in the Content-Type header parsing in the Jakarta Multipart parser. The CVSS score was 10.0. A patch was available on the same day.
Equifax was running Apache Struts on their ACIS online dispute portal. a consumer-facing web application processing financial data for hundreds of millions of Americans. They had commercial vulnerability scanning tools in place.
The breach began May 13, 2017. 66 days after CVE publication. Attackers maintained access undetected for 78 additional days until July 29. By then, names, Social Security numbers, birth dates, addresses, and credit card numbers for 147.9 million people had been exfiltrated.
The US Government Accountability Office published a post-breach report in 2018. Its finding on the scanner: the signature database for the specific scanner covering the ACIS portal had not been updated. The scanner was running stale signatures and did not have a detection rule for CVE-2017-5638.
Second failure: Equifax had an SSL traffic inspection tool that should have provided a secondary detection layer. That tool had an expired certificate and had been non-functional for 19 months. It was renewed on July 29, 2017. the same day the breach was discovered, entirely by coincidence.
Third failure: the Apache Struts vulnerability notification had been sent to a generic security team email address. The process for triaging and assigning critical CVEs required manual review. The responsible engineer for the ACIS portal was not notified.
Total cost: $1.38 billion in settlements with the FTC, CFPB, and all 50 state attorneys general. Equifax's CEO, CIO, and CSO all resigned within months of the disclosure.
On December 9, 2021 at approximately 08:20 PST, the National Vulnerability Database published CVE-2021-44228: a critical remote code execution vulnerability in Apache Log4j 2, the most widely deployed Java logging library in the world. CVSS score: 10.0. Severity: the highest possible. Apache released version 2.15.0 as a patch that same day.
The first public exploit code appeared approximately 9 hours later. Within 72 hours, over 840,000 exploitation attempts had been observed by security researchers. CISA Director Jen Easterly called it 'the most serious vulnerability I have seen in my decades-long career.'
Here is the detection problem: Log4j was rarely a direct dependency. It was a transitive dependency. a dependency of your dependencies.
Elasticsearch bundled Log4j. Apache Solr bundled Log4j. VMware vCenter used Log4j. Cisco's unified communications products used Log4j. Apple's iCloud backend used Log4j. Amazon's AWS services used Log4j. Cloudflare used Log4j. IBM, Oracle, and SAP all had Log4j in production systems.
None of these organizations' package.json, pom.xml, or requirements.txt files listed Log4j as a direct dependency. SCA tools that scanned manifest files found no Log4j. Dependabot. which monitors your declared dependencies and creates pull requests when they have known CVEs. found no Log4j. GitHub's security advisory system, scoped to code repositories and their manifests, found no Log4j.
The only way to find it was to inspect the lock file: the fully resolved dependency graph that records what is actually installed, including everything your dependencies depend on. Maven's effective POM, Gradle's lock file, npm's package-lock.json. the resolved artifact list, not the declared manifest.
A Tenable research report published in January 2022 found that 72% of organizations were still unpatched or partially patched two weeks after disclosure. The attack window for those organizations was measured in days, not months.
On May 27, 2023, the Cl0p ransomware group began exploiting an undisclosed SQL injection vulnerability in Progress Software's MOVEit Transfer managed file transfer application. The CVE. CVE-2023-34362. was published four days later on May 31. CISA added it to the Known Exploited Vulnerabilities catalog on June 1, 2023.
By the end of 2023, over 2,620 organizations had confirmed breaches via the MOVEit vulnerability. Over 77.2 million individuals were affected. The victims include British Airways, BBC, Boots (the UK pharmacy chain), Shell, Boeing, the US Department of Energy, Oak Ridge National Laboratory, Johns Hopkins University, the Virginia Department of Elections, Sony Pictures, PricewaterhouseCoopers, Ernst and Young, Deloitte, TIAA, and the US Government Services Administration.
The reason none of these organizations detected the exposure through their existing security tooling is specific: MOVEit Transfer is not a code dependency. It is not in any repository. It does not appear in any package.json, requirements.txt, pom.xml, Cargo.toml, or go.mod file. It is enterprise infrastructure. a managed file transfer application that runs as a Windows service.
Every code-based SCA tool. Snyk, Veracode, Black Duck, Checkmarx, GitHub Dependabot, OWASP Dependency-Check. had zero visibility into MOVEit Transfer by architectural design. These tools scan code repositories and their dependency manifests. They do not know which enterprise applications are installed on your production infrastructure.
Organizations with CVSS-threshold-based alerting systems did receive the alert when CVE-2023-34362 was published. it is a CVSS 9.8. But they would only have received it if MOVEit Transfer was already in their monitored software inventory. For most organizations, it was not. Adding it required someone to know it should be there and add it manually. That is a process that requires advance knowledge of your own attack surface.
The organizations that discovered the breach proactively. before Cl0p's extortion notices arrived. had infrastructure CVE monitoring that tracked their installed applications across their production environment, not just the packages in their code repositories.
The three incidents expose distinct failure modes, but they share a common architecture:
Equifax: the detection system's knowledge base was out of date. The CVE existed in the NVD but not in the scanner's signature database. The patch window was 66 days. not because patching took 66 days, but because awareness took 66 days.
Log4Shell: the detection system was looking in the wrong place. Manifest files showed no Log4j. The tool was correct about what it saw. What it saw was incomplete. the transitive dependency graph that reflected what was actually installed was not being inspected.
MOVEit: the detection system was the wrong type of system. Code SCA tools are correct, complete, and irrelevant to enterprise infrastructure CVEs. The attack surface they miss is substantial.
All three scenarios share one common characteristic: the information needed to detect the exposure was publicly available before the breach began. CVE-2017-5638 was in the NVD on March 8. CVE-2021-44228 was in the NVD on December 9. CVE-2023-34362. while exploited before publication. was in the CISA KEV catalog on June 1.
The detection gap is not an intelligence gap. It is a monitoring architecture gap.
Closing all three gaps requires three distinct capabilities that most tools implement only one or two of:
Continuous CVE matching. not scheduled scans. A scanner that runs weekly would have found CVE-2021-44228 on December 12, 72 hours after the first exploitation wave. The alert needs to arrive within minutes of NVD publication, before the attack window closes.
Lock file parsing for dependency monitoring. Not manifest parsing. The difference is whether you see your declared dependencies or your installed dependencies. For transitive exposure (Log4Shell, and any transitive dependency CVE), only the installed list matters.
Infrastructure software tracking. Not code repository monitoring. The software running in your production environment includes applications that no code repository will ever list. MOVEit Transfer, nginx, PostgreSQL, OpenSSL. the CVE histories of these applications are as relevant to your security posture as any library in your package.json.
None of these capabilities is exotic. They are engineering choices about what to monitor and how frequently.
Takeaway
The three incidents covered here were preventable. not because the vulnerabilities were predictable, but because the detection gap that allowed them to persist was documentable before the breach began. Each one was a monitoring architecture problem masquerading as a security failure. The CVEs were public. The patches existed. The tooling was pointed at the wrong data. Understanding the specific failure mode. stale signature database, manifest-only scanning, code-only scope. is the prerequisite for fixing it.