Any Apache Struts 2 vulnerability worth discussing traces back to the same root cause: the framework's OGNL expression language evaluates untrusted input as code far more readily than most developers assume. Struts 2 has had over a dozen critical remote code execution disclosures since 2013, and the pattern is consistent enough that it's worth walking through the history rather than treating each CVE as an isolated event.
Struts 2 is a Java web application framework, and for over a decade it sat underneath a large share of enterprise Java applications, particularly in banking, insurance, and government systems that adopted it during the mid-2000s Java web framework wave. Its longevity is exactly why its vulnerability history matters: systems built on Struts 2 in 2008 are, in some organizations, still running today, often with a version several major releases behind current.
What made CVE-2017-5638 so damaging?
CVE-2017-5638 is the Struts 2 vulnerability most people have heard of, because it was the initial entry point in the 2017 Equifax breach that exposed data on roughly 147 million people. The flaw lived in the Jakarta Multipart parser: a malformed Content-Type header during file upload triggered an OGNL expression evaluation, giving an unauthenticated attacker remote code execution on the server. Equifax had a patch available for over two months before the breach and did not apply it, which is the detail that turned a framework bug into a case study in patch management failure.
The technical lesson is narrower than the headline suggests. The vulnerability existed because Struts 2 parsed certain HTTP headers through an expression evaluator without adequately sandboxing what that evaluator could do. Once an attacker could get arbitrary strings into the OGNL context, remote code execution followed almost immediately, since OGNL by design can invoke Java methods.
Why do OGNL-related flaws keep recurring?
OGNL, Object-Graph Navigation Language, is Struts 2's expression language for binding HTTP parameters to Java objects. It's powerful, and that power is the problem: a poorly scoped OGNL context can be coerced into calling arbitrary methods, including Runtime.exec. Several later CVEs, including issues in the Struts 2 REST plugin and in namespace handling, followed the same shape: user-controlled input reaches an OGNL evaluation path that wasn't properly restricted.
This is a structural issue, not a one-off coding mistake, which is why patching one CVE hasn't stopped new ones from appearing. Each fix has tightened OGNL's sandbox a bit further, but the fundamental design, evaluating expressions built partly from request data, keeps producing new corner cases. Static analysis tools that understand data flow into expression-language sinks catch a meaningful share of these before release; tools that only pattern-match known CVE signatures do not.
How should teams manage Struts 2 risk today?
If you still run Struts 2, the practical answer is threefold. First, stay current: the project has continued releasing patched versions, and being two or three versions behind is where most exploitable exposure lives. Second, run software composition analysis against your dependency tree so a Struts 2 upgrade doesn't silently reintroduce a vulnerable transitive version through a plugin. Third, treat any internet-facing Struts 2 application as a priority target for both SAST, to catch OGNL-adjacent misuse in custom code, and periodic DAST scanning, since some of these flaws are only observable in live request handling.
Safeguard's SCA tooling flags outdated Struts 2 dependencies and known-vulnerable versions automatically as part of a broader dependency inventory, which matters because Struts 2 exposure is frequently inherited through a transitive dependency rather than a direct one. Combined with SAST/DAST coverage on the application layer itself, that gives a reasonably complete picture of exposure.
Migrating off Struts 2 entirely is the long-term answer many organizations eventually choose, given the framework's maintenance mode status and its track record. But for the systems that can't migrate quickly, disciplined patch cadence and dependency visibility are what stand between you and the next Equifax-style incident.
FAQ
Is Apache Struts 2 still maintained?
Yes, the Apache Software Foundation continues to release Struts 2 patches, though development has slowed and organizations are encouraged to plan for eventual migration to actively developed frameworks.
What is OGNL and why does it matter for security?
OGNL is the expression language Struts 2 uses to bind and evaluate data between HTTP requests and Java objects. Because it can invoke Java methods, insufficiently sandboxed OGNL evaluation is the root cause behind most major Struts 2 CVEs.
How do I know if my application is affected by a specific Struts 2 CVE?
Check your exact Struts 2 version and any plugins in use against the CVE's affected version range in the NVD entry, and cross-reference with your software composition analysis tool's dependency inventory rather than relying on manual tracking.
Was Equifax the only major incident involving a Struts 2 vulnerability?
It's the most widely known, but Struts 2 RCE vulnerabilities have been exploited in numerous smaller incidents across banking and government systems since 2013, many never publicly disclosed in detail.