Apache CXF Versions, EOL Dates, and Latest Releases (October 2026)

Apache CXF is the JAX-WS and JAX-RS implementation underneath a large share of enterprise Java SOAP and REST services. It ships inside WildFly and JBoss EAP as the JAX-WS stack, inside Apache TomEE, and inside Apache Camel through camel-cxf, and it sits directly in the dependency tree of thousands of Spring Boot and Jakarta EE applications that expose or consume WSDL-based services. Because CXF is usually a transitive dependency buried under an application server or an integration framework, teams frequently do not know which line they are running until a scanner flags it.

That matters more in 2026 than in any previous year. The CXF project published 26 security advisories between May and August 2026, nearly nine times its total for 2025, and every one of them was fixed only in the three lines the project still maintains. Anything older, including the still widely deployed 3.5.x and 4.0.x lines, received nothing.

This page is the definitive reference for Apache CXF versions, release dates, support status, and end-of-life. It is updated as new versions ship.

The Short Version: Apache CXF Versions and Support Status

• Current release: 4.2.3, released July 30, 2026 (Jakarta EE 11, JDK 17 baseline).
• Maintained lines: 4.2.x, 4.1.x, and 3.6.x. These are the only lines that received fixes for the 2026 advisories.
• Most recent line to drop out of support: 4.0.x. Its final release was 4.0.11 on February 10, 2026, and the May 2026 advisories list 4.1.6 as the fix for 4.0 users.
• Oldest line still receiving upstream patches: 3.6.x (3.6.12, July 30, 2026). It is the last line on the javax.* namespace.
• End of life with unpatched 2026 CVEs: 3.5.x (last release 3.5.11, March 3, 2025), 4.0.x, and everything from 3.4.x back to 2.x. HeroDevs Never-Ending Support (NES) covers 3.5.x and 3.4.x.

How Apache CXF's Support Policy Works

CXF does not publish end-of-life dates. There is no LTS designation, no fixed support window, and no lifecycle table on cxf.apache.org. The project's last published roadmap still described 3.1.x as the active branch, which tells you how much to rely on it.

What the project does instead is maintain two or three fixes branches at a time and cut patch releases across all of them on the same day. A line is effectively end of life when two things happen: it disappears from the download page, and the next security advisory lists a newer line as the remediation for users on it. Both happened to 4.0.x in spring 2026. The download page now lists only 4.2.3, 4.1.8, and 3.6.12, and every advisory since May 2026 describes the affected range as "4.0.0 before 4.1.x", meaning 4.0 users are told to move to 4.1.

The practical lifecycle looks like this:

• A new minor line ships roughly every 18 months to two years, usually tied to a Jakarta EE or JDK baseline change.
• The newest line and the previous one or two lines receive synchronized patch releases, typically three to four times a year.
• When a new line ships, the oldest maintained line is usually dropped within one or two patch cycles.
• Nothing is announced. You find out from the download page and the advisory text.

The one durable rule: the project keeps 3.6.x alive as the last javax.* namespace option for applications that cannot move to Jakarta EE 9+ packages. That line has now outlived both 4.0.x and the original 3.5.x it was meant to replace.

Complete Apache CXF Version Timeline

Release dates are taken from Maven Central artifact timestamps for org.apache.cxf:cxf-core (cxf-api for 2.7). "Effective EOL" is the date of the last patch release on that line, since the project publishes no formal dates.

The 4.0.x and 3.5.x rows deserve a closer look because those are the two lines where teams are most likely to be stranded. Both received their final release before the 2026 advisory wave started, and both are explicitly listed as affected, with no fix on the line, in every 2026 advisory.

Latest Apache CXF Patch Release Per Maintained Line

All three maintained lines were last released on July 30, 2026, which is the normal CXF pattern: one release day, every branch.

4.2.3 (July 30, 2026): fixes 12 advisories disclosed August 6, 2026, including the JMS ObjectMessage deserialization RCE (CVE-2026-66909, CVSS 9.8) and the WSDL/XSD import XXE (CVE-2026-65432, CVSS 7.5). Adds default limits of 50 MB per attachment and 500 form parameters per request. Ships Undertow 2.4.2.Final; the alpha-Undertow caveat from the 4.2.0 release notes no longer applies.

4.1.8 (July 30, 2026): same 12 fixes as 4.2.3, on the Jakarta EE 10 baseline. This is the line most Spring Boot 3.x applications should be on.

3.6.12 (July 30, 2026): same 12 fixes, plus the project's note that the line "remains Jakarta EE 8.x (javax namespaces)". If you cannot move off javax.xml.ws and javax.ws.rs, this is the only upstream-supported option.

Previous 2026 release days were February 10 (4.2.0, 4.1.5, 4.0.11, 3.6.10), May 14 (4.2.1, 4.1.6, 3.6.11), and June 4 (4.2.2, 4.1.7). The February release was the last time 4.0.x was included.

The 2026 Apache CXF Advisory Wave

CXF published three advisories in all of 2025. Between May 22 and August 6, 2026 it published 26. The breakdown by component tells you where the exposure actually is:

• OAuth2 and OIDC modules (cxf-rt-rs-security-oauth2, cxf-rt-rs-security-sso-oidc): 14 advisories. Most are logic flaws in token validation, code redemption, and revocation.
• JMS transport and JCA integration: 4 advisories, including a three-stage incomplete-fix chain for JNDI injection and a separate unrestricted deserialization RCE.
• Core XML parsing and attachments (cxf-core, cxf-rt-wsdl, cxf-rt-ws-transfer): 7 advisories, mostly XXE and resource-exhaustion.
• XKMS LDAP repository: 1 advisory (LDAP injection).

Every one of these was fixed in 4.2.x, 4.1.x, and 3.6.x only. If you run 4.0.x or 3.5.x, the following table is your current unpatched exposure. Scores are CVSS 3.1 as listed on NVD as of October 1, 2026: NVD's own primary score where NVD has assigned one (five of the June batch), and the CISA ADP score otherwise. For most of the August 6 batch NVD has not yet published a primary score, and other sources differ on some entries (Red Hat rates CVE-2026-50632 at 8.8, for example), so treat the column as indicative rather than final.

Two things stand out. First, the project's own severity ratings run lower than the scores on NVD: CXF rates CVE-2026-68079 "low" while the listed score is 9.8, so expect scanner output to look worse than the advisory text. Second, the JMS JNDI issue took three attempts to close (CVE-2025-48913 in August 2025, CVE-2026-44417 in May 2026, CVE-2026-50632 in June 2026). If your 4.0 or 3.5 application uses the JMS transport with any externally influenced configuration, that chain is the one to worry about first.

Versions Reaching End of Life: What to Know

For a closer look at the two Java 8 lines, see Apache CXF 3.4 and 3.5 End of Life.

Apache CXF 4.0.x: Effective EOL February 10, 2026

4.0.x was the first Jakarta-namespace line and the one most teams landed on when they moved to Spring Boot 3 in 2023 and 2024. Its last release was 4.0.11 on February 10, 2026, cut the same day 4.2.0 shipped. It was dropped from the download page shortly after, and the May 22, 2026 advisories describe the affected range as "4.0.0 before 4.1.6".

Every CVE in the table above affects 4.0.x with no fix on the line. The recommended path is 4.1.8. For most Spring Boot 3 applications that is a version bump: both lines are Jakarta EE 10 compatible at the API level and both run on JDK 17, and the 4.1 line does not remove APIs that 4.0 applications commonly depend on. The friction is dependency alignment with the Spring Boot BOM you are on, not the CXF code itself.

Going further to 4.2.x is a bigger step: it targets Jakarta EE 11 and Spring Boot 4, moves to Jackson 3, and removes the long-deprecated org.apache.cxf.feature.LoggingFeature and the <logging> namespace handler (CXF-9116). The replacement is org.apache.cxf.ext.logging.LoggingFeature from cxf-rt-features-logging. Do 4.0 to 4.1 now; do 4.1 to 4.2 when the rest of your stack is on Spring Boot 4.

Compliance note: 4.0 users on JDK 11 need JDK 17 to move to 4.1. If the JDK upgrade is what is blocking you, see our Java EOL dates by OpenJDK vendor reference.

Apache CXF 3.5.x: Effective EOL March 3, 2025

3.5.x is the last line that runs on Java 8 and the line baked into most Spring Boot 2.x applications that expose SOAP services. Its final release was 3.5.11 on March 3, 2025. The first advisory to leave it behind was CVE-2025-48913 (CVSS 9.8, JNDI injection via untrusted JMS configuration) in August 2025, which listed 3.6.8 as the fix for everything older. Since then, all 28 advisories published after 3.5.11 shipped have treated it the same way.

The upstream exit from 3.5 is 3.6.12, which keeps the javax.* namespace but raises the JDK baseline to 11. That is a real move for Java 8 shops, and it does not help teams pinned to a Spring Boot 2.7 stack that is itself out of OSS support.

HeroDevs NES for Apache CXF covers this line. HeroDevs maintains a fork of 3.5.11 under the original org.apache.cxf Maven coordinates, so adoption is a version string change in your BOM import (3.5.11-cxf-3.5.13 as of September 29, 2026). The 3.5.13 release notes list fixes for 27 CXF advisories: CVE-2025-48913 and all 26 of the 2026 CVEs in the table above, backported to Java 8. The documented behavior changes match upstream 3.6.11 and 3.6.12 where upstream made them, so the hardening you get is the same hardening the maintained lines got.

Apache CXF 3.4.x: Effective EOL December 7, 2022

3.4.x reached its last release, 3.4.10, in December 2022, which means it missed not only the 2026 wave but the 2024 and early 2025 advisories as well: CVE-2024-28752 (SSRF via Aegis databinding, CVSS 9.3), CVE-2024-29736 (SSRF via WADL stylesheet parameter, 9.1), CVE-2024-32007 (JOSE DoS, 7.5), and CVE-2025-23184 (temp-file DoS, 5.9). Teams on 3.4 are usually also on an EOL Java and an EOL application server, and the CXF upgrade is rarely the hardest part of the migration.

NES for Apache CXF 3.4 covers this line too. It is a fork of 3.4.10, Java 8, same org.apache.cxf coordinates. The current release 3.4.10-cxf-3.4.12 (September 30, 2026) lists fixes for 30 CXF advisories: the four above, CVE-2025-48913, and 25 of the 2026 CVEs. If you are going to upgrade instead, jump directly to 3.6.12 if you must stay on javax, or to 4.1.8 if the rest of the stack can go Jakarta.

Apache CXF 3.3.x and Older

Everything from 3.3.13 (February 2022) back is long past any patch and is not covered by NES. Upgrade to 3.6.12 or 4.1.8, or to NES for CXF 3.4 or 3.5 if the application cannot absorb a minor-line change.

What Happens After Apache CXF End of Life

For CXF specifically, "after EOL" means:

Security patches stop, and the exposure is in the request path. CXF is the thing parsing inbound SOAP envelopes, WSDL imports, MTOM attachments, and OAuth2 tokens. Unlike a logging library or a build tool, every 2026 CVE class here (XXE, deserialization, JNDI injection, token validation) is reachable from the network. Twenty-six unpatched advisories on an internet-facing SOAP endpoint is not a theoretical backlog.

Dependency compatibility degrades. The maintained lines bumped WSS4J, Woodstox, Jackson, Jetty, and the HttpClient 5 series through 2025 and 2026. An EOL CXF line pins you to the versions of those libraries that it was tested against, which means CVEs in Jackson or Woodstox cannot be fixed by upgrading the dependency without risking a CXF break. The Jackson 2 to Jackson 3 split in 4.2.x is the current example.

Compliance audits flag it. PCI DSS 4.0 requirement 6.3.3, SOC 2 change-management controls, HIPAA, FedRAMP continuous monitoring, NIS2, DORA, and the EU Cyber Resilience Act all require that production software receive security updates. A SOAP gateway running cxf-core-3.5.11 with 26 known unpatched CVEs will show up in every SCA scan and every penetration test report until it is fixed.

Options for EOL Apache CXF Versions

1. Upgrade within upstream. From 4.0.x, move to 4.1.8 (same Jakarta namespace, JDK 17 required). From 3.5.x or older javax lines, move to 3.6.12 (JDK 11 required, namespace unchanged). From 3.6.x, the next step is 4.1.8 or 4.2.3, which is a javax to jakarta migration across your whole service layer, including generated JAX-WS clients, WS-Security configuration, and any JAX-RS providers. Budget it like a Spring Boot 2 to 3 migration, because for most applications it is the same migration.

2. Replace the framework. Some teams use a CXF EOL as the trigger to retire SOAP endpoints entirely or move JAX-RS workloads to Spring MVC or Quarkus RESTEasy. This is the right long-term answer for a shrinking service surface and the wrong one for a stable integration layer with external WSDL consumers who are not going to change.

3. HeroDevs Never-Ending Support for Apache CXF. NES for Apache CXF covers the 3.5.x line (fork of 3.5.11, current release 3.5.11-cxf-3.5.13, September 29, 2026) and the 3.4.x line (fork of 3.4.10, current release 3.4.10-cxf-3.4.12, September 30, 2026). Both keep the Java 8 baseline, the javax namespace, and the org.apache.cxf coordinates, and both ship from a private registry. Adoption is the registry entry plus a BOM version change:

<!-- ~/.m2/settings.xml -->
<servers>
  <server>
    <id>herodevs-nes-registry</id>
    <username>any_text_here_not_used</username>
    <password>YOUR_NES_ACCESS_TOKEN</password>
  </server>
</servers>

<!-- pom.xml: swap the BOM version, leave individual cxf-* artifacts unversioned -->
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.apache.cxf</groupId>
      <artifactId>cxf-bom</artifactId>
      <version>3.5.11-cxf-3.5.13</version> <!-- or 3.4.10-cxf-3.4.12 -->
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

<repositories>
  <repository>
    <id>herodevs-nes-registry</id>
    <url>https://registry.nes.herodevs.com/maven</url>
  </repository>
</repositories>

<!-- pom.xml: swap the BOM version, leave individual cxf-* artifacts unversioned -->
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.apache.cxf</groupId>
      <artifactId>cxf-bom</artifactId>
      <version>3.5.11-cxf-3.5.13</version> <!-- or 3.4.10-cxf-3.4.12 -->
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

<repositories>
  <repository>
    <id>herodevs-nes-registry</id>
    <url>https://registry.nes.herodevs.com/maven</url>
  </repository>
</repositories>

Check the release notes for the per-CVE fix list and the documented behavior changes before you roll it out, since several fixes (the WS-Transfer XXE hardening, the XKMS LDAP identifier validation) intentionally tighten behavior the same way upstream did.

If you are also running Spring Boot 2.7 or Spring Framework 5.3 underneath that CXF 3.5 service, NES for Spring covers the rest of the stack, and our Spring Boot versions and EOL dates reference has the timeline.

Quick Reference: Is My Apache CXF Version Supported?

To find out which line you are on, resolve the cxf-core version in your build:

# Maven
mvn dependency:tree -Dincludes=org.apache.cxf

# Gradle
gradle dependencies --configuration runtimeClasspath | grep org.apache.cxf

If CXF arrives through an application server, check the server's component matrix: WildFly, JBoss EAP, and TomEE each pin a specific CXF version per release.

Frequently Asked Questions

What is the latest version of Apache CXF?

4.2.3, released July 30, 2026. It requires JDK 17 and targets Jakarta EE 11. The latest releases on the other maintained lines are 4.1.8 (Jakarta EE 10) and 3.6.12 (javax namespace, JDK 11), both also released July 30, 2026.

Does Apache CXF have LTS versions?

No. CXF has no LTS program and publishes no end-of-life dates. The project maintains two or three lines at a time and drops the oldest when a new one ships. Right now the maintained lines are 4.2.x, 4.1.x, and 3.6.x.

Is Apache CXF 4.0 still supported?

No. The final 4.0.x release was 4.0.11 on February 10, 2026. Every security advisory since May 2026 lists 4.1.x as the fix for 4.0 users, and 4.0.x has been removed from the download page.

Is Apache CXF 3.5 still supported?

No. 3.5.11 (March 3, 2025) was the last release. The 28 advisories published since then, including CVE-2025-48913 and all 26 from 2026, list 3.6.x as the fix for 3.5 users. HeroDevs NES for Apache CXF provides patched 3.5.x builds on Java 8.

Is Apache CXF 3.4 still supported?

No. 3.4.10 (December 7, 2022) was the last upstream release, and the line has unpatched CVEs from 2024, 2025, and 2026. HeroDevs NES for Apache CXF 3.4 provides patched 3.4.x builds on Java 8, with 30 CXF advisories fixed as of 3.4.10-cxf-3.4.12.

Is Apache CXF 3.6 still supported?

Yes. 3.6.12 shipped July 30, 2026 with the same security fixes as 4.2.3 and 4.1.8. It is the last line on the javax.* namespace and requires JDK 11.

Which Apache CXF version works with Spring Boot 3?

4.1.x is the natural fit (Jakarta EE 10, JDK 17). 4.0.x also works but is end of life. 4.2.x targets Spring Boot 4 and Spring Framework 7. For Spring Boot 2.x, use 3.6.x, or 3.5.x via NES if you must stay on Java 8.

How many CVEs were disclosed in Apache CXF in 2026?

Twenty-six, published between May 22 and August 6, 2026, versus three in all of 2025. Nine carry CVSS 3.1 scores of 9.0 or higher as listed on NVD. All were fixed in 4.2.x, 4.1.x, and 3.6.x only.

Taking Action on Your Apache CXF Version

If you are on 4.1.x, 4.2.x, or 3.6.x, make sure you are on the July 30, 2026 patch releases; that is the whole job. If you are on 4.0.x, the upgrade to 4.1.8 is a contained change and should be scheduled now, not at the next quarterly release. If you are on 3.5.x or 3.4.x with a Java 8 or Spring Boot 2 dependency that is not moving this year, you are carrying 26 or more unpatched network-reachable CVEs today, and the two realistic options are a JDK 11 plus 3.6.12 upgrade or NES for Apache CXF.

Contact HeroDevs if you want help sizing either path for your stack.