Apache Struts Vulnerabilities in 2026: Critical CVEs Still Unpatched

In September 2017, Equifax disclosed that attackers had stolen the personal data of 147 million people. The root cause was a single unpatched vulnerability in Apache Struts: CVE-2017-5638, a remote code execution flaw in the framework's multipart request parser. The Apache Software Foundation had released a fix months earlier. Equifax never applied it.

Nearly nine years later, the conditions that enabled that breach have not improved. They have gotten worse.

Apache Struts remains deeply embedded in enterprise Java stacks across finance, government, healthcare, and telecommunications. Sonatype's Maven Central telemetry from January 2026 shows 387,549 downloads of org.apache.struts:* in a single week, with roughly 98% of that activity concentrated on end-of-life Struts 2.x versions. These are versions that will never receive another official security patch from the Apache Software Foundation.

Meanwhile, four new CVEs have been disclosed since late 2024, including one discovered by an AI security research system. If the Equifax breach taught the industry anything, it is that known vulnerabilities in widely deployed frameworks do not age gracefully. They become weaponized.

‍

The Equifax Breach: A Pattern, Not an Anomaly

The Equifax breach was not a sophisticated zero-day attack. CVE-2017-5638 exploited a flaw in how Struts handled Content-Type headers in multipart requests, allowing attackers to inject OGNL expressions and execute arbitrary code. A patch existed. Scanning tools could detect the vulnerability. Equifax simply failed to apply the fix in time.

The consequences were staggering: regulatory fines, a $700 million settlement, executive resignations, and permanent reputational damage. But the more important takeaway is structural. The breach succeeded because a critical framework was running an unpatched version in production, and the organization lacked the operational discipline to close the gap between disclosure and remediation.

That same structural risk exists today for every organization running end-of-life versions of Apache Struts. The only difference is the number of open vulnerabilities has grown. (For historical context on the most exploited Struts flaws, see The top CVEs in Apache Struts.)

‍

Four CVEs in Fifteen Months: The Current Apache Struts Vulnerability Landscape

Since December 2024, four distinct CVE identifiers have been published affecting Apache Struts, each one impacting end-of-life versions that will never receive an official fix. Here is a summary of the current Apache Struts CVE exposure:

‍

CVE-2024-53677: Path Traversal and Remote Code Execution (CVSS 9.5)

Disclosed in December 2024, this vulnerability targets a flaw in Struts' file upload mechanism. Attackers can manipulate file upload parameters to traverse the server's file system, place malicious files in restricted directories, and under certain conditions achieve full remote code execution. The flaw affects Struts versions 2.0.0 through 6.3.0.2. Apache's recommended fix requires upgrading to Struts 6.4.0 and migrating to the new Action File Upload mechanism, a change that is not backward-compatible and demands significant code modifications.

For organizations on Struts 2.5.x or 2.3.x, this remediation path is not just difficult. It is architecturally impossible without a full framework migration. Proof-of-concept exploit code is publicly available, and the Canadian Centre for Cyber Security confirmed active exploitation concerns shortly after disclosure.

‍

CVE-2025-64775 and CVE-2025-66675: Denial of Service via Disk Exhaustion (CVSS 8.2)

Disclosed in November and December 2025 respectively, these two CVEs describe the same underlying vulnerability in Struts' multipart request processing. The JakartaMultiPartRequest class fails to properly clean up temporary files created during file uploads. Attackers can exploit this by sending repeated multipart requests that generate temporary files faster than the system removes them, eventually filling the server's disk and rendering the application completely unavailable.

CVE-2025-66675 was issued to correct incomplete version information in the original CVE-2025-64775 advisory, specifically adding Struts 6.7.4 to the affected range. Both CVEs should be treated as a single remediation item. The vulnerability affects Struts 2.0.0 through 6.7.4 and 7.0.0 through 7.0.3. The fix requires upgrading to Struts 6.8.0 or 7.1.1. No workaround exists.

This attack vector is particularly dangerous because it requires no authentication, has low complexity, and is easily automatable. For organizations running customer-facing applications on Struts, a disk exhaustion attack can cause SLA violations, operational disruption, and cascading failures across infrastructure.

‍

CVE-2025-68493: XML External Entity Injection, Discovered by AI (CVSS 8.1)

This is the most novel disclosure in the group. CVE-2025-68493 was identified by Zast AI, an autonomous AI security research system, and reported via the Apache Struts security bulletin S2-069. The vulnerability resides in the XWork component, the command-pattern framework that underpins Struts' action invocation and configuration processing.

The flaw is a failure of XML validation. XWork's XML configuration parser does not properly restrict external entity resolution, opening the door to XXE injection attacks. An attacker who can influence XML configuration input can craft payloads that read local files (including credentials and configuration data), trigger server-side request forgery against internal resources, or cause denial of service.

