Practice & Reference · Case Study · Real company

Equifax — an unpatched dependency

This is a real, named company's story, and this page sticks to what's on the public record: the Apache Struts project's own security advisory, Equifax's own disclosures and congressional testimony, and the U.S. House Committee on Oversight and Government Reform's December 2018 report, The Equifax Data Breach, which remains the single most detailed public account of what actually happened inside Equifax's systems. The headline fact is almost insultingly simple: the vulnerability that let attackers into Equifax had a vendor patch available on the same day it was publicly disclosed. Equifax did not install it for 76 days on the one system that mattered. This page is about that 76-day gap — not because patching is hard, but because knowing you need to and verifying you did turned out to be the actual failure, and that's a process problem, not a tooling problem.

The vulnerability: CVSS 10.0, patched the day it was disclosed

☺ Like you're 10: The worst possible score on the "how bad is this" scale, for a flaw that a total stranger on the internet could use to take over your computer — and the fix was ready before most people had even heard about the problem.

On March 7, 2017, the Apache Struts project published security advisory S2-045 for CVE-2017-5638, a remote code execution vulnerability in the Jakarta Multipart parser used by Struts2 to handle file uploads. The flaw sat in how the parser handled a malformed Content-Type header during an exception: instead of treating the header as inert text, the error-handling path passed it through OGNL (Object-Graph Navigation Language, Struts' expression language for binding form data to Java objects) without sanitizing it first. A request crafted with an OGNL expression in the Content-Type field didn't just crash the parser — it got evaluated, on the server, with the application's own privileges. No authentication required, no user interaction needed, full remote code execution from a single malicious HTTP header. It's the kind of flaw Secure Coding Patterns covers under the same family as the deserialization gadget chains discussed there: untrusted input reaching a code-execution path that nobody intended to expose.

Apache didn't just disclose the bug — the same advisory shipped the fix, in Struts 2.3.32 and 2.5.10.1. The National Vulnerability Database scored it a perfect CVSS 10.0: maximum impact across confidentiality, integrity, and availability, minimum complexity to pull off. Within days, security researchers and honeypot operators — Cisco Talos and Rapid7 among them — were already recording mass, automated scanning and exploitation attempts against the flaw across the open internet. This was never a quiet, theoretical CVE that sat unnoticed in a database. It was front-page security news the week it dropped, with a patch already sitting in the release Equifax's own engineers could have pulled the same afternoon.

Equifax had a process on paper. Here is exactly where it broke.

☺ Like you're 10: Sending an email that says "fix this" isn't the same as checking that anyone actually did — and Equifax's story is what happens in the gap between the two.

The House Oversight Committee's report is unusually specific about what Equifax actually did, and the timeline is damning precisely because it shows a company that was trying, not one that ignored the advisory entirely:

• March 8, 2017 — the day after the advisory, US-CERT (the federal cybersecurity alert body) sent Equifax's internal Global Threat and Vulnerability Management team a notification about CVE-2017-5638.
• March 9, 2017 — Equifax's own vulnerability-management team emailed the alert to more than 400 people across the organization, per the committee's report, with instructions to patch any affected Apache Struts installation within 48 hours, per Equifax's own internal policy for a critical vulnerability.
• March 15, 2017 — Equifax's security team ran both manual reviews and automated vulnerability scans intended to catch any system that had missed the deadline. The scans did not identify the Automated Consumer Interview System (ACIS) — the online portal consumers used to dispute items on their credit report — as a system running the vulnerable Struts library. ACIS stayed unpatched, and nobody knew it had.

That third bullet is the entire case study in one sentence. This wasn't "Equifax never scanned." Equifax scanned, on schedule, six days after the internal deadline, specifically looking for exactly this problem — and the scan came back clean on the one system that wasn't. Congressional testimony and Equifax's own later statements didn't converge on a single tidy root cause for why the scan missed ACIS; the committee's report points to gaps in Equifax's asset inventory — nobody had a complete, trustworthy list of every internet-facing system and the third-party components each one depended on, so the scan's scope was already wrong before a single request went out. That's not a criticism unique to Equifax. It's the default failure mode of any vulnerability program that treats "we have a scanner" as equivalent to "we know what we're running" — see Software Bills of Materials for the control that closes exactly this gap.

76 days, and a second, unrelated failure that hid it

☺ Like you're 10: Even a burglar who gets in through an unlocked door usually still trips an alarm eventually — unless the alarm's own battery died months ago and nobody noticed that either.

Attackers began exploiting the unpatched ACIS system on May 13, 2017, roughly two months after the Struts patch had shipped, and moved laterally from there — the House Oversight Committee's report describes them pivoting from the compromised web application into other parts of Equifax's network, eventually reaching databases containing consumer PII that had no obvious business relationship to a credit-dispute web form. That lateral movement is itself worth pausing on: it's a reminder that a single unpatched, internet-facing component is rarely the whole story — it's the entry point, and what happens after entry depends on network segmentation and least-privilege access that this course covers in Kubernetes Security Deep Dive and Zero Trust for Pipelines.

The access continued undetected for 76 days. Per the committee's report, one specific, ordinary-sounding operational failure explains a meaningful part of that gap: the device responsible for inspecting encrypted (SSL/TLS) traffic on the relevant network segment was running with an expired inspection certificate — for approximately 19 months. With that certificate expired, the device could no longer decrypt and inspect traffic crossing the segment, so the encrypted channel the attackers were using to move data out went unexamined by the very control meant to catch it. Equifax renewed the certificate on July 29, 2017. Within roughly a day of restoring visibility into that traffic, its security team spotted the suspicious pattern, investigated, and took the ACIS application offline.

The aftermath: 147 million records, a $700 million settlement, and three departures

☺ Like you're 10: A mistake this size didn't just cost data — it cost money, jobs, and, for one executive, a criminal conviction.

Equifax publicly disclosed the breach on September 7, 2017. The final scope, per Equifax's own subsequent disclosures: approximately 147 million people's names, dates of birth, and Social Security numbers, with a substantial subset also exposing addresses and, for some, driver's license numbers; roughly 209,000 people additionally had credit card numbers exposed; and around 182,000 had personal information exposed through dispute documents submitted to ACIS itself — the very system the attackers first got into. The breach wasn't US-only: Equifax later confirmed exposure affecting UK and Canadian residents as well.

Three senior leaders left within weeks of disclosure. Equifax announced on September 15, 2017 that CIO David Webb and CSO Susan Mauldin were retiring effective immediately; Chairman and CEO Richard Smith retired on September 26, 2017, after testifying before Congress that the breach traced to "human error and technology failures" — a summary that, per the timeline above, undersells how much of it was process failure specifically. Separately, and more seriously: Equifax's former CIO of US Information Solutions, Jun Ying, pleaded guilty in 2018 to insider trading — he exercised stock options and sold shares after learning internally about the breach but before it was made public, netting roughly $1 million in avoided losses, and was later sentenced to prison. Three other executives who sold shares in the same window were investigated by Equifax's own board and, separately, federal authorities; Equifax's internal review concluded they hadn't known about the breach when they traded, though the timing understandably drew scrutiny regardless.

In July 2019, Equifax reached a settlement with the FTC, the CFPB, and all 50 states and territories, reported at the time as worth up to $700 million — a $175 million payment to the states, a $100 million CFPB civil penalty, and a fund of up to $425 million to compensate affected consumers. As with any regulatory settlement, treat the exact figure as "what was announced," not a number every dollar of which was necessarily paid out exactly as structured; readers wanting the current, authoritative figures should check the FTC's own settlement page rather than this summary.

What would actually have stopped this

☺ Like you're 10: Not "scan once and email people" — a system that knows what you're running, checks it constantly, and won't let a fix get marked done until someone actually verifies it's done.

It's worth being precise about what this case does and doesn't indict. It doesn't indict vulnerability scanning as a category — Equifax's scan on March 15 was exactly the right instinct, run on a reasonable schedule, by a team that clearly cared enough to send a 400-person alert six days earlier. What it indicts is treating a scan as a single event instead of a continuously-running, continuously-verified system. Three specific gaps, each one covered elsewhere in this course, are what a mature Software Composition Analysis and vulnerability management and triage program closes:

• A trustworthy asset inventory, generated automatically. Equifax's scan couldn't find a vulnerable component it didn't know to look for. An SCA tool that runs at every build and produces a real SBOM for every deployed service doesn't depend on someone remembering ACIS uses Struts — it's derived directly from the actual dependency tree, every time.
• Continuous rescanning against a live vulnerability feed, not a point-in-time check. A dependency that was clean on March 1 and vulnerable on March 7 stays "clean" in a system that only checks once. A working program rescans the existing SBOM against fresh CVE and KEV data continuously, so a newly-disclosed critical flaw in something already deployed surfaces automatically instead of waiting for the next scheduled audit.
• A triage workflow with an owner, an SLA, and a verified-closed state — not an email. "Patch within 48 hours" sent to 400 people has no single owner and no mechanism that confirms the fix actually landed. A finding tracked in a system like DefectDojo, with a severity-driven SLA and a re-scan that has to come back clean before the ticket closes, is the difference between a policy and an enforced control.

Where this connects in the course

☺ Like you're 10: This one breach touches almost every module in "Securing the Pipeline" — read whichever piece matches what you're building.

The mechanics of catching a vulnerable dependency before it ships are SAST, DAST & SCA and, in far more depth, Software Composition Analysis in Depth; what to do with the findings once you have them — the exact discipline missing from Equifax's 400-person email — is Vulnerability Management & Triage. Knowing what you're actually running, which is where Equifax's asset inventory broke down first, is Software Bills of Materials and Dependency & License Risk Management; separating "how bad could this be" from "is anyone actively exploiting it right now" is Secure by Design & Threat Intelligence, which already uses this exact breach as its worked example. A hands-on, timed version of the triage decision this case study is built around — real CVSS, EPSS, and KEV data, a mixed pile of findings, ten minutes on the clock — is Drill: Vulnerable Dependency Fire Drill, modeled directly on this breach; the fuller, continuity version of the same stage lives in Capstone Part 3 — Add an SCA Gate. Tool-wise, Trivy and Syft & Grype cover modern SCA scanners; DefectDojo covers where findings live once they exist. For a different failure mode in the same neighborhood — a trusted vendor's own build pipeline getting compromised, rather than an unpatched open-source dependency — read SolarWinds — a supply-chain attack; for a fictional, fully worked pipeline you can compare this real case against, see the course's own case study.

What this case doesn't prove

☺ Like you're 10: One very public failure doesn't mean scanning is pointless, or that every company can patch as fast as the headlines imply it should — the honest lesson is narrower than that.

• This isn't an argument against a 48-hour patch SLA. The SLA itself was reasonable for a CVSS 10.0, actively-exploited flaw. The failure was that the SLA had no verification step — an instruction with no mechanism confirming compliance isn't a control, whatever the deadline says.
• Not every unpatched CVE is an Equifax waiting to happen. This flaw scores at the extreme end on every axis that matters — unauthenticated, remotely exploitable, on an internet-facing system, with confirmed mass exploitation in the wild within days. Most findings in a real backlog are nowhere near this combination, which is exactly why severity-and-SLA triage exists — to spend urgency where it's earned, not to treat every CVE as a five-alarm fire.
• Patching alone would not have made Equifax's broader security posture sound. The 19-month-expired inspection certificate is a separate, independent failure. A company can close the SCA gap this case is mostly about and still get breached by a different, unrelated lapse — defense in depth exists because no single control, patched or otherwise, is the whole story.
• The exact mechanism of the scan's miss isn't settled down to a single root cause in public reporting. The House Oversight Committee's report points to asset-inventory gaps as the likely explanation; some later commentary has focused instead on possible scan-configuration or scope issues. Both point to the same practical fix — an automatically generated, continuously verified inventory — so this page treats them as two descriptions of the same underlying gap rather than picking one with more certainty than the public record actually supports.

Check your answers

1. A remote code execution flaw in Apache Struts2's Jakarta Multipart parser, where a malformed Content-Type header got evaluated as an OGNL expression instead of being treated as inert text — no authentication needed, full server-side code execution. It scored CVSS 10.0 because it combined maximum impact with minimum complexity to exploit.
2. March 7: Apache disclosed the flaw and shipped the patch simultaneously. March 9: Equifax's own vulnerability-management team emailed a 48-hour patch instruction to 400+ people. March 15: Equifax ran vulnerability scans meant to catch anything still unpatched — the scans didn't identify the ACIS dispute-portal system as running the vulnerable Struts library, so it stayed unpatched with nobody aware.
3. An SSL-traffic-inspection device on the relevant network segment had an expired certificate for roughly 19 months, so it couldn't decrypt and inspect the encrypted channel attackers used to move data. Once the certificate was renewed on July 29, the anomalous traffic was spotted almost immediately.
4. (1) A trustworthy, automatically generated asset inventory / SBOM — Equifax's scan missed ACIS because nobody's inventory reliably flagged it as running Struts2. (2) Continuous rescanning against a live vulnerability feed, not a one-time check — a dependency clean on day one can become critical on day seven. (3) A triage workflow with an owner, an SLA, and a verified-closed state — Equifax's 48-hour instruction went to 400 people with no single owner and no mechanism confirming the fix actually landed.
5. Because a scanner produces a list of findings, but nothing about running a scanner guarantees the list gets acted on, verified, or even correctly scoped in the first place. Vulnerability management is the closed loop of inventory, continuous checking, ownership, and verification around that list — Equifax had the first thing and not the second, and the gap between them is what turned a same-day patch into a 76-day breach.