Fin de vie d'Apache CXF : versions, état du support et marche à suivre

Principaux enseignements

• Les versions 3.5.x et antérieures d'Apache CXF ont atteint leur fin de vie ; aucun autre correctif de sécurité n'est prévu de la part d'Apache.
• Seules les versions 4.1.x et 4.2.x sont désormais des branches de version actives ; les versions 3.6.x et 4.0.x ont toutes deux atteint leur dernière version prévue.
• « EOL CXF » désigne les vulnérabilités CVE connues à ce jour pour lesquelles aucun correctif n'a été publié, ainsi que l'absence de correctifs Apache pour toute vulnérabilité découverte ultérieurement.
• Vous avez le choix entre passer à la version 4.x de CXF, le remplacer purement et simplement, ou recourir au support étendu pour continuer à bénéficier des correctifs en attendant.

Si vous disposez d'une pile de services Java qui fonctionne depuis l'époque de Spring XML, il y a de fortes chances qu'Apache CXF s'y trouve quelque part, gérant discrètement vos points de terminaison SOAP, une ou deux API JAX-RS, et peut-être une intégration WS-Security que personne n'a ouverte depuis des années. Et il y a de fortes chances que la version que vous utilisez ne bénéficie plus de correctifs depuis un certain temps déjà.

Toutes les versions de CXF de la série 3.5.x et antérieures ont atteint leur fin de vie, ce qui signifie que le projet Apache ne fournira plus de correctifs de sécurité.

Cet article passe en revue les versions de CXF qui ne sont plus prises en charge, ce que cela implique concrètement pour votre sécurité et votre conformité, ainsi que les trois options réalistes qui s'offrent à vous : passer à la version 4.x, remplacer CXF purement et simplement, ou vous accorder un peu de répit grâce à une extension de la prise en charge.

Apache CXF a-t-il atteint sa fin de vie ?

Apache ne publie pas de dates fixes de fin de vie (EOL) pour CXF. Dans la pratique, cela fonctionne selon un modèle glissant : les branches pour lesquelles Apache publie activement des mises à jour figurent sur la page de téléchargement du projet, et à mesure que de nouvelles versions sont mises à disposition, les anciennes sont retirées et ne bénéficient plus de correctifs. À l'heure actuelle, cette page indique que CXF 4.2.x est la branche la plus récente (basée sur JDK 17 et Jakarta EE 11), suivie de près par la branche 4.1.x (JDK 17, Jakarta EE 10). La branche 3.6.x a déjà publié ce qu’Apache qualifie explicitement de « dernière version prévue », la 3.6.11, et la branche 4.0.x a connu le même sort avec la version 4.0.11 – aucune de ces deux branches ne doit être considérée comme une source de correctifs futurs.

Tout ce qui concerne la version 3.5.x et les versions antérieures est terminé. Apache a publié sa dernière version de maintenance de la série 3.5.x (3.5.11) et est passé à autre chose : plus de rétroportages, plus de correctifs CVE, plus rien à venir. Si votre build Maven ou Gradle fixe toujours la version d’org.apache.cxf à 3.5.x ou une version antérieure, vous utilisez un logiciel en fin de vie en production en ce moment même, que cela ait été signalé ou non.

Versions d'Apache CXF arrivées en fin de vie (EOL) et état du support à prendre en compte

Contrairement à certains environnements d'exécution, Apache ne publie pas de dates officielles de fin de vie pour les versions « LTS actives » et « LTS de maintenance » de CXF. Le support dépend de la branche actuellement à jour ; le tableau ci-dessous établit donc une correspondance entre chacune d'elles et sa version de référence JDK, son espace de noms et son statut actuel sur la page de téléchargement d'Apache, plutôt que d'inventer des jalons qui n'existent pas.

Agence CXF	Référence JDK / espace de noms	État de la prise en charge d'Apache
4.2.x	JDK 17 / Jakarta EE 11 (jakarta.*)	Actuel, dernier
4.1.x	JDK 17 / Jakarta EE 10 (jakarta.*)	Actuel
4.0.x	JDK 11 / Jakarta EE 9.1 (jakarta.*)	Dernière version prévue publiée (4.0.11) ; désormais archivée
3.6.x	JDK 11 / Java EE 8 (javax.*)	Version finale prévue désormais disponible (3.6.11)
3.5.x	JDK 8 / Java EE 8 (javax.*)	Fin de vie (dernière version : 3.5.11)
3.4.x et versions antérieures	JDK 8 / javax.*	Fin de vie

Attention : La transition de javax.* vers jakarta.* se situe exactement à la frontière entre les versions 3.x et 4.x. Il ne s'agit pas d'un simple paramètre de configuration que l'on peut activer ou désactiver : c'est la principale raison pour laquelle le passage de CXF 3 à CXF 4 se transforme en un véritable projet de migration plutôt qu'en une simple mise à jour de version.

