Apache Struts EOL: Keep Your Java Web Applications Secure | TuxCare ELS

Key Takeaways

• When a Struts version reaches end of life, the entire dependency stack, OGNL, FreeMarker, Commons FileUpload, Commons BeanUtils, Log4j2, and others stop receiving coordinated security fixes alongside the framework itself.
• The migration from Struts 2.5.x to 6.x requires Java runtime upgrades, Servlet API changes, OGNL expression rewrites, interceptor interface replacements, and removal of static method access patterns, all of which demand careful planning and extended testing, not compressed timelines.
• TuxCare ELS extends security coverage for EOL Struts versions and their dependency trees, so organizations can maintain security and compliance while planning a deliberate, properly resourced migration on their own timeline.

Struts has been the backbone of enterprise Java web development for over two decades. Its Model-View-Controller architecture, mature plugin ecosystem, and deep integration with the broader Java enterprise stack have made it the framework of choice for large-scale web applications across financial services, government, healthcare, and telecommunications. But Struts has a history that makes the end-of-life question unusually high-stakes. It has the most consequential CVE record of any Java web framework in production, and organizations running Apache Struts EOL versions are carrying a risk profile that the 2017 Equifax breach turned from theoretical to front-page news.

This article explains what Apache Struts EOL actually means for Java application teams, where the real security exposure hides in the dependency tree, why the migration path to current versions is more demanding than it appears, and how TuxCare’s Endless Lifecycle Support (ELS) lets you maintain full security and compliance coverage without forcing a migration your teams aren’t ready for.

What Is the Apache Struts Product Lifecycle?

Struts does not follow a formally documented, time-based release cadence the way some other open-source projects do. The project’s Apache Software Foundation PMC publishes EOL notices directly on the project website when a major branch is approaching retirement, typically providing a six-month warning before support formally ends. EOL notices are not tied to a fixed calendar schedule; they reflect the community’s capacity to maintain a given branch and the availability of a supported successor.

For instance, you can check our guide on Apache Kafka EOL to see how streaming infrastructure handles similar support cliffs, or look into how big data frameworks manage an Apache Spark end of life lifecycle milestone. You can also learn more about Apache hive EOL in our in-depth guide if you are managing data warehousing components.

The project follows semantic versioning and maintains support for its current active branches. EOL notices have historically come with six months of continued security-only coverage after the initial announcement, after which the branch receives no further patches of any kind. This means there is no grace period for security vulnerabilities disclosed after the final EOL date; any CVE affecting an EOL branch will not receive an official community fix.

The current Struts release support status:

Version	Release Date	EOL Date	Status
Struts 1.x	2000–2008	April 2013	EOL
Struts 2.3.x	2012	May 2019	EOL
Struts 2.5.x	May 2016	April 30, 2024	EOL
Struts 6.x	June 2022	Not announced	Active (latest)
Struts 7.x	December 2024	Not announced	Active

Struts 2.5.x, the version most widely deployed in enterprise environments, received its final release (2.5.33) in December 2023 and formally reached end of life on April 30, 2024. Organizations that have not completed their migration to Struts 6.x or 7.x are now running an Apache Struts EOL framework with no upstream security patch coverage.

The practical consequence of this lifecycle model is significant. Because the project does not publish fixed future EOL dates years in advance, organizations often find that an EOL announcement arrives before a migration was budgeted, resourced, and planned. The six-month Apache Struts EOL notice period is not sufficient runway for large enterprise applications with extensive Struts integration to complete a tested, validated migration.

What Does Apache Struts EOL Mean for Java Web Applications?

For organizations running Struts as the web tier of mission-critical Java applications handling public-facing HTTP requests, managing file uploads, processing form submissions, and sitting in front of business logic layers that touch financial records, patient data, or government systems, the Apache Struts EOL designation is not a housekeeping concern. It is a security event with direct compliance consequences.

No More Security Patches After the EOL Date

Once a Struts version reaches end of life, the Apache community stops publishing security fixes for it. Any vulnerability disclosed after the EOL date, whether in the framework’s core dispatcher, its OGNL expression evaluation engine, its file upload handling, or its interceptor stack, will not receive an official patch. The only remediation path the community offers is migrating to a supported release.

