patch&proof.
The briefing ↗
THE INDEPENDENT SECURITY RESEARCH JOURNAL
← Incident desk

Incident / 0006-bf-012 / historical case file

Equifax left a known web-framework flaw unpatched for months

A federal audit and an FTC settlement trace the 2017 breach to a missed patch notice and an expired certificate.

Historical analysis. Event dates and source publication dates are recorded with the evidence.
corporate-location photograph used as historical context, not as evidence of breach activity. Case context: Greenlight ↗Contextual image · source credit retained
The defensive takeaway

Confirm your patch process tracks acknowledgement to the individual system owner rather than a mass notice, and check whether any device inspecting encrypted traffic for threats has a certificate that is expiring or already expired.

What happened

On 7 September 2017, Equifax disclosed that attackers had accessed personal data belonging to an estimated 143 million US consumers, a figure later revised upward. According to the company's own disclosure filed with the Securities and Exchange Commission, the intrusion ran from mid-May through 29 July 2017 and exposed names, Social Security numbers, birth dates, addresses and, for some consumers, driver's licence numbers and credit card details. A review by the Government Accountability Office traces the root cause to Apache Struts, a web-application framework: a critical flaw in it was disclosed and patched in March 2017, roughly two months before attackers began extracting data through Equifax's online dispute portal, which still ran the vulnerable version.

The GAO review and the Federal Trade Commission's subsequent settlement both describe how the failure persisted: an internal notice about the flaw did not reach the employee responsible for the dispute portal, and a follow-up vulnerability scan was not configured to find the affected system. A second, separate failure then delayed detection for months: an expired network-monitoring certificate meant Equifax could not inspect encrypted traffic on the affected server, so the certificate had to be replaced before unusual activity became visible.

Confidence and limits

These details come from a congressionally requested audit that reviewed Equifax's own investigation and interviewed federal customer agencies, and from a federal enforcement settlement, so the patch failure and certificate lapse are well corroborated. Neither document independently re-verified Equifax's internal logs; both state they relied on the company's own reconstruction. The final consumer count, revised twice, should be read as Equifax's best estimate from incomplete records rather than an exact figure.

Why it mattered

Equifax held identity data on most of the US adult population without those people choosing to be its customer, a poor fit for the usual advice to change a password. The case became a reference point for patch management because the failure was not a missing fix, one existed within days of disclosure, but a gap between a security team's notice and the owner responsible for applying it. The settlement's board-oversight requirement shaped how regulators since have framed adequate data-security governance.

Defensive takeaway

Confirm that your patch process tracks acknowledgement down to the individual system owner rather than a mass notice, and check whether any device inspecting your encrypted traffic for threats has a certificate that is due to expire or has already lapsed.

  • Do you have a current, verified inventory of every public-facing system running a specific open-source framework, so a critical advisory can be matched to an owner within hours?
  • Would a critical-patch notice sent to a distribution list definitely reach the specific engineer responsible for the affected system?
  • Are any of your network-security appliances relying on a certificate that has expired or is close to expiring?

The Equifax breach is often remembered for its scale, but the more transferable lesson is procedural: a known vulnerability with an available patch sat exposed for months because two ordinary failures, a missed notification and a misconfigured scan, went unnoticed until an expired certificate was replaced in the course of routine maintenance.

Evidence ledger

Open the source. Check the claim.

A congressional audit and a federal enforcement settlement corroborate the patch-notification failure and the certificate lapse; both rely on Equifax's own forensic reconstruction rather than independent verification of internal logs, and the final consumer count was revised more than once.

Incident / event
7 September 2017 event
Lead source published
2017-09-07
Data Protection: Actions Taken by Equifax and Federal Agencies in Response to the 2017 Breach (GAO-18-559)2018-08-30 · government-primary
Traces the breach to the unpatched Apache Struts vulnerability, the missed internal patch notice, the misconfigured scan, and the expired certificate that delayed detection.
↗
Equifax to Pay $575 Million as Part of Settlement with FTC, CFPB, and States Related to 2017 Data Breach2019-07-22 · court-or-regulator-primary
Confirms the settlement amount, the approximately 147 million affected consumers, and the required security governance reforms.
↗
Equifax Announces Cybersecurity Incident Involving Consumer Information2017-09-07 · company-primary
Equifax's own initial disclosure of the discovery date, the window of unauthorized access, and the types of data exposed.
↗
Search the evidence
Source image / inspection view

View original source ↗Source credits and usage context remain attached. Check original terms before reusing an image.