Equifax, 2017: one missed patch, 76 days undetected.
A vulnerability alert went out in March 2017. The notice did not reach the person responsible for one portal, and a scan missed it. What the US Government Accountability Office and the FTC found, and the controls that address each gap.
Last updated Published by TryTrustableNot legal advice
Attackers exploited a known Apache Struts vulnerability (CVE-2017-5638) in Equifax's online dispute portal, which had not been patched after a March 2017 US-CERT alert. From 13 May 2017 they ran about 9,000 database queries and removed personal data on about 147 million people, undetected for about 76 days because an expired certificate had stopped traffic inspection. In July 2019 Equifax agreed a settlement with the FTC, the CFPB and 50 states and territories of $575 million, potentially up to $700 million.
What happened
| Date | What happened |
|---|---|
| 8 March 2017 | US-CERT alerts Equifax to a critical vulnerability in Apache Struts (FTC complaint). |
| 9 March 2017 | Equifax circulates the alert by mass email to more than 400 employees, asking for a patch within 48 hours as its patch policy required (FTC complaint). |
| 10 March 2017 | Unidentified individuals scan Equifax systems for the vulnerability and find the online dispute portal running a vulnerable version; no data is taken at this point (GAO). |
| 15 March 2017 | An automated scan for vulnerable Struts instances does not find the portal (FTC complaint). |
| 13 May 2017 | Attackers gain access to the portal and begin querying other databases (GAO). |
| 29 July 2017 | After an expired certificate is replaced, security staff see suspicious traffic (GAO). |
| 30 July 2017 | The portal is taken offline (GAO). |
| 7 September 2017 | Equifax announces the incident publicly. |
| 22 July 2019 | Settlement with the FTC, CFPB and states is announced. |
Root cause
The Apache Struts vulnerability allowed remote command execution through a crafted HTTP header and was being exploited in the wild in March 2017. Equifax's own officials told the GAO that four factors led to the breach (GAO-18-559):
- Identification. The vulnerability was not identified as present on the dispute portal. The patch notice went to an out-of-date recipient list, so it did not reach the people responsible for the portal, and a scan a week later did not detect the vulnerability there.
- Detection. A tool that inspected network traffic could not do so because its digital certificate had expired about ten months before the breach. Encrypted traffic passed uninspected throughout the attack.
- Segmentation. Databases were not isolated from each other, so the attackers reached 48 unrelated databases beyond the portal's own.
- Data governance. The attackers found a database holding unencrypted usernames and passwords for other databases.
The GAO adds a fifth factor: no limit on the frequency of database queries, which let the attackers run about 9,000 queries. The FTC complaint makes the same points as allegations, including that the scanner "was not configured to correctly search all" potentially vulnerable assets.
Impact and regulatory outcome
- People affected: the FTC puts it at approximately 147 million people. The GAO, writing in August 2018, reported at least 145.5 million in the US and nearly 1 million outside it.
- Duration: about 76 days from first data access to discovery (GAO).
- Settlement: on 22 July 2019 Equifax agreed to pay $575 million, and potentially up to $700 million, in a global settlement with the Federal Trade Commission, the Consumer Financial Protection Bureau and 50 US states and territories.
The FTC's summary of the allegation is short: Equifax failed to patch its network after being alerted to a critical vulnerability, and did not follow up to make sure the patch order had been carried out.
The controls that address it
| Control | SOC 2 criteria | ISO 27001:2022 Annex A |
|---|---|---|
| Vulnerability management: know what software runs where, and patch to a deadline | CC7.1 | A.8.8 |
| Asset inventory that tells you who owns each system | CC6.1, CC7.1 | A.5.9 |
| Verification that patches were actually applied (rescan, coverage) | CC7.1, CC4.1 | A.8.8, A.8.29 |
| Monitoring that works, including certificate lifecycle for inspection tools | CC7.2 | A.8.16 |
| Network segregation between applications and data stores | CC6.1, CC6.6 | A.8.22 |
| Credentials not stored in plain text; secrets managed | CC6.1 | A.5.17, A.8.24 |
| Rate limits and anomaly detection on sensitive queries | CC7.2 | A.8.16 |
SOC 2 references are the 2017 Trust Services Criteria (points of focus revised 2022); Annex A references are ISO/IEC 27001:2022. These are the usual mappings: agree yours with your auditor.
How TryTrustable checks these controls
- Dependency vulnerabilities: the SDK runs in your CI on every push, reports known CVEs in your dependencies to vulnerability management, and the pre-push gate can stop a push that fails.
- Dependabot: the GitHub integration checks that Dependabot alerts are enabled on your repositories.
- Container images: on GCP, a check that Artifact Registry vulnerability scanning is on.
- Web security testing:
trytrustable dastruns Nuclei, which tests running applications against templated CVE checks, and OWASP ZAP. - Certificates you expose: attack surface monitoring discovers your subdomains from Certificate Transparency and flags expiring and expired public TLS certificates. (It sees public certificates, not the internal certificate of a traffic inspection appliance.)
- Secrets in code: the SDK's secret scan and the GitHub secret scanning check look for credentials committed to repositories.
These are the checks TryTrustable runs today. None of them is a claim about what would have happened in this incident: they test whether the control is in place in your environment, continuously, and record the result as audit evidence.
Sources
- FTC: Equifax to pay $575 million as part of settlement with FTC, CFPB and states (22 July 2019)
- FTC v. Equifax Inc., complaint (N.D. Ga., filed 22 July 2019)
- US GAO, GAO-18-559: Actions taken by Equifax and federal agencies in response to the 2017 breach
- NIST National Vulnerability Database: CVE-2017-5638
- Equifax: announcement of the cybersecurity incident (7 September 2017)
Every figure on this page is taken from the official documents listed here, read in October 2026. Regulatory findings quoted are the regulator's; where a company neither admitted nor denied them, or where proceedings are still open, the page says so. Not legal advice.
More case studies: all breach case studies · Research
The things people ask us
What vulnerability caused the Equifax breach?
A known vulnerability in the Apache Struts web framework (CVE-2017-5638) on Equifax's online dispute portal. US-CERT alerted Equifax in March 2017; the patch was not applied to that portal, and a later scan did not detect it.
How long were the attackers inside Equifax's network?
About 76 days, according to the GAO: from 13 May 2017 until suspicious traffic was noticed on 29 July 2017. An expired certificate on a traffic inspection tool meant encrypted traffic was not being inspected during that time.
How much did Equifax pay?
Equifax agreed in July 2019 to pay $575 million, potentially up to $700 million, in a settlement with the FTC, the CFPB and 50 US states and territories.
What does the Equifax breach teach about patching?
That a patch policy is only as good as the asset inventory behind it. The notice reached an out-of-date list, and the scan was not configured to cover all assets. Verifying that patches landed, system by system, is the control.
Check these controls in your own environment.
We connect GitHub and one cloud account in a demo and show which of these checks pass, with the evidence an auditor would ask for.