For teams running large, production-critical web applications where migration requires rewriting Action classes, replacing interceptor interfaces, updating OGNL expressions throughout templates, and validating behavior across dozens or hundreds of application endpoints, that is not always an option on short notice. The gap between when EOL status takes effect and when a migration can realistically be completed and validated is exactly when unpatched vulnerabilities accumulate.

Security and Compliance Risks After End of Life

The compliance consequences of running an EOL Struts version are direct. PCI DSS (Requirement 6.3.3) requires critical and high-severity patches to be installed within one month of patch release, but on an EOL Struts version, there are no patches to install, making compliance through normal means impossible. SOC 2 auditors flag end-of-life software in production environments. Organizations running Apache Struts EOL deployments face documentation gaps that surface in security questionnaires, stall vendor certifications, and in regulated industries, block customer renewals.

For organizations where Struts applications sit in a PCI scope, process personally identifiable information, or underpin services with contractual SLA obligations, the compliance exposure from this EOL event is not theoretical. It is an audit finding waiting to materialize.

CVE History: What the Vulnerability Record Shows

Struts has the most consequential CVE record of any Java web framework in production, and the history makes a direct case for why patched EOL coverage is not optional.

CVE-2017-5638 (CVSS 10.0 Critical) is the vulnerability that exposed personal and financial data of 147 million people in the Equifax breach, one of the most damaging data breaches in history. The flaw resided in the Jakarta Multipart parser: an attacker could craft a malicious Content-Type HTTP header that triggered improper exception handling in the parser, resulting in arbitrary command execution on the server under the privileges of the web server process. No authentication was required. Exploits were publicly available within days of disclosure, and active exploitation in the wild began immediately. A patch was released on March 7, 2017. Equifax’s failure to apply it left their systems exposed for 144 days, long enough for attackers to exfiltrate Social Security numbers, birth dates, and driver’s license numbers across an extended campaign. The breach resulted in a $700 million settlement, congressional testimony, and became the definitive case study in what unpatched Struts exposure actually costs. The fix was available. The window between patch availability and application is what determined the outcome.

CVE-2023-50164 (NVD CVSS 3.1: 9.8 Critical) demonstrated that Struts’ critical RCE exposure did not end with the 2017 generation of vulnerabilities. This flaw resided in the framework’s file upload logic: an attacker could manipulate file upload parameters to enable path traversal, then upload a malicious file to a location accessible to the web server – enabling remote code execution. The CVSS vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H indicates no authentication required, no user interaction, network-accessible, and full compromise of confidentiality, integrity, and availability. Proof-of-concept exploits were published within days of the December 2023 disclosure. Affected versions spanned the full Struts 2 history from 2.0.0 through 2.5.32 and 6.0.0 through 6.3.0. Struts 2.5.33 received a patch – but Struts 2.5.33 is the final Struts 2.5.x release, meaning the branch is now EOL. Any CVE disclosed against Struts 2.5.33 going forward will not receive a community fix.

CVE-2024-53677 (NVD CVSS 3.1: 9.8 Critical) is the most direct illustration of what Apache Struts EOL status means in practice today. Disclosed in December 2024, this critical path traversal vulnerability in the Struts file upload mechanism affects every version of Struts from 2.0.0 through 6.3.0.2 – including Struts 2.5.33, the final EOL release. The attack vector is identical in character to CVE-2023-50164: an attacker manipulates file upload parameters to traverse to an unintended server path and upload a malicious file, achieving remote code execution. The fix requires upgrading to Struts 6.4.0 and migrating to the new Action File Upload interceptor. Struts 2.5.33, as an EOL branch, received no patch. Any organization still running Struts 2.5.x is permanently exposed to this critical RCE vulnerability with no official remediation path available – exactly the Apache Struts EOL risk scenario this article addresses.

These are precisely the class of vulnerability – unauthenticated network-accessible RCE in production web application infrastructure – that becomes a permanently unresolved exposure on EOL releases. The Equifax case established that this is not a risk that organizations can manage through monitoring or detection alone. The only durable remediation is a patched version.

The Hidden Risk: Struts’ Dependency Tree

The vulnerability surface of a Struts deployment is not limited to the framework binary itself. Struts ships with a substantial dependency footprint that carries its own security exposure – and when Struts reaches end of life, the coordinated patching of those dependencies in the context of that Struts version ends as well.

