- Amir Boroumand | Software Engineer based in Pittsburgh, PA/
- blog/
- Apache Struts Vulnerability Exploited in Equifax Breach (CVE-2017-5638)/
Apache Struts Vulnerability Exploited in Equifax Breach (CVE-2017-5638)

Overview #
The Equifax data breach announced last week exposed the personally identifiable information (PII) of 143 million people. It’s still a developing story, but this is shaping up to be one of the worst breaches in history.
The company has confirmed that hackers gained access by exploiting a vulnerability in Apache Struts which is an open-source framework for building Java web applications. The current major release of Struts has been around for over a decade and is used by many Fortune 500 companies.
In this article, we’ll review the timeline of events, discuss the vulnerability that opened the door to millions of customer records, and outline ways it could have been prevented.
Timeline of Events #
- March 6: Apache discloses Struts 2 vulnerability in Jakarta Multipart parser
- March 7: Exploit made public (exploits-db)
- Mid-May to July: Hackers gain access to Equifax database
- July 29: Equifax discovers the data breach
- September 7: Equifax publicly announces the data breach (press release)
- September 9: The Apache Software Foundation publishes a statement regarding Apache Struts
- September 13: Equifax confirms that CVE-2017-5638 was the vulnerability that was exploited
CVE-2017-5638 #
The vulnerability was announced in March (CVE-2017-5638) and centers on the framework’s Jakarta Multipart parser. The parser can mishandle file upload which allows an attacker to issue remote commands using the Content-Type HTTP header.
Affected versions include Struts 2.3.5 to 2.3.31 and 2.5 to 2.5.10. Struts 1 is not affected.
What’s the fix? #
- Recommended - Upgrade to Struts 2.3.32 or Struts 2.5.10.1
- Workaround - Switch to a different implementation of the Multipart parser or remove the File Upload Interceptor from the stack
- Workaround - Implement a Java Servlet filter which will discard requests containing malformed Content-Type headers
Who was negligent here? #
Equifax.
Contrary to previous speculation, this was not a zero-day exploit. It was a known vulnerability that had an exploit in the wild since March 7th.
Large enterprises are typically slow in rolling out security updates. In addition, upgrading an application framework like Struts can be tricky since it often requires additional development, testing, and code deployments. A company like Equifax may have dozens or hundreds of web apps, so this would have been a complex and painstaking endeavor.
However, given the sensitive nature of the consumer credit data, Equifax has a responsibility to follow industry best practices related to data security. Their security team should have taken prompt action to identify any affected web applications and formulate a plan to address the security flaw back in March.
An Ounce of Prevention #
Here are a few technology best practices that could have helped Equifax:
- Follow a rigorous schedule for staying up-to-date on security patches.
- Deploy a web application firewall (WAF) which is a security appliance capable of blocking unusual HTTP requests with malformed Content-Type headers.
- Automate detection of abnormal network or database activity so it can trigger alarms.