Apache CXF EOL: Versions, Support Status & What to Do Next

Key Takeaways

• Apache CXF 3.5.x and earlier are end of life, with no further security patches to expect from Apache.
• Only 4.1.x and 4.2.x are current release lines now – 3.6.x and 4.0.x have both shipped their final planned releases.
• EOL CXF means known unpatched CVEs today and no Apache fixes for anything discovered later.
• Your options are upgrading to CXF 4.x, replacing it outright, or using extended support to stay patched in the meantime.

If you’ve got a Java services stack that’s been running since the Spring XML days, odds are decent Apache CXF is in there somewhere, quietly handling your SOAP endpoints, a JAX-RS API or two, and maybe a WS-Security integration nobody’s opened in years. And there’s a fair chance the version you’re on stopped getting patches a while back.

Every CXF release in the 3.5.x line and earlier is past end of life, which means no more security fixes from the Apache project.

This post walks through which CXF versions are dead, what that actually means for your security and compliance posture, and the three realistic options you’ve got: upgrade to 4.x, replace CXF outright, or buy yourself breathing room with extended support.

Has Apache CXF Reached End of Life?

Apache doesn’t publish fixed calendar EOL dates for CXF. In practice it works like a rolling model: the branches Apache is actively releasing sit on the project’s download page, and as new lines ship, older ones drop off and stop getting fixes. Right now that page lists CXF 4.2.x as the latest branch (JDK 17 baseline, Jakarta EE 11), with 4.1.x right behind it (JDK 17, Jakarta EE 10). The 3.6.x line has already shipped what Apache explicitly calls its last planned release, 3.6.11, and 4.0.x closed out the same way with 4.0.11 – neither is a branch you should count on for future fixes.

Everything at 3.5.x and below is finished. Apache shipped its final 3.5.x maintenance release (3.5.11) and moved on – no backports, no CVE fixes, nothing coming. If your Maven or Gradle build still pins org.apache.cxf at 3.5.x or earlier, you’re running EOL software in production right now, whether anyone’s flagged it or not.

Apache CXF EOL Versions and Support Status to Keep in Mind

Apache doesn’t publish formal “active LTS” and “maintenance LTS” end dates for CXF the way some runtimes do. Support comes down to which branch is current, so the table below maps each one to its JDK baseline, namespace, and current status on Apache’s download page instead of inventing milestones that don’t exist.

CXF branch	JDK baseline / namespace	Apache support status
4.2.x	JDK 17 / Jakarta EE 11 (jakarta.*)	Current, latest
4.1.x	JDK 17 / Jakarta EE 10 (jakarta.*)	Current
4.0.x	JDK 11 / Jakarta EE 9.1 (jakarta.*)	Final planned release shipped (4.0.11); now archived
3.6.x	JDK 11 / Java EE 8 (javax.*)	Final planned release shipped (3.6.11)
3.5.x	JDK 8 / Java EE 8 (javax.*)	End of life (last release: 3.5.11)
3.4.x and earlier	JDK 8 / javax.*	End of life

Watch Out: The javax.* to jakarta.* split lands right at the 3.x / 4.x boundary. That’s not a config flag you can flip – it’s the single biggest reason a CXF 3 to CXF 4 jump turns into an actual migration project instead of a version bump.

What Apache CXF EOL Means for Your Java Services Stack

Running an EOL CXF version isn’t some abstract policy problem on a spreadsheet somewhere. It changes three concrete things: the CVEs that stay open, the ones you’ll never even hear about, and the libraries CXF drags along with it.

Unpatched CVEs With Publicly Documented Fixes

The CVEs are already out there, and the older your branch, the more of them apply to you.

CVE-2022-46363 allows remote directory listing or code exfiltration when the CXFServlet is misconfigured with the static-resources-list and redirect-query-check attributes together. NVD scores it 7.5, and the fixes landed in 3.5.5 and 3.4.10. CVE-2024-28752, an SSRF flaw that only affects deployments using the Aegis DataBinding (not the default databinding), carries an NVD score of 9.3 and affects versions before 4.0.4, 3.6.3, and 3.5.8. Those two patch floors show how the backports narrow over time: the 2022 fix reached both 3.4.x and 3.5.x, but the 2024 fix stopped at 3.5.8 – it never reached 3.4.x at all. The further back your branch sits, the sooner it disappears from the fixed-versions list.