The struts2-core module pulls in OGNL (the Object-Graph Navigation Language library) as a direct runtime dependency – and OGNL has its own CVE history stemming from its role as the primary expression evaluation engine that has been exploited in numerous Struts vulnerabilities. FreeMarker is included for template rendering. Apache Commons FileUpload handles multipart form data and was directly implicated in CVE-2017-5638. Apache Commons BeanUtils, Commons Collections, Commons IO, and Commons Lang are all runtime dependencies. Log4j2 is included for logging – a library whose own critical vulnerability history (Log4Shell, CVE-2021-44228) generated its own wave of emergency patches across the Java ecosystem. Jackson Databind handles JSON processing in plugins. The Spring framework integration brings in spring-core, spring-beans, spring-context, spring-web, and Spring AOP when the Spring plugin is used. Hibernate Validator is pulled in for bean validation.

Each of these dependencies carries its own upstream CVE stream. When a Struts branch goes EOL, the community stops issuing coordinated updates for all of these dependencies in the context of that Struts release. Vulnerability scanners running against EOL Struts deployments will generate findings across the dependency tree that have no official fix available for that version, leaving security teams with a growing list of unresolvable scan results.

The struts2-core dependency tree spans more than 20 direct and transitive dependencies when common plugins are included. Each of those carries its own transitive tree. The practical patching surface of a production Struts 2.5.x deployment with a typical plugin set is substantially larger than the framework binary alone, and every component in that tree stops receiving coordinated coverage when the parent Struts branch goes EOL.

Options for Staying Secure and Compliant

Organizations running Apache Struts EOL versions have three paths forward. Two involve significant engineering effort, operational risk, and extended timelines. The third – TuxCare’s Endless Lifecycle Support closes the security gap immediately while your teams plan the migration properly.

Option 1: Migrate to a Current Struts Version

The long-term answer is to migrate the application to a currently supported Struts version. The actively supported releases are Struts 6.x and Struts 7.x, with 7.1.1 the current latest release as of October 2025.

The practical reality, particularly for large applications built on Struts 2.5.x, is that this is not a version bump. It is a migration involving coordinated changes across the application codebase, configuration, and runtime environment. Struts 6.0 requires Java 8 at a minimum, and Servlet API 3.1 – organizations running older Java environments must upgrade the runtime before the framework migration can proceed. All Struts 2.3 configuration constants were removed in 6.0; any application using deprecated constants must update to their replacements. The XWork package namespace was reorganized, requiring import updates across Action classes. Static method access via OGNL expressions, a pattern used throughout many Struts 2.x applications, was removed entirely in 6.0 and must be replaced with Action instance method wrappers. OGNL expression length is limited to 256 characters by default, breaking longer expressions that may be scattered across FreeMarker templates and JSPs.

 

Migrating to Struts 7.x adds substantially more requirements, and two of them are massive efforts in their own right before a single line of Struts code is touched. First, Struts 7.x requires Java 17 as the minimum runtime. For organizations still running Java 8 or Java 11, which is common in large enterprise Struts deployments, this means planning and executing a full JVM upgrade across every environment: development, CI, staging, and production. Second, Struts 7.x requires Jakarta EE, which means every single `javax.*` import throughout the entire codebase must be updated to its corresponding `jakarta.*` equivalent. This javax-to-jakarta namespace migration touches `javax.servlet.*`, `javax.annotation.*`, `javax.persistence.*`, and every other `javax.*` package wherever it appears across Action classes, configuration files, custom interceptors, JSPs, and any third-party libraries in the dependency tree that have not yet published Jakarta EE-compatible releases. In large enterprise codebases, this namespace migration alone can span thousands of import statements across hundreds of files and requires end-to-end validation at every layer of the application stack. Only after those two prerequisites are addressed does the Struts-specific migration work begin: every Action class setter that accepts request parameters must be explicitly annotated with `@StrutsParameter`, a change that can affect hundreds of setters in a mature application. Namespace mapping defaults changed to require exact matches, potentially breaking links in existing templates. The previous File Upload Interceptor was removed entirely and replaced with the Action File Upload Interceptor, requiring configuration and code changes in applications that handle file uploads. For applications with significant Struts investment, which is most applications for which the migration question is meaningful, a properly planned and tested migration to Struts 7.x is measured in months, not weeks.

Option 2: Migrate to a Different Web Framework