Ce que signifie la fin de vie d'Apache CXF pour votre pile de services Java

L'utilisation d'une version de CXF en fin de vie n'est pas simplement un problème de politique abstrait figurant dans un tableur quelque part. Cela a des répercussions concrètes sur trois aspects : les vulnérabilités CVE qui restent ouvertes, celles dont vous n'entendrez même jamais parler, et les bibliothèques que CXF entraîne dans son sillage.

Vulnérabilités CVE non corrigées pour lesquelles des correctifs ont été rendus publics

Les CVE sont déjà connus, et plus votre branche est ancienne, plus vous êtes concerné par ces vulnérabilités.

CVE-2022-46363 permet la liste des répertoires à distance ou l'exfiltration de code lorsque le CXFServlet est mal configuré avec les attributs « static-resources-list » et « redirect-query-check » activés simultanément. Le NVD lui attribue une note de 7,5, et les correctifs ont été intégrés dans les versions 3.5.5 et 3.4.10. CVE-2024-28752, une faille SSRF qui n'affecte que les déploiements utilisant Aegis DataBinding (et non le databinding par défaut), présente un score NVD de 9,3 et concerne les versions antérieures à 4.0.4, 3.6.3 et 3.5.8. Ces deux séries de correctifs montrent comment les rétroportages se réduisent au fil du temps : le correctif de 2022 a concerné à la fois les versions 3.4.x et 3.5.x, mais celui de 2024 s’est arrêté à la version 3.5.8 – il n’a jamais concerné les versions 3.4.x. Plus votre branche est ancienne, plus vite elle disparaît de la liste des versions corrigées.

Et il ne s'agit pas d'un problème historique. Apache a publié 14 nouveaux avis de sécurité concernant CXF rien qu'en 2026, notamment une vulnérabilité XXE dans la fonctionnalité WS-Transfer, une faille d'injection LDAP dans le référentiel XKMS LDAP, un ensemble de failles OAuth2, ainsi qu'un correctif incomplet pour un problème antérieur d'exécution de code à distance lié à JMS. Les branches actuelles intègrent ces correctifs. Ce n'est pas le cas des branches obsolètes.

C’est vraiment là le piège des logiciels dont le support a pris fin. La vulnérabilité est documentée, le correctif est public, le diff est disponible dans l’historique des commits. Les attaquants n’ont pas besoin de découvrir quoi que ce soit par eux-mêmes : ils peuvent étudier l’avis de sécurité et le correctif, puis rechercher les déploiements qui utilisent encore une version vulnérable. Le rapport DBIR 2026 de Verizon a révélé que l’exploitation des vulnérabilités est désormais le vecteur d’accès initial le plus courant, représentant 31 % des violations, contre 20 % l’année précédente – c’est la première fois en 19 ans d’existence du rapport qu’elle dépasse l’usurpation d’identifiants pour occuper la première place.

Les vulnérabilités CVE qu'Apache ne corrigera jamais pour votre branche

Le plus grand risque, c'est celui que l'on ne voit pas encore. Une fois qu'une branche arrive en fin de vie (EOL), les problèmes découverts par la suite dans ce code ne sont tout simplement plus corrigés par Apache.

Imaginons qu’une faille soit découverte l’année prochaine dans CXF et qu’elle concerne la branche 3.5.x. Elle est corrigée dans les branches 4.x actuelles, mais reste sans solution ailleurs. Vous lisez l’avis de sécurité, vérifiez votre version et vous vous rendez compte qu’il n’existe tout simplement pas de version corrigée pour votre branche. À ce stade, vous vous retrouvez face à une migration d’urgence ou à un backport fourni par le fournisseur, et aucune de ces deux solutions ne se met en place du jour au lendemain.

C'est plus ou moins cette lacune que les correctifs proposés par les éditeurs visent à combler. Le support « Endless Lifecycle » de TuxCare  continue de fournir des correctifs de sécurité pour les branches CXF que Apache a déjà abandonnées – un moyen de continuer à bénéficier de correctifs sans être contraint de procéder à une mise à niveau pour laquelle vous n’êtes pas prêt.

Si vous souhaitez consulter les informations déjà recensées concernant les versions CXF en fin de vie (EOL) et leurs dépendances, le TuxCare CVE Tracker vous permet de filtrer les vulnérabilités CXF par niveau de gravité et par statut de correction sans avoir à fouiller vous-même dans la base de données NVD.

Les dépendances transitives qui s'ajoutent

CXF ne fonctionne pas de manière isolée. Il utilise des bibliothèques dédiées à l'analyse syntaxique du XML, au streaming StAX et à la sécurité XML, et chacune d'entre elles présente son propre historique de vulnérabilités CVE dont il faut tenir compte.