And this isn’t a historical problem. Apache has published 14 new CXF advisories in 2026 alone, including an XXE vulnerability in the WS-Transfer functionality, an LDAP injection flaw in the XKMS LDAP repository, a cluster of OAuth2 flaws, and an incomplete fix for an earlier JMS-related remote code execution issue. Current branches pick those fixes up. Retired branches don’t.

That’s really the trap with unsupported software. The vulnerability is documented, the patch is public, the diff is sitting right there in the commit history. Attackers don’t have to discover anything themselves – they can study the advisory and the patch, then go looking for deployments still running a vulnerable release. The 2026 Verizon DBIR found that vulnerability exploitation is now the single most common initial access vector, accounting for 31% of breaches, up from 20% the year before – the first time in the report’s 19-year history it has overtaken credential abuse for the top spot.

The CVEs Apache Will Never Patch for Your Branch

The bigger risk is the one you can’t see yet. Once a branch goes EOL, anything discovered in that code afterward just doesn’t get fixed by Apache.

Say a flaw turns up in CXF next year that touches the 3.5.x line. It gets patched in the current 4.x branches and quietly stays open everywhere else. You read the advisory, check your version, and realize there’s no patched release for your branch at all. At that point you’re looking at an emergency migration or a vendor backport, and neither happens overnight.

This is more or less the gap vendor-backed patching exists to fill. TuxCare’s Endless Lifecycle Support  keeps producing security fixes for CXF branches Apache has already walked away from – a way to keep receiving fixes without forcing an upgrade you’re not ready for.

If you want to see what’s already being tracked against EOL CXF versions and their dependencies, the TuxCare CVE Tracker lets you filter CXF vulnerabilities by severity and fix status without having to dig through NVD yourself.

The Transitive Dependencies Riding Along

CXF doesn’t run in isolation. It pulls in libraries for XML parsing, StAX streaming, and XML security, and each of those has its own CVE history to worry about.

When CXF is frozen at an EOL version, those dependencies tend to freeze right along with it. The exposure runs deeper than CXF itself – it extends to whatever older library versions the frozen build has settled on. We’ve seen the same pattern in Apache Camel and Apache Struts deployments too; it’s a recurring theme with frameworks that haven’t been touched in a while.

Compliance Frameworks Impacted by Running EOL Apache CXF

Auditors don’t really care that CXF is “internal” or “behind a firewall.” Unsupported software tends to surface as a finding in its own right, because it breaks the patching assumptions most frameworks are built on. Here’s where EOL CXF tends to trip people up.

PCI DSS 4.x

PCI DSS Requirement 6.3.3 expects applicable critical or high-security patches installed within one month of release, with all other applicable patches installed on a documented, risk-based timeline. An EOL CXF version with no patch source makes both timelines unmeetable – there’s nothing left to apply. If a vulnerable CXF component sits anywhere in your cardholder data environment, that gap is the kind that turns into a Requirement 6.3.3 finding. Compliance tooling can flag the version for you, but it can’t patch what Apache no longer supports.

SOC 2

SOC 2’s security criteria assume you’ve got a working vulnerability management process. Software with no available patch source is hard to square with that. The question auditors end up asking isn’t whether you patch fast – it’s whether you can patch at all. 

FIPS and Federal Workloads

If you’re working in a context that requires validated cryptography, an EOL framework complicates the whole chain. CXF’s lifecycle status doesn’t invalidate a FIPS-validated module on its own, but a frozen framework can pin you to crypto library versions that have fallen out of validated status, with no upstream releases left to move you forward.

Options After Apache CXF End of Life

You’ve got three real paths here, and which one’s right depends on how much migration risk you can absorb right now versus later. None of them is “do nothing.” That stopped being a real option the day your branch went EOL.