Some organizations treat an Apache Struts EOL event as a trigger to evaluate alternative Java web frameworks: Spring MVC, Jakarta EE with Faces, Micronaut, Quarkus, or others. The architectural argument has merit in some contexts, particularly where modern REST-first architectures would better serve the application’s current requirements, or where cloud-native deployment models would benefit from a lighter framework.

A full framework migration is far more expensive than a Struts version upgrade. Action classes, JSP templates, FreeMarker views, Tiles layouts, validation configurations, interceptor stacks, and struts.xml mappings all require replacement or significant rework. The programming model is different, the deployment model is different, and EOL Struts versions are still running in production throughout the entire evaluation, planning, and migration process. This is a strategic infrastructure decision that deserves its own carefully planned timeline, not one forced by an EOL date arriving ahead of schedule.

Option 3: TuxCare Extended Lifecycle Support: The Recommended Path

This is the option that solves the immediate problem without creating new ones. TuxCare’s Endless Lifecycle Support for Struts means you continue running your current Struts version in production while receiving continued security patch coverage for the framework and its dependency tree delivered through your existing Maven or Gradle toolchain, with no forced migration required.

The security gap closes immediately. Your compliance posture is maintained. Your teams are free to plan the proper migration on a timeline that makes operational sense – including the extended runway needed to annotate Action classes for Struts 7.x parameter injection, update OGNL expression patterns throughout templates, and validate behavior across the full application endpoint set. No forced migration under deadline pressure, no compliance emergency, no behavioral regressions in production web applications that serve live users.

The Risks of Rushing a Struts Migration

When an EOL status registers on a security dashboard and a compliance team starts asking questions, the pressure to act immediately is real. Understanding what a rushed Struts migration actually entails is as important as understanding the exposure itself.

What a Struts Migration Actually Involves

A proper Struts migration – especially from 2.5.x to 6.x or 7.x – is a multi-phase application project, not a dependency version bump. It requires auditing the full codebase for deprecated APIs and removed features, updating the Java runtime if the current version falls below the Struts 6.x minimum, updating Servlet API references and deployment descriptor configurations, replacing deprecated configuration constants throughout struts.xml, updating all Action class imports affected by the XWork package reorganization, and rewriting OGNL expressions that rely on static method access or exceed the new 256-character limit.

Code Adaptation: Every Action class setter that accepts form or request parameters must be annotated with @StrutsParameter in Struts 7.x. In a large application with dozens or hundreds of Action classes, this is a systematic codebase change that requires thorough review to avoid inadvertently omitting injection points – which would cause silent failures in form submission handling.

Compatibility Verification: Every JSP, FreeMarker template, and Velocity template in the application needs to be reviewed for OGNL expressions that use static method access, exceed length limits, or reference deprecated tag libraries. Template rendering behavior changes – including FreeMarker auto-escaping defaults – can introduce subtle output differences that surface in end-to-end testing.

Toolchain Adaptation: Build configurations, CI/CD pipelines, and deployment descriptors that reference Struts-specific plugins, DTD declarations, and configuration constants need to be reviewed and updated. The Tiles plugin underwent changes across versions; Velocity support was moved into a dedicated plugin. Any plugin dependency that was dropped in the target version must be replaced or removed from the build.

Testing Overhead: Comprehensive end-to-end testing across the full application – covering form submissions, file uploads, validation flows, interceptor behavior, and result rendering – cannot be skipped. Behavioral changes in the parameter injection model, namespace mapping defaults, and OGNL evaluation semantics all need to be validated under realistic request patterns before production rollout.

What Happens When a Migration Is Rushed

When teams compress this work under deadline pressure, the consequences are predictable and follow a consistent pattern.

Increased Support Load: Annotation gaps in Action classes, missed OGNL expression updates, and unverified template rendering changes surface in production as form submission failures, broken validation flows, and unexpected page rendering behavior. These generate a wave of incidents that engineering and operations teams have to absorb on top of normal workloads.

System Instability: Struts applications often underpin customer-facing workflows, such as loan applications, patient portals, and government service submissions, where behavioral regressions affect real users immediately. Subtle changes in parameter binding, in interceptor execution order, or in result rendering can cause intermittent failures that are difficult to reproduce, and that manifest under production request volumes that pre-production testing rarely matches.

Accumulating Technical Debt: Workarounds implemented under time pressure become permanent. Action classes annotated in bulk without review introduce unintended parameter injection points. OGNL expressions were refactored quickly without understanding the security implications of the new allowlist model, creating vulnerabilities that were not present before the migration. The Apache Struts EOL problem is deferred, not resolved.

Unplanned Costs: Emergency engineering hours, delayed feature releases, incident response overhead, and the opportunity cost of senior engineers debugging production web application failures instead of building new capabilities all compound quickly and in ways that are difficult to predict in advance.

The Easy Solution: TuxCare ELS for Apache Struts EOL

TuxCare provides Endless Lifecycle Support for end-of-life Struts versions. Instead of forcing a migration your teams are not ready for, you keep running your current Struts deployment with continued security patch coverage delivered through your existing Maven or Gradle build toolchain.

TuxCare has been doing this for over a decade, delivering security patches for end-of-life operating systems, runtimes, libraries, and application frameworks. They have shipped over 220,000 security patches across the open-source ecosystem. When they say they know how to keep EOL software secure at enterprise scale, that is not marketing language. They have done it at scale, consistently.

Complete Dependency Tree Coverage: TuxCare’s ELS for Struts covers the framework and its direct and transitive dependencies, including OGNL, FreeMarker, Commons FileUpload, Commons BeanUtils, Commons Collections, Log4j2, and other libraries that carry their own CVE exposure at no additional cost. Vulnerability scanners don’t respect package boundaries, and neither does TuxCare’s coverage. The entire patching surface is addressed, not just the top-level Struts artifact.

Refined, Automated Patching Process: TuxCare monitors the NVD, vendor security advisories, Apache’s own CVE list, and GitHub security feeds, all the channels where Struts and dependency vulnerabilities get disclosed. When a CVE is identified, algorithmic tools and AI-assisted automation handle backporting security fixes to the supported version, and security experts validate every patch before it ships. Every update goes through integrity, functionality, and regression testing before reaching your repositories. For full technical details, see TuxCare’s technical whitepaper on their Open Source Patching Process.

Seamless Integration: Whether you currently consume Struts via Maven or Gradle, you can switch your update source to TuxCare’s secure repository with minimal changes to your existing workflow. There is no change to your build pipeline, no change to your CI/CD workflows, and no change to how your teams work. Security updates flow through your existing toolchain automatically.

SLA-Backed Rapid Response: When new vulnerabilities are disclosed in Apache Struts EOL versions, whether in the framework itself or in its dependency tree, TuxCare delivers patches on a guaranteed timeline backed by service-level agreements. High- and critical-severity vulnerabilities (CVSS 7+) are addressed within 14 days of public disclosure. You are not waiting for a community backport that will never come for an EOL Struts version. You are getting production-ready patches on a schedule you can plan around, with 24/7 expert support for vulnerability triage and troubleshooting.

Cost-Effective Security Continuity: The cost of TuxCare ELS is a fraction of what an emergency framework migration costs when forced by a compliance deadline in engineering time, operational risk, incident response, and delayed roadmap work. Predictable security coverage, a controlled migration timeline, and no compliance emergencies are what make extended support the right enterprise strategy.

To see exactly which vulnerabilities have been addressed for EOL Struts versions, TuxCare maintains a live CVE tracker for Struts.

Don’t Let Apache Struts EOL Put Your Web Applications at Risk

Apache Struts EOL doesn’t mean your application is immediately compromised, and it doesn’t mean you need to execute an emergency migration that your teams aren’t prepared for. But this Apache Struts EOL status does mean the security coverage your web application infrastructure depended on is no longer there, and the Equifax breach established precisely what the consequences of unpatched Struts exposure look like at scale.

The organizations that handle this well are the ones that treat this EOL status as a security problem to be managed, not a deadline to react to under pressure. You can plan a deliberate migration to Struts 6.x or 7.x when it genuinely fits your team’s capacity, including the extended time needed to annotate Action classes correctly, update OGNL expression patterns throughout your template layer, and validate behavior across your full endpoint set. You can evaluate whether a broader framework migration serves a real architectural purpose. Or you can use TuxCare ELS to maintain full security and compliance while you make those decisions on your timeline, not a compliance auditor’s.

Extended support is not a workaround. It is the option that keeps your Struts applications secure, your compliance posture intact, and your engineering teams focused on building – not firefighting. If Apache Struts EOL is on your security radar right now, visit TuxCare’s Endless Lifecycle Support for Open-Source Software to see how extended support can protect your web application infrastructure for as long as you need.