The vulnerability affects Struts versions 2.0.0 through 6.1.0 and was fixed in Struts 6.1.1. The fix is backward-compatible, which simplifies the upgrade for organizations on Struts 6.x. For organizations on Struts 2.3.x or 2.5.x, however, no fix will ever be issued.

What makes this CVE significant beyond its technical impact is the discovery method. AI-assisted vulnerability research is accelerating the pace at which flaws are found, but enterprise remediation timelines have not kept up. As Sonatype noted, if vulnerabilities are being discovered faster than ever, organizations relying on traditional patch-and-upgrade workflows face a widening gap between discovery and defense.

‍

380,000 Downloads Per Week: The Scale of Apache Struts End of Life Exposure

The raw download numbers tell a stark story. In the week following the CVE-2025-68493 disclosure, Sonatype observed 387,549 downloads of org.apache.struts:* packages from Maven Central. Of those downloads, approximately 98% were for end-of-life Struts 2.x versions. Only about 1.8% targeted Struts 6.0.0 through 6.1.0.

To put this in context: Struts 2.3.x has been end-of-life since September 2019, making it unmaintained for over 2,270 days as of January 2026. The Struts 2.5 EOL date arrived in April 2024, when the Apache Software Foundation officially ended support for the 2.5.x branch after a six-month wind-down period announced in October 2023. (For a complete timeline, see Apache Struts end-of-life dates you need to know.) Both version lines are affected by every CVE discussed in this article, and neither will receive an official patch.

These are not hobbyist downloads. Apache Struts is an enterprise framework used to build mission-critical applications in regulated industries. The organizations pulling these artifacts are building, deploying, and maintaining production systems on a foundation that has known, exploitable vulnerabilities with no upstream fix.
‍

Why Migration is Not a Simple Answer

The standard advice for EOL software is straightforward: upgrade to a supported version. For Apache Struts, that means migrating to Struts 6.x or 7.x. In practice, this migration is anything but simple.

Struts 2.5.x to 6.x requires Java 8 at minimum (with Java 11+ recommended), Servlet API 3.1, and significant changes to interceptors, action configurations, and plugin usage. The file upload mechanism was completely redesigned in 6.4.0, breaking backward compatibility for any application using the legacy FileUploadInterceptor. For applications originally built on Struts 2.3.x, the gap is even wider: two major version jumps, an entirely different configuration model, and potential rearchitecting of the application layer.

For enterprises with large Struts-based application portfolios, migration is a multi-quarter engineering initiative. Meanwhile, the CVEs keep coming.

‍

The Compliance Dimension

Running EOL software with known, unpatched vulnerabilities is not just a security risk. It is a compliance liability. PCI DSS requires organizations to install vendor-supplied security patches within a defined timeframe. SOC 2 controls require evidence of vulnerability management and timely remediation. The EU Cyber Resilience Act, which began applying to product categories in 2025, imposes specific obligations around vulnerability handling and security update delivery for software products.

When the software vendor (in this case, the Apache Software Foundation) has declared a version end-of-life, the patch obligation does not disappear. It transfers to the organization running the software or to a commercial support provider that can deliver patches for the EOL version.

‍

Securing What You Cannot Yet Migrate

For organizations that cannot complete a Struts migration on the timeline that these CVEs demand, there is an alternative to accepting the risk.

HeroDevs provides Never-Ending Support (NES) for Apache Struts, delivering security patches for EOL versions including Struts 2.3.x and 2.5.x. NES for Struts operates as a drop-in replacement: the same package coordinates, the same API surface, with security fixes backported to the versions your applications already run. No migration required.

HeroDevs tracks every CVE affecting the Apache Struts ecosystem, including transitive dependency vulnerabilities like CVE-2025-48976 (a DoS flaw in Apache Commons FileUpload that impacts Struts' file handling). The HeroDevs vulnerability directory provides detailed advisories, affected version ranges, and fix availability for each issue, including CVE-2025-68493, which was patched in the NES for Struts release within one day of the public disclosure.

‍

Taking Action

The Equifax breach happened because a known vulnerability in a widely deployed framework went unpatched. Nine years later, the same framework is accumulating critical CVEs at an accelerating pace, and 98% of its weekly downloads are for versions that will never receive a community fix. AI-powered vulnerability discovery is compressing the window between flaw identification and potential exploitation. The question is not whether another Struts-related breach will occur, but whether your organization will be the one running a vulnerable version when it does.

If your applications depend on Apache Struts 2.3.x, 2.5.x, or early 6.x versions, the path forward starts with visibility. Audit your software bill of materials to identify every Struts dependency. Assess which applications can realistically migrate to Struts 7.x and which need an alternative. For the applications that cannot migrate today, explore NES for Apache Struts to ensure they remain patched and compliant while you plan the transition.

The Equifax lesson is simple: known vulnerabilities in production systems are not theoretical risks. They are open doors. Close them.

‍