The Equifax Breach: Anatomy of an Unpatched Vulnerability

On September 7th, Equifax, one of the three credit bureaus that hold detailed financial files on most American adults, disclosed a breach affecting roughly 143 million US consumers. Names, Social Security numbers, birth dates, addresses, and for some victims driver's license and credit card numbers. Most of the people affected never chose to be Equifax customers; the data was collected about them, not from them. It's hard to imagine a worse combination of scale and sensitivity.

Details are still emerging, congressional hearings are being scheduled, and some of what follows may be revised as the investigation continues. But the outline from the past two weeks is clear enough to learn from, and the central fact is familiar: a fix for the hole the attackers used had been available for months and wasn't applied.

What we know so far

From Equifax's statements and reporting to date:

• The entry point was a vulnerability in Apache Struts, a widely used Java web framework: CVE-2017-5638, which Equifax confirmed on September 13th.
• The patch predated the attack by about two months. The Struts fix shipped in early March. Equifax says unauthorized access began in mid-May and continued until it was discovered on July 29th.
• Discovery to disclosure took nearly six weeks, from July 29th to September 7th, a gap the company will be answering questions about for some time.
• The flaw was well known. CVE-2017-5638 was rated critical, working exploits circulated within days of the March disclosure, and scanning for vulnerable servers was widespread all spring.

If that sounds familiar, it's WannaCry's pattern with the nouns changed. The patch ships, months pass, and the damage comes through the unpatched gap.

Lesson one: you can't patch what you don't know you run

The Struts advisory went out to everyone in March. Patches like this usually get missed not because someone decided to skip them, but because nobody realized they applied. Struts isn't an application you install; it's a framework inside applications, including vendor-supplied ones whose internals you've never seen. When an advisory says "Apache Struts", someone has to translate that into "our customer portal, the claims system, and that thing procurement bought in 2013".

That translation requires a software inventory: not a two-year-old spreadsheet, but a current answer to "where do we run X?" It's less exciting than any security product and more useful than most:

• Dependency manifests for the software you build (composer.json, pom.xml, Gemfile and so on), kept somewhere queryable.
• Artifact scans for the software you deploy, because manifests go stale and vendors bundle things. Even a crude scan beats nothing:

# Where is Struts actually deployed on this host?
find / \( -name "*.jar" -o -name "*.war" \) 2>/dev/null \
  | xargs -I{} sh -c 'unzip -l "{}" 2>/dev/null | grep -q struts && echo {}'

• A named owner per application. When the next critical advisory lands, "who checks the customer portal?" should have a one-name answer.

The test of an inventory is response time. When a critical CVE drops, how long until you can say where you're exposed and where you aren't? Hours is good. Days is survivable. Finding another instance in week three is how breaches like this happen.

Lesson two: critical CVEs need an SLA, not a backlog ticket

Ordinary patching can run on a calendar. A critical, remotely exploitable vulnerability in internet-facing software, especially one being actively exploited, needs different rules, agreed in advance:

• A defined clock. For actively exploited critical flaws in exposed systems, days rather than sprints. Some teams use 72 hours; pick a number you'll actually honor.
• Permission to be disruptive. The SLA means nothing if any product owner can veto the maintenance window. Settle that authority question before you need it.
• A feed someone reads. Vendor advisories, distro security lists, US-CERT. The Struts warning was everywhere in March. The usual problem isn't missing information; it's information nobody was assigned to read.
• Mitigation as a fallback. When patching has to wait, WAF rules or disabling the vulnerable component buy time, as a tracked exception with an expiry date.

Lesson three: the quiet months

By Equifax's own timeline, attackers were inside from mid-May to late July, roughly ten weeks, before anyone noticed. The initial exploitation is almost the least damning part; eventually something gets through everyone's perimeter. Ten weeks of undetected access is the deeper failure. Ask it of your own systems: if data started leaving tonight, what would notice? Egress volumes, query patterns, authentication anomalies, logs that someone or something actually reviews. Time to detect deserves as much attention as prevention.

Lesson four: practice the communication before you need it

Equifax's response has drawn nearly as much anger as the breach: a help site on a separate, unfamiliar domain that looked a lot like phishing, overloaded call centers, confusion over terms-of-service language, and questions about executives' stock sales before disclosure. Whatever the investigations conclude, the communication was clearly unrehearsed, and rehearsal is cheap:

• Draft notice templates now, with the blanks marked, reviewed by legal on a calm day rather than at midnight.
• Decide where updates will be posted: a status or security page on infrastructure and domains your customers already trust, not a new domain that looks like phishing.
• Run a tabletop exercise. Two hours, once or twice a year: who decides, who writes, who talks to regulators, and what the disclosure clock is. Better to find the gaps yourself than have reporters find them.

The pattern is the lesson

Remove the specifics and Equifax is the same story as WannaCry in May: the vulnerability was known, the fix existed, the warnings were public, and the damage happened in the gap between fix available and fix applied. The defense is inventory, patch discipline, detection and rehearsed communication. None of it is exciting, which is why it keeps getting skipped.

CompleteStatus helps with the watching part: continuous external monitoring of your sites, endpoints and certificates, so changes and failures show up as alerts within minutes. Create a free account, and then check that nothing in your stack is still running a March version of anything.