In the long history of cybersecurity failures, few events rival the 2017 Equifax breach — a catastrophe that exposed the personal data of 147 million people and cost the company more than $2 billion in damages, remediation, and fallout. But what makes this breach particularly infamous is not the scale, nor the sensitivity of the data stolen. It’s the fact that the entire breach hinged on a single unpatched vulnerability — one for which a fix already existed.
This post is Part 2 of the series, where we examine the flaw at the center of the crisis: CVE-2017-5638, a remote-code-execution vulnerability in Apache Struts. We’ll dig into why Struts was so popular, how attackers exploited the flaw, why Equifax’s patching process failed, and why patch management remains one of the hardest — and most important — challenges in cybersecurity.
To understand how Equifax fell, we need to understand the vulnerability itself. CVE-2017-5638 was a Remote Code Execution (RCE) flaw disclosed in March 2017 that affected Apache Struts 2, a popular open-source framework used for building Java-based web applications.
The vulnerability existed in Struts’ Jakarta Multipart Parser, the component responsible for handling file uploads. Specifically:
When a user uploads a file, the request contains a Content-Type header.
Struts used this header to determine how to process the uploaded content.
But a flaw in the error-handling code meant that attackers could insert malicious OGNL (Object-Graph Navigation Language) expressions directly into the header.
The application — instead of rejecting the malformed header — would evaluate it on the server.
This meant attackers could send a specially crafted HTTP request that caused Struts to execute arbitrary system commands, effectively giving them full control of the underlying server.
No authentication required — anyone could exploit it.
One request was enough.
RCE on a production web server means instant and total compromise.
Exploitation was simple — publicly available PoC scripts appeared within days.
The Apache Foundation moved quickly. A patch was released the same day the vulnerability became public.
But the damage was already in motion.
To understand why Equifax — and many other enterprises — relied on Struts, we need to rewind and examine its role in the early 2000s and 2010s.
Before Spring Boot dominated the Java web ecosystem, Struts was:
Stable
Enterprise-friendly
Well-documented
Flexible
Backed by the Apache Software Foundation
It offered a framework that allowed large organizations to build web applications with a predictable MVC pattern — ideal for companies with long development cycles.
Equifax’s core dispute portal, one of the systems compromised, was built in Struts because:
It was established and widely adopted.
It scaled well for enterprise workloads.
It fit the architecture of long-lived monolithic systems.
By 2017, Struts had become:
Legacy, but still heavily used in production.
Hard to maintain, especially with custom extensions.
Known for complex upgrade paths.
Dependent on manual patching cycles.
Enterprises — including financial institutions — often ran Struts versions that were several years old, because upgrading required regression testing across massive monolithic applications.
This reliance on Struts, combined with slow upgrade processes, created an ecosystem where known vulnerabilities remained in production systems for far too long.
Once the vulnerability was publicly disclosed, attackers moved fast. Security researchers detected mass scanning for the flaw occurring within days.
The attacker simply sent a crafted HTTP request such as:
Content-Type: %{(#context[‘com.opensymphony.xwork2.ActionContext.container’]
.getInstance(@ognl.OgnlContext@DEFAULT_CLASS_RESOLVER).findClass(‘java.lang.Runtime’)
.getRuntime().exec(‘commandHere’))}
Struts would interpret the OGNL payload because:
The header triggered an exception inside the multipart parser.
Struts’ error handler used OGNL for message evaluation.
The attacker-controlled payload was executed on the server.
Once inside, attackers could:
Run arbitrary system commands
Install web shells
Open outbound connections
Move laterally through the network
Exfiltrate sensitive data
For Equifax, this meant attackers were able to plant a web shell and operate inside the system for 76 days before being detected.
After disclosure:
Exploit kits included the vulnerability within days.
Botnets were scanning the internet for vulnerable Struts servers.
A simple Python script could exploit the flaw.
Attackers didn’t need insider information. They just needed an unpatched server.
Equifax had a patch management process — at least on paper. In reality, the system was fractured, misaligned, and dependent on manual workflows that broke under real-world pressure.
March 7, 2017: Apache releases the patch.
March 9, 2017: DHS sends a vulnerability alert to Equifax.
Mid-March: Equifax’s security team instructs IT to patch all Struts systems.
But the vulnerable server is never updated.
Multiple failures contributed:
Ownership of systems was unclear. A Struts-based system could fall under:
Infrastructure
Application development
Security operations
Each assumed another team had patched it.
Equifax ran vulnerability scans, but:
The scanner failed to detect that Struts was in use.
A certificate error caused a scanning tool to go offline.
No monitoring existed to confirm the scanner was functioning.
This meant Equifax believed no system was vulnerable — because the scanner incorrectly reported a clean bill of health.
Patching instructions were issued, but:
No checks were done to verify the patches were actually applied.
There was no enforcement mechanism.
There was no SLA for patch confirmation.
The process relied entirely on manual follow-through.
Patching Struts often required:
Code refactoring
Regression testing
Manual redeployments
This slowed down the fixing process, especially for older applications that were no longer actively developed.
Equifax’s post-mortem report revealed something striking: the breach was not caused by a lack of tools or policies, but by miscommunication and human error.
The security team distributed the patch instructions. But:
The recipient assumed the system wasn’t using Struts.
The scanning tools incorrectly reinforced this belief.
No one double-checked.
Equifax’s team believed:
“If the scanner doesn’t detect a vulnerability, we’re safe.”
This mindset is dangerous. Scanning tools fail. False negatives happen. Automation must be paired with human oversight.
For a vulnerability allowing unauthenticated RCE:
Immediate patching is non-negotiable.
Cross-functional response teams should mobilize.
Verification should be mandatory.
Instead, the organization treated it like a routine advisory.
Equifax was a dramatic example, but the problem is universal.
Old systems often:
Cannot be easily updated
Have incompatible dependencies
Require full QA cycles
Patching them is slow, risky, and expensive.
Large companies have:
Thousands of servers
Multiple business units
Hybrid cloud environments
On-prem legacy systems
Coordinating patches across all of them is difficult.
Many organizations still struggle to answer:
“Do we know every service running in our environment?”
Unsurprisingly, unpatched systems hide in the shadows.
Downtime for patching competes with:
Feature releases
Customer deadlines
Operational obligations
Security rarely gets the loudest voice in the room.
The Equifax breach changed the industry. From their mistakes emerged best practices that modern teams must adopt.
These are “drop everything and patch now” events. No exceptions.
A proper process includes:
Patch notification
Assignment
Action
Verification
Audit confirmation
No step can rely solely on trust.
You can’t patch what you don’t know exists.
Use:
Manual spot checks
Multiple scanning engines
Continuous monitoring
Penetration tests
Configuration auditing
Defense in depth applies here too.
Old systems introduce security debt.
Every asset should have:
A clear owner
A defined maintenance process
Security SLAs
Ambiguity kills.
The Equifax breach did not happen because attackers were too smart or because the vulnerability was too obscure. It happened because a patch — one released months before the breach — was simply never applied. A single point of failure cascaded into one of the worst security incidents in history.
The lesson is timeless: patching is not optional, and visibility, ownership, and verification matter more than policies written on paper.
Fixing a flaw might take minutes.
Failing to fix it can cost billions.