On December 7, 2023, the Apache Software Foundation disclosed CVE-2023-50164, a critical vulnerability in Apache Struts that allowed remote code execution through manipulation of file upload parameters. The vulnerability affected Struts 2.0.0 through 2.5.32 and Struts 6.0.0 through 6.3.0. Within days, proof-of-concept exploits were publicly available, and security firms began observing exploitation attempts in the wild.
For anyone who lived through the Equifax breach in 2017, the announcement triggered a visceral reaction. That breach, which exposed the personal information of 147 million Americans, was caused by an unpatched Apache Struts vulnerability (CVE-2017-5638). Six years later, Struts was once again producing critical RCE vulnerabilities that threatened any organization still running the framework.
The Technical Details
CVE-2023-50164 was a path traversal vulnerability in Struts' file upload mechanism. The flaw existed in how Struts handled file upload parameters. By manipulating certain request parameters, an attacker could control the path where uploaded files were stored on the server. This path traversal capability allowed placing a malicious file (such as a JSP webshell) in the web application's document root, where it could be executed through a direct HTTP request.
The attack chain was straightforward: send a crafted multipart request to a Struts action that handles file uploads, manipulate the upload path to place a webshell in an accessible location, and then request the webshell to execute arbitrary commands on the server.
The vulnerability required that the target application had at least one action that processed file uploads, which is extremely common in web applications. Upload functionality for documents, images, attachments, or any other file type provided the entry point.
The Equifax Shadow
The Equifax breach fundamentally changed how the industry views Apache Struts vulnerabilities. When Equifax disclosed in September 2017 that attackers had exploited CVE-2017-5638, an Struts vulnerability that had been patched months earlier, the breach became a case study in patch management failure. The FTC settlement cost Equifax at least $575 million.
CVE-2023-50164 was different in mechanism (path traversal vs. OGNL injection) but shared the same critical characteristics: it was a pre-authentication RCE in a widely deployed framework. The parallels were impossible to ignore.
The security community's response reflected the Equifax lesson. Exploitation proof-of-concepts appeared within 48 hours. CISA issued an advisory. Security vendors pushed detection signatures rapidly. And organizations that had Apache Struts in their inventory immediately prioritized patching.
But organizations that didn't know they had Struts in their inventory, that's where the real risk lived.
The Discovery Problem
Apache Struts is a Java web framework, and like many Java frameworks, it can be embedded in applications in ways that aren't immediately obvious. A compiled WAR file might include Struts JARs deep in its library directory. An application might have been built on Struts years ago by developers who have since left the organization. Container images might include applications with Struts dependencies that were never documented.
When CVE-2023-50164 was disclosed, the first question for every security team should have been: "Where are we running Apache Struts?" For organizations with mature software inventory practices, this question had an immediate answer. For others, it triggered the same scramble that had occurred with Log4Shell, Text4Shell, and every other library-level vulnerability: manual searching, build file analysis, and container image scanning.
The organizations that answered the question fastest were those with comprehensive SBOMs for their deployed applications. An SBOM that lists Apache Struts as a component, along with its version, immediately tells you whether you're affected and where the vulnerable instances are running.
Exploitation Activity
Security researchers and honeypot operators observed exploitation attempts within days of the public disclosure. Initial exploitation was largely opportunistic: automated scanning for Struts applications followed by payload delivery. More targeted exploitation followed as threat actors identified high-value targets running vulnerable Struts versions.
The exploitation patterns included deploying JSP webshells for persistent access, cryptocurrency mining payloads, and reconnaissance activity consistent with initial access brokers selling access to compromised systems.
The speed of exploitation underscored a persistent reality: the window between vulnerability disclosure and active exploitation continues to shrink. Organizations that can't identify and patch affected systems within days are operating in the exploitation window.
Why Struts Keeps Producing Critical Vulnerabilities
Apache Struts has a history of critical vulnerabilities that extends back over a decade. The framework's architecture contributes to this pattern in several ways.
OGNL expression injection. Struts uses the Object-Graph Navigation Language (OGNL) for various runtime operations. OGNL expressions that process user input have repeatedly led to remote code execution vulnerabilities because OGNL can invoke arbitrary Java methods.
Complex input processing. Struts' parameter handling, type conversion, and validation mechanisms process user input through multiple layers. Each layer is a potential vulnerability point, and the interactions between layers create additional complexity.
Legacy codebase. Struts 2 has been maintained since 2007. While it has been modernized over time, it carries architectural decisions from an era when security assumptions were different. Redesigning core input handling would break backward compatibility, so the framework must work within its existing architecture.
Ongoing maintenance challenges. The Apache Struts project, like many open-source projects, is maintained by a relatively small team of volunteers. The resources available for security review, fuzzing, and architectural improvements are limited compared to the project's deployment footprint.
Migration Considerations
For organizations evaluating their long-term use of Apache Struts, the repeated pattern of critical vulnerabilities raises a strategic question: is it time to migrate to a different framework? Spring Boot, Jakarta EE, and other modern Java frameworks have different security profiles and generally benefit from larger maintainer communities and more active security investment.
Migration from Struts is a significant engineering effort, but the ongoing risk of critical RCE vulnerabilities may justify it. At minimum, organizations should assess whether their Struts applications are still actively developed. If an application is in maintenance mode running on Struts, the risk of future vulnerabilities accumulates without the benefit of active development investment.
How Safeguard.sh Helps
Safeguard.sh provides the immediate answer to "where are we running Apache Struts?" that organizations need when a critical CVE drops. Our SBOM generation catalogs framework dependencies across all your applications, giving you a complete inventory that includes version information. Continuous vulnerability scanning matches your inventory against known CVEs in real time, alerting you the moment a new Struts vulnerability is disclosed. Policy gates can enforce framework version requirements, preventing deployment of applications with known-vulnerable Struts versions. The difference between a controlled patch cycle and an Equifax-scale incident often comes down to knowing your exposure before the attackers find it for you.