Fin de la vida útil de Apache CXF: versiones, estado del soporte técnico y qué hacer a continuación

Principales conclusiones

• Apache CXF 3.5.x y versiones anteriores han llegado al final de su ciclo de vida, por lo que no cabe esperar más parches de seguridad por parte de Apache.
• En la actualidad, las únicas líneas de versiones activas son las 4.1.x y las 4.2.x; tanto la 3.6.x como la 4.0.x ya han lanzado sus últimas versiones previstas.
• «EOL CXF» se refiere a las vulnerabilidades CVE conocidas a día de hoy para las que no hay parches, y a que Apache no ofrecerá correcciones para ninguna vulnerabilidad que se descubra posteriormente.
• Las opciones que tienes son actualizar a CXF 4.x, sustituirlo por completo o recurrir al soporte ampliado para seguir recibiendo parches mientras tanto.

Si tienes una pila de servicios Java que lleva funcionando desde los tiempos de Spring XML, es bastante probable que Apache CXF esté ahí en alguna parte, gestionando discretamente tus puntos finales SOAP, una o dos API JAX-RS y, tal vez, una integración de WS-Security que nadie ha abierto en años. Y hay muchas posibilidades de que la versión que utilizas haya dejado de recibir parches hace ya un tiempo.

Todas las versiones de CXF de la línea 3.5.x y anteriores han superado su fin de vida útil, lo que significa que el proyecto Apache ya no ofrece correcciones de seguridad.

En esta entrada se explica qué versiones de CXF han dejado de recibir soporte, qué implica esto realmente para tu nivel de seguridad y cumplimiento normativo, y las tres opciones viables que tienes: actualizar a la versión 4.x, sustituir CXF por completo o ganar tiempo con el soporte ampliado.

¿Ha llegado Apache CXF al final de su ciclo de vida?

Apache no publica fechas fijas de fin de vida útil (EOL) para CXF. En la práctica, funciona como un modelo continuo: las ramas que Apache lanza activamente aparecen en la página de descargas del proyecto y, a medida que se publican nuevas versiones, las más antiguas desaparecen y dejan de recibir correcciones. En este momento, esa página muestra CXF 4.2.x como la rama más reciente (basada en JDK 17, Jakarta EE 11), seguida de cerca por la 4.1.x (JDK 17, Jakarta EE 10). La línea 3.6.x ya ha lanzado lo que Apache denomina explícitamente su última versión prevista, la 3.6.11, y la 4.0.x se cerró de la misma manera con la 4.0.11; ninguna de estas ramas es una opción en la que debas confiar para futuras correcciones.

Todo lo relacionado con la versión 3.5.x y anteriores ha llegado a su fin. Apache lanzó su última versión de mantenimiento de la serie 3.5.x (3.5.11) y ha pasado página: no habrá adaptaciones a versiones anteriores, ni correcciones de CVE, ni nada más. Si tu compilación con Maven o Gradle sigue fijando org.apache.cxf en la versión 3.5.x o anterior, estás ejecutando software al final de su ciclo de vida en producción en este mismo momento, independientemente de que alguien lo haya señalado o no.

Versiones de Apache CXF con fin de vida útil (EOL) y estado del soporte técnico que hay que tener en cuenta

Apache no publica fechas oficiales de finalización para las versiones «LTS activas» y «LTS de mantenimiento» de CXF, como hacen algunos entornos de ejecución. El soporte depende de cuál sea la rama actual; por ello, la tabla que figura a continuación asigna cada una de ellas a su versión de referencia del JDK, su espacio de nombres y su estado actual en la página de descargas de Apache, en lugar de inventar hitos que no existen.

Sucursal de CXF	Línea base del JDK / espacio de nombres	Estado de la asistencia técnica de Apache
4.2.x	JDK 17 / Jakarta EE 11 (jakarta.*)	Actual, más reciente
4.1.x	JDK 17 / Jakarta EE 10 (jakarta.*)	Actual
4.0.x	JDK 11 / Jakarta EE 9.1 (jakarta.*)	Se ha publicado la última versión prevista (4.0.11); ahora está archivada
3.6.x	JDK 11 / Java EE 8 (javax.*)	Se ha lanzado la última versión prevista (3.6.11)
3.5.x	JDK 8 / Java EE 8 (javax.*)	Fin de vida útil (última versión: 3.5.11)
3.4.x y versiones anteriores	JDK 8 / javax.*	Fin de la vida

Atención: La división entre javax.* y jakarta.* se sitúa justo en la frontera entre las versiones 3.x y 4.x. No se trata de un indicador de configuración que se pueda activar o desactivar: es la razón principal por la que el salto de CXF 3 a CXF 4 se convierte en un auténtico proyecto de migración en lugar de una simple actualización de versión.

Qué supone el fin de vida útil (EOL) de Apache CXF para tu pila de servicios Java

Utilizar una versión de CXF que ha llegado al final de su vida útil (EOL) no es un problema abstracto de política que figure en alguna hoja de cálculo. Esto afecta a tres aspectos concretos: las vulnerabilidades CVE que permanecen sin resolver, aquellas de las que ni siquiera llegarás a oír hablar y las bibliotecas que CXF arrastra consigo.

Vulnerabilidades CVE sin parchear con soluciones documentadas públicamente

Las vulnerabilidades CVE ya están ahí fuera, y cuanto más antigua sea tu rama, más te afectarán.

CVE-2022-46363 permite la visualización remota de directorios o la exfiltración de código cuando CXFServlet está mal configurado con los atributos «static-resources-list» y «redirect-query-check» activados simultáneamente. El NVD le otorga una puntuación de 7,5, y las correcciones se han incorporado en las versiones 3.5.5 y 3.4.10. CVE-2024-28752, una vulnerabilidad SSRF que solo afecta a las implementaciones que utilizan Aegis DataBinding (no el enlace de datos predeterminado), tiene una puntuación NVD de 9,3 y afecta a las versiones anteriores a la 4.0.4, la 3.6.3 y la 3.5.8. Esas dos series de parches muestran cómo se van reduciendo los retroportes con el tiempo: la corrección de 2022 llegó tanto a la 3.4.x como a la 3.5.x, pero la de 2024 se detuvo en la 3.5.8 —ni siquiera llegó a la 3.4.x—. Cuanto más antigua sea tu rama, antes desaparecerá de la lista de versiones corregidas.

Y esto no es un problema histórico. Apache ha publicado 14 nuevos avisos de seguridad sobre CXF solo en 2026, entre los que se incluyen una vulnerabilidad XXE en la funcionalidad WS-Transfer, un fallo de inyección LDAP en el repositorio XKMS LDAP, un conjunto de fallos en OAuth2 y una corrección incompleta para un problema anterior de ejecución remota de código relacionado con JMS. Las ramas actuales incorporan esas correcciones. Las ramas retiradas, no.

Esa es, en realidad, la trampa del software sin soporte técnico. La vulnerabilidad está documentada, el parche es público y el cambio está ahí mismo, en el historial de confirmaciones. Los atacantes no tienen que descubrir nada por sí mismos: pueden estudiar el aviso y el parche y, a continuación, buscar las instalaciones que aún ejecutan una versión vulnerable. El DBIR de Verizon de 2026 reveló que la explotación de vulnerabilidades es ahora el vector de acceso inicial más común, representando el 31 % de las brechas de seguridad, frente al 20 % del año anterior; es la primera vez en los 19 años de historia del informe que supera al uso indebido de credenciales en el primer puesto.

Las vulnerabilidades CVE que Apache nunca corregirá en tu rama

El mayor riesgo es aquel que aún no se ve. Una vez que una rama llega al final de su vida útil (EOL), cualquier problema que se detecte posteriormente en ese código simplemente no lo corrige Apache.

Imaginemos que el año que viene se detecta un fallo en CXF que afecta a la línea 3.5.x. Se corrige en las ramas actuales de la versión 4.x, pero sigue sin solucionarse en el resto de versiones. Lees el aviso, compruebas tu versión y te das cuenta de que no existe ninguna versión corregida para tu rama. En ese momento, te enfrentas a una migración de emergencia o a una adaptación retroactiva por parte del proveedor, y ninguna de las dos cosas se hace de la noche a la mañana.

Esta es, más o menos, la laguna que pretenden cubrir los parches respaldados por los fabricantes. El servicio «Endless Lifecycle Support» de TuxCare  sigue proporcionando correcciones de seguridad para las ramas de CXF de las que Apache ya se ha desentendido: una forma de seguir recibiendo correcciones sin tener que realizar una actualización para la que aún no estás preparado.

Si quieres ver qué se está supervisando ya en relación con las versiones de CXF que han llegado al final de su vida útil (EOL) y sus dependencias, el TuxCare CVE Tracker te permite filtrar las vulnerabilidades de CXF por gravedad y estado de la corrección sin tener que rebuscar tú mismo en la NVD.

Las dependencias transitivas que vienen de la mano

CXF no funciona de forma aislada. Utiliza bibliotecas para el análisis de XML, la transmisión StAX y la seguridad de XML, y cada una de ellas tiene su propio historial de CVE del que hay que preocuparse.

Cuando CXF se congela en una versión al final de su ciclo de vida (EOL), esas dependencias suelen congelarse junto con él. El alcance va más allá del propio CXF: se extiende a cualquier versión antigua de las bibliotecas que haya adoptado la compilación congelada. Hemos observado el mismo patrón en Apache Camel y Apache Struts ; es un tema recurrente en los marcos de trabajo que llevan tiempo sin actualizarse.

Marcos de cumplimiento afectados por la ejecución de Apache CXF al final de su ciclo de vida (EOL)

A los auditores no les importa realmente que CXF sea «interno» o esté «protegido por un cortafuegos». El software sin soporte técnico suele aparecer como un hallazgo en sí mismo, ya que incumple los supuestos sobre la aplicación de parches en los que se basan la mayoría de los marcos de trabajo. Aquí es donde CXF, al haber llegado al final de su vida útil (EOL), suele suponer un escollo para los usuarios.

PCI DSS 4.x

PCI DSS El requisito 6.3.3 exige que los parches críticos o de alta seguridad pertinentes se instalen en el plazo de un mes desde su lanzamiento, y que el resto de parches pertinentes se instalen siguiendo un calendario documentado y basado en el riesgo. Una versión de CXF al final de su ciclo de vida (EOL) sin fuente de parches hace que ambos plazos sean imposibles de cumplir: no queda nada que aplicar. Si hay un componente CXF vulnerable en cualquier parte de su entorno de datos de titulares de tarjetas, esa brecha es del tipo que da lugar a un hallazgo relacionado con el requisito 6.3.3. Las herramientas de cumplimiento pueden señalarle la versión, pero no pueden aplicar parches a lo que Apache ya no soporta.

SOC 2

Los criterios de seguridad de SOC 2 dan por hecho que dispones de un proceso de gestión de vulnerabilidades. El software para el que no hay parches disponibles es difícil de conciliar con eso. La pregunta que acaban planteando los auditores no es si aplicas los parches rápidamente, sino si puedes aplicarlos en absoluto. 

FIPS y cargas de trabajo federales

Si trabajas en un contexto que requiere criptografía validada, un marco en fin de vida útil (EOL) complica toda la cadena. El estado del ciclo de vida de CXF no invalida por sí solo un módulo validado según FIPS, pero un marco «congelado» puede obligarte a utilizar versiones de bibliotecas criptográficas que ya no cuentan con la validación, sin que queden versiones de origen que te permitan seguir avanzando.

Opciones tras el fin de la vida útil de Apache CXF

Tienes tres opciones reales, y cuál es la más adecuada depende de cuánto riesgo de migración puedas asumir ahora mismo en comparación con más adelante. Ninguna de ellas es «no hacer nada». Esa dejó de ser una opción viable el día en que tu rama llegó al final de su vida útil (EOL).

• ¿No puedes realizar la migración este trimestre, pero necesitas mantenerte al día con los parches? Soporte ampliado.
• ¿Tienes el JDK 17 y tiempo de desarrollo disponible? Actualízate a la versión 4.x.
• ¿El CXF apenas se utiliza, o de todos modos vas a cambiar de plataforma? Sustitúyelo.

Utiliza el soporte técnico de ciclo de vida ilimitado para Apache CXF

Una forma directa de eliminar el riesgo inmediato, sin necesidad de reescribir la aplicación, es contar con el soporte de seguridad respaldado por el proveedor. El servicio Endless Lifecycle Support (ELS) de TuxCare mantiene actualizadas las versiones de Apache CXF al final de su vida útil (EOL), incluidas las ramas que Apache ha retirado por completo, como la 3.5.x, con correcciones que se envían a medida que se publican nuevos CVE. Actualmente, la cobertura se centra específicamente en CXF 3.5.9 y 3.5.11, y siguen publicándose parches para CVE en ambas versiones mucho después del lanzamiento definitivo de la versión 3.5.x de Apache. Las correcciones se distribuyen a través de repositorios firmados y alojados por TuxCare que se integran con el flujo de trabajo de Maven o Gradle que ya tienes.

Lo que la mayoría de los equipos subestiman es el árbol de dependencias. CXF incluye bibliotecas de tiempo de ejecución para el análisis de XML, la gestión de esquemas y la seguridad, y estas necesitan parches tanto como el propio código de CXF. TuxCare ELS cubre tanto las dependencias directas como las transitivas sin coste adicional, por lo que no tendrás que limitarte a aplicar parches al marco de trabajo mientras una biblioteca vulnerable situada más abajo en el árbol permanece sin parchear.

Esta opción es la más adecuada cuando la migración supone un trabajo de ingeniería complejo y no es posible programarla en este momento. Te quedas con tu versión actual, tus servicios SOAP y REST siguen funcionando sin necesidad de reescribirlos, y sigues recibiendo parches de seguridad mientras planificas la actualización a tu propio ritmo, en lugar de hacerlo bajo la presión de una brecha de seguridad. Es un puente, no el destino final. El objetivo sigue siendo actualizarte con el tiempo, pero en los términos que tú mismo controles.

Se adapta especialmente bien a dos situaciones: un servicio congelado pero crítico para el negocio que no puede asumir una migración de javax.* a jakarta.* este año, y un código heredado en el que nadie ha definido aún el alcance completo de la migración. En ambos casos, ELS recupera lo único que la fin de vida útil (EOL) nos quita: tiempo.

Actualización a Apache CXF 4.x

La solución más clara a largo plazo es pasar a una rama 4.x actual. Esta es la decisión acertada si dispones de los recursos técnicos necesarios y tu entorno de ejecución puede realmente migrar.

El problema es doble. En primer lugar, CXF 4.x se ejecuta en el espacio de nombres jakarta.*, por lo que todas las importaciones de javax.ws.rs, javax.xml.ws y otras relacionadas del código de tu aplicación deben trasladarse, y cualquier dependencia que siga basándose en las antiguas API javax.* necesita una actualización o sustitución compatible con jakarta. En segundo lugar, la versión de referencia del JDK ha dado un salto: CXF 4.0.x tiene como referencia el JDK 11, mientras que las versiones 4.1.x y 4.2.x requieren el JDK 17. Herramientas como Eclipse Transformer pueden encargarse automáticamente de gran parte de la reescritura del espacio de nombres, pero cualquier elemento reflexivo o basado en cadenas de tu configuración tendrá que revisarse manualmente. Tómatelo como un proyecto, no como una tarea de una tarde.

Una advertencia sobre la rama más reciente: Apache señala que la versión actual 4.2.x depende de compilaciones alfa de Undertow, por lo que es posible que su integración con Undertow aún no sea estable. Si utilizas Undertow en tu entorno, la versión 4.1.x es la opción más segura por el momento.

Sustituir CXF por un marco o enfoque alternativo

Si CXF solo gestiona una pequeña parte de tu pila tecnológica, sustituirlo puede suponer, de hecho, menos trabajo que una migración completa a la versión 4.x. Los equipos que utilizan principalmente puntos finales REST a veces se pasan a Spring MVC o WebFlux en Spring Boot, o a una implementación de JAX-RS como Jersey o RESTEasy. Los grandes usuarios de SOAP y WS-Security no tienen tantas opciones claras para salir de CXF, la verdad, ya que esa es precisamente la carga de trabajo para la que se creó CXF en un principio, y es por eso que esos equipos tienden a quedarse con CXF más tiempo del que les gustaría.

Sé sincero contigo mismo respecto a la complejidad antes de comprometerte con esto. Una sustitución supone reescribir los límites de tu servicio, con todas las pruebas que ello conlleva. Si tienes contratos WSDL extensos, políticas de WS-Security o archivos adjuntos MTOM en la ecuación, la idea de «simplemente cambiar el marco de trabajo» suele subestimar el trabajo real en gran medida.

Protege Apache CXF tras el fin de su vida útil con TuxCare

Utilizar Apache CXF en fase de fin de vida útil (EOL) supone un riesgo que se va acumulando poco a poco. Funciona perfectamente hasta que, de la noche a la mañana, una vulnerabilidad CVE pública o una auditoría lo convierten en una emergencia. No tienes por qué elegir entre llevar a cabo una migración disruptiva ahora mismo o quedarte de brazos cruzados ante el riesgo.

El soporte ampliado mantiene tu versión actual actualizada con los parches mientras planificas la actualización según tu propio calendario, y una migración a la versión 4.x o un cambio de marco de trabajo resuelve este problema concreto de fin de vida útil (EOL) cuando estés listo. La única opción que siempre acaba mal es no hacer nada. Empieza por evaluar el coste de tus opciones, o echa un vistazo a cómo TuxCare mantiene seguras las pilas de código abierto heredadas de forma más general en ELS para software de código abierto.

Preguntas frecuentes