• Can’t migrate this quarter but need to stay patched? Extended support.
• Have JDK 17 and engineering time to spend? Upgrade to 4.x.
• CXF is lightly used, or you’re re-platforming anyway? Replace it.

Use Endless Lifecycle Support for Apache CXF

A direct way to get the immediate risk off your plate, without rewriting the application, is vendor-backed security support. TuxCare’s Endless Lifecycle Support (ELS) keeps EOL Apache CXF patched, including branches Apache has fully retired like 3.5.x, with fixes shipped as new CVEs come out. Coverage currently targets CXF 3.5.9 and 3.5.11 specifically, with CVE patches still going out for both long after Apache’s final 3.5.x release. Fixes are distributed through signed, TuxCare-hosted repositories that integrate with the Maven or Gradle workflow you already have.

What most teams underestimate is the dependency tree. CXF ships with runtime libraries for XML parsing, schema handling, and security, and those need patching just as much as CXF’s own code does. TuxCare ELS covers both direct and transitive dependencies at no extra cost, so you’re not left patching the framework while a vulnerable library deeper in the tree stays unpatched.

This path makes the most sense when the migration is heavy engineering work and you can’t schedule it right now. You stay on your current version, your SOAP and REST services keep running without a rewrite, and you keep getting security fixes while you plan the upgrade on your own clock instead of under breach pressure. It’s a bridge, not the destination. The goal is still to get current eventually, just on terms you actually control.

It fits two situations especially well: a frozen but business-critical service that can’t absorb a javax.*-to-jakarta.* migration this year, and an inherited codebase where nobody’s even fully scoped the migration yet. In both cases, ELS buys back the one thing going EOL takes away: time.

Upgrade to Apache CXF 4.x

The clean long-term answer is getting onto a current 4.x branch. This is the right call if you’ve got the engineering bandwidth and your runtime can actually move.

The catch is twofold. First, CXF 4.x runs on the jakarta.* namespace, so every javax.ws.rs, javax.xml.ws, and related import in your application code has to move over, and any dependency still built against the old javax.* APIs needs a jakarta-compatible upgrade or replacement. Second, the JDK baseline jumped: CXF 4.0.x has a JDK 11 baseline, while 4.1.x and 4.2.x require JDK 17. Tools like the Eclipse Transformer can handle a good chunk of the namespace rewrite automatically, but anything reflective or string-based in your config is going to need a manual look. Treat it as a project, not an afternoon.

One caveat on the newest branch: Apache notes that the current 4.2.x release depends on alpha builds of Undertow, so its Undertow integration may not be stable yet. If Undertow is in your stack, 4.1.x is the safer landing spot for now.

Replace CXF With an Alternative Framework or Approach

If CXF is only handling a thin slice of your stack, replacing it can actually be less work than a full 4.x migration. Teams that are mostly running REST endpoints sometimes move to Spring MVC or WebFlux on Spring Boot, or to a JAX-RS implementation like Jersey or RESTEasy. Heavy SOAP and WS-Security users don’t have as many clean exits, honestly, since that’s precisely the workload CXF was built for in the first place, and it’s why those teams tend to stay on CXF longer than they’d like.

Be honest with yourself about the lift before you commit to this. A replacement is a rewrite of your service boundary, with all the testing that comes with it. If you’ve got extensive WSDL contracts, WS-Security policies, or MTOM attachments in the mix, “just swap the framework” usually undersells the actual work by a wide margin.

Secure Apache CXF Beyond EOL with TuxCare

Running EOL Apache CXF is a slow-burn risk. It works fine right up until a public CVE or an audit turns it into an emergency overnight. You don’t have to choose between a disruptive migration right now and quietly sitting on the exposure.

Extended support keeps your current version patched while you plan the upgrade on your own schedule, and a 4.x migration or a framework swap closes out this particular EOL problem whenever you’re ready. The one path that always ends badly is leaving it alone. Start by pricing out your options, or take a look at how TuxCare keeps legacy open-source stacks secure more broadly at ELS for Open Source Software.

FAQs