The Equifax Breach: An Unpatched Struts Bug and 147 Million Records

Every element of the Equifax breach was ordinary. A known vulnerability with a published patch. A scan that reported nothing. An expired certificate. A flat internal network. Credentials in a file. None of it required a sophisticated adversary, and the combination produced one of the largest disclosures of personal data on record.

That is why it remains the reference case for vulnerability management. The interesting question is not how the attackers got in, which took one HTTP request against an unpatched server. It is how a single web application reached 51 databases, and how 76 days of data leaving the network went unnoticed.

Facts here come from the US Government Accountability Office report, the House Oversight majority staff report, Equifax's own disclosures and the FTC settlement. Figures are as those sources stated them.

Timeline

Date	Event
7 March 2017	Apache discloses CVE-2017-5638 in Struts 2 and publishes a fix
8 March 2017	US-CERT notifies Equifax, among others, about the vulnerability
9 March 2017	Equifax circulates an internal notice to apply the patch
15 March 2017	Equifax runs scans intended to find affected systems. The dispute portal is not identified
13 May 2017	First unauthorised access, per Equifax's investigation
13 May to 30 July 2017	Access continues. Roughly 9,000 queries against 51 databases
29 July 2017	An expired certificate on the traffic inspection device is replaced. Suspicious traffic is identified the same day
30 July 2017	The portal is taken offline
7 September 2017	Public disclosure, initially about 143 million US consumers
July 2019	Settlement with the FTC, CFPB and states: at least 575 million dollars, up to 700 million

The two dates that matter most sit 67 days apart: the patch was available on 7 March, and the first intrusion was on 13 May.

The vulnerability

CVE-2017-5638 is a remote code execution flaw in the Jakarta Multipart parser in Apache Struts 2. A crafted Content-Type header on a file upload request caused the value to be evaluated as an expression, which meant an attacker could run commands on the server by sending one HTTP request. No authentication was required.

Its severity was not in doubt at the time. It was disclosed with a patch, exploitation began within days, and it was widely flagged by vendors and by US-CERT. This is a textbook case for Vulnerability Management Lifecycle: a critical, internet-reachable, actively exploited flaw with a fix available.

The vulnerable application was ACIS, a consumer dispute portal, reachable from the internet.

Why the patch never landed

Two failures compounded, and both are common.

The notice did not reach the owner. An internal alert instructed teams to patch Struts within a defined period. The list of recipients did not include the people responsible for the affected application. An instruction is not a control unless somebody can confirm it was executed on every affected asset.

The verification scan missed the asset. Scans were run on 15 March to find vulnerable systems and did not flag the dispute portal. The GAO report describes the scanning as insufficient to identify the affected system. This is the most transferable failure in the case: a scan that does not cover an asset returns nothing, and a report with no findings looks identical whether the estate is clean or the scan was blind. It is why asset inventory sits at the top of the lifecycle and why coverage is a metric.

From one web application to 51 databases

The initial access was one server. The scale came from what that server could reach.

No segmentation of consequence. The dispute portal sat where it could reach databases holding data unrelated to disputes. Attackers ran roughly 9,000 queries across 51 databases. In a segmented design, described in Network Segmentation Guide, a compromised public-facing portal reaches the small set of systems it needs and nothing else.

Credentials in the clear. Usernames and passwords were found stored unencrypted on a file share reachable from the compromised host, which supplied the access to those other databases. This is precisely the failure that vaulting and rotation exist to prevent, covered in Privileged Access Management Explained.

Web shells for persistence. Multiple web shells were placed on the server, giving durable command execution independent of the original exploit.

Data staged and removed in pieces. Extracted data was compressed and moved out in chunks small enough not to look unusual, which matters only because nothing was watching. Which brings us to the detection failure.

The expired certificate

Equifax decrypted and inspected outbound traffic to look for exactly this kind of activity. The device doing that inspection required a valid certificate. The certificate had expired and had not been renewed, so the traffic passed through uninspected.

The failure mode is worth dwelling on. The device did not stop working, did not raise an alarm, and did not report a degraded state that anybody acted on. It simply saw less. From the outside, a security control that has silently stopped inspecting looks exactly like a security control that is inspecting and finding nothing.

The proof is in the timing. When the certificate was replaced on 29 July, the monitoring came back, and the suspicious traffic was identified the same day. The capability to detect this intrusion existed for the whole 76 days. It was switched off by an expired certificate that nobody was tracking.

The general lesson goes beyond certificates: a security control needs monitoring that it is working, separate from the alerts it produces. A log source that goes quiet, a scanner that stops covering a subnet, an agent that stops reporting, and an inspection device with an expired certificate all fail the same way, which is invisibly and in the direction of less visibility. That is why What Is a SIEM argues that a detection for a source going silent is among the most valuable rules a team can write.

What changed afterwards

At Equifax. The chief executive, chief information officer and chief security officer departed. The company committed to substantial security investment as part of the settlement, including specified programme requirements.

In regulation and oversight. The GAO and congressional investigations produced detailed public accounts, which is why this incident can be studied precisely while others cannot. The FTC settlement in July 2019 involved at least 575 million dollars, rising to as much as 700 million, and included consumer redress.

In the wider industry. The case became the standard argument for treating exploited-in-the-wild vulnerabilities as a different category from merely severe ones. CISA's Known Exploited Vulnerabilities catalogue, created in 2021 and covered in KEV Catalog Explained, is a direct descendant of the reasoning: what mattered about CVE-2017-5638 was that it was being exploited, not its score.

What actually generalises

Four things, in order of how often they still appear in incident reports.

1. The patch existed and was not applied to a system nobody knew was affected. The fix for this is asset inventory rather than exhortation.
2. The verifying scan reported nothing because it did not cover the asset. Measure coverage, not just findings.
3. A detection control failed silently. Monitor the health of controls, not only their output.
4. The internal network let a public web application reach unrelated databases, and credentials on a share opened them.

Each of those is unremarkable on its own. That is the point of studying this breach: nothing exotic happened, and 147 million records left the building.

Related guides

• Vulnerability Management Lifecycle
• KEV Catalog Explained
• Network Segmentation Guide
• Privileged Access Management Explained
• What to Do After a Data Breach