Lorsque CXF est figé à une version en fin de vie (EOL), ces dépendances ont tendance à être figées en même temps. Cette vulnérabilité va au-delà de CXF lui-même : elle s'étend à toutes les anciennes versions de bibliothèques sur lesquelles la version figée s'est stabilisée. Nous avons observé le même phénomène dans Apache Camel et les déploiements d’Apache Struts ; c’est un phénomène récurrent avec les frameworks qui n’ont pas été mis à jour depuis un certain temps.

Cadres de conformité affectés par l'exécution d'Apache CXF en fin de vie (EOL)

Les auditeurs ne se soucient guère de savoir si CXF est « interne » ou « protégé par un pare-feu ». Les logiciels non pris en charge font généralement l'objet d'une constatation à part entière, car ils remettent en cause les principes de mise à jour sur lesquels reposent la plupart des cadres d'audit. C'est là que CXF en fin de vie (EOL) pose souvent problème.

PCI DSS 4.x

PCI DSS L'exigence 6.3.3 prévoit que les correctifs critiques ou de haut niveau de sécurité applicables soient installés dans un délai d'un mois à compter de leur publication, et que tous les autres correctifs applicables soient installés selon un calendrier documenté et basé sur les risques. Une version de CXF en fin de vie (EOL) pour laquelle il n’existe plus de source de correctifs rend ces deux calendriers impossibles à respecter : il n’y a plus rien à appliquer. Si un composant CXF vulnérable se trouve quelque part dans votre environnement de données des titulaires de carte, cette lacune est susceptible de donner lieu à une non-conformité à l’exigence 6.3.3. Les outils de conformité peuvent signaler cette version, mais ils ne peuvent pas appliquer de correctif à ce qu’Apache ne prend plus en charge.

SOC 2

Les critères de sécurité de la norme SOC 2 partent du principe que vous disposez d’un processus de gestion des vulnérabilités. Les logiciels pour lesquels aucune source de correctifs n’est disponible sont difficilement compatibles avec cette exigence. La question que les auditeurs finissent par poser n’est pas de savoir si vous appliquez les correctifs rapidement, mais si vous êtes en mesure de les appliquer tout court. 

FIPS et charges de travail fédérales

Si vous travaillez dans un contexte nécessitant une cryptographie validée, un cadre en fin de vie (EOL) complique l'ensemble de la chaîne. Le statut de cycle de vie de CXF n'invalide pas en soi un module validé selon la norme FIPS, mais un cadre figé peut vous contraindre à utiliser des versions de bibliothèques cryptographiques qui ne sont plus validées, sans qu'il n'y ait plus de versions en amont disponibles pour vous permettre d'évoluer.

Options après la fin de vie d'Apache CXF

Vous disposez ici de trois voies réelles, et le choix de la bonne dépend de votre capacité à absorber le risque lié à la migration dès maintenant plutôt que plus tard. Aucune d’entre elles ne consiste à « ne rien faire ». Cette option a cessé d’être envisageable le jour où votre branche a atteint sa fin de vie (EOL).

• Vous ne pouvez pas effectuer la migration ce trimestre, mais vous devez rester à jour ? Bénéficiez d'une assistance prolongée.
• Vous disposez du JDK 17 et de ressources techniques à consacrer à ce projet ? Passez à la version 4.x.
• Le CXF est peu utilisé, ou vous êtes de toute façon en train de changer de plateforme ? Remplacez-le.

Bénéficiez d'un support à vie pour Apache CXF

Une solution directe pour vous débarrasser immédiatement de ce risque, sans avoir à réécrire l'application, consiste à faire appel à un support de sécurité assuré par le fournisseur. Le service « Endless Lifecycle Support » (ELS) de TuxCare assure la mise à jour des versions d’Apache CXF en fin de vie (EOL), y compris les branches qu’Apache a complètement retirées comme la 3.5.x, avec des correctifs fournis dès la publication de nouveaux CVE. La couverture vise actuellement plus particulièrement les versions CXF 3.5.9 et 3.5.11, pour lesquelles des correctifs CVE continuent d’être publiés bien après la sortie de la dernière version 3.5.x d’Apache. Les correctifs sont distribués via des dépôts signés et hébergés par TuxCare qui s’intègrent à votre workflow Maven ou Gradle existant.

Ce que la plupart des équipes sous-estiment, c’est l’arborescence des dépendances. CXF est fourni avec des bibliothèques d’exécution pour l’analyse XML, la gestion des schémas et la sécurité, et celles-ci ont tout autant besoin de correctifs que le code de CXF lui-même. TuxCare ELS couvre à la fois les dépendances directes et transitives sans frais supplémentaires ; vous n’êtes donc pas obligé d’appliquer des correctifs au framework alors qu’une bibliothèque vulnérable située plus en profondeur dans l’arborescence reste sans correctif.

Cette approche s’avère particulièrement judicieuse lorsque la migration nécessite un travail d’ingénierie important et que vous ne pouvez pas la planifier dans l’immédiat. Vous conservez votre version actuelle, vos services SOAP et REST continuent de fonctionner sans réécriture, et vous continuez à bénéficier des correctifs de sécurité tout en planifiant la mise à niveau à votre rythme, plutôt que sous la pression d’une faille de sécurité. Il s’agit d’une solution transitoire, et non d’une fin en soi. L’objectif reste de vous mettre à jour à terme, mais selon des conditions que vous maîtrisez réellement.

Cette solution convient particulièrement bien à deux situations : d'une part, un service figé mais essentiel à l'activité, qui ne peut pas supporter une migration de javax.* vers jakarta.* cette année ; d'autre part, une base de code héritée pour laquelle personne n'a encore défini l'étendue exacte de la migration. Dans les deux cas, ELS permet de regagner la seule chose que la fin de vie (EOL) enlève : le temps.

Mise à niveau vers Apache CXF 4.x

La solution la plus judicieuse à long terme consiste à migrer vers une branche 4.x actuelle. C'est le bon choix si vous disposez des ressources techniques nécessaires et si votre environnement d'exécution peut effectivement être migré.

Le problème est double. Premièrement, CXF 4.x s’appuie sur l’espace de noms jakarta.* ; par conséquent, toutes les importations javax.ws.rs, javax.xml.ws et associées dans le code de votre application doivent être déplacées, et toute dépendance encore développée à partir des anciennes API javax.* doit faire l’objet d’une mise à niveau ou d’un remplacement compatible avec jakarta. Deuxièmement, la version de référence du JDK a changé : CXF 4.0.x utilise le JDK 11 comme version de référence, tandis que les versions 4.1.x et 4.2.x nécessitent le JDK 17. Des outils tels que l’Eclipse Transformer peuvent gérer automatiquement une grande partie de la réécriture de l’espace de noms, mais tout ce qui est lié à la réflexion ou aux chaînes de caractères dans votre configuration devra être vérifié manuellement. Considérez cela comme un projet à part entière, et non comme une simple tâche à réaliser en un après-midi.

Une mise en garde concernant la toute dernière branche : Apache précise que la version 4.2.x actuelle repose sur des versions alpha d'Undertow ; son intégration avec Undertow pourrait donc ne pas être encore stable. Si Undertow fait partie de votre pile technologique, la version 4.1.x reste pour l'instant le choix le plus sûr.

Remplacer CXF par un autre framework ou une autre approche

Si CXF ne gère qu’une petite partie de votre pile technologique, son remplacement peut en réalité demander moins d’efforts qu’une migration complète vers la version 4.x. Les équipes qui exploitent principalement des points de terminaison REST migrent parfois vers Spring MVC ou WebFlux sur Spring Boot, ou vers une implémentation JAX-RS telle que Jersey ou RESTEasy. Les utilisateurs intensifs de SOAP et WS-Security n’ont, pour être honnête, pas autant d’options de migration simples, car c’est précisément pour ce type de charge de travail que CXF a été conçu à l’origine, et c’est pourquoi ces équipes ont tendance à rester sur CXF plus longtemps qu’elles ne le souhaiteraient.

Soyez honnête avec vous-même quant à l'ampleur de la tâche avant de vous lancer dans cette aventure. Un remplacement implique de redéfinir les limites de votre service, avec tous les tests que cela implique. Si vous disposez de contrats WSDL complexes, de politiques WS-Security ou de pièces jointes MTOM, l'idée de « simplement changer de framework » sous-estime généralement de loin la charge de travail réelle.

Assurez la sécurité d'Apache CXF au-delà de la fin de vie (EOL) avec TuxCare

L'utilisation d'Apache CXF en fin de vie (EOL) représente un risque qui s'installe progressivement. Tout fonctionne parfaitement jusqu'à ce qu'une vulnérabilité CVE rendue publique ou un audit transforme la situation en urgence du jour au lendemain. Vous n'avez pas à choisir entre une migration perturbante dès maintenant et le fait de laisser tranquillement cette vulnérabilité en place.

Le support étendu permet de maintenir votre version actuelle à jour pendant que vous planifiez la mise à niveau selon votre propre calendrier, et une migration vers la version 4.x ou un changement de framework résoudra ce problème particulier lié à la fin de vie du produit dès que vous serez prêt. La seule voie qui mène toujours à une issue désastreuse est de ne rien faire. Commencez par évaluer le coût de vos différentes options, ou découvrez comment TuxCare assure la sécurité des piles open source héritées de manière plus générale sur ELS pour les logiciels open source.

FAQ