La faille d’authentification d’Apache Tomcat survit au correctif précédent et exige un nouveau patch

Le correctif appliqué en avril par Apache à une faille d’authentification de Tomcat par certificat était incomplet. Le 23 septembre, le projet a révélé le problème restant sous la référence CVE-2026-86248.

Dans les configurations concernées, CLIENT_CERTl’authentification par certificat peut réussir alors que certains échecs de l’Online Certificate Status Protocol (OCSP) devraient interrompre la connexion TLS. Les organisations qui utilisent le TLS mutuel (mTLS) pour leurs applications, leurs API ou leurs services internes devront peut-être appliquer un nouveau correctif aux systèmes qu’elles pensaient avoir remédiés en avril.

La faille concerne Tomcat 11.0.0-M14 à 11.0.25, 10.1.22 à 10.1.59 et 9.0.92 à 9.0.121. L’avis de sécurité d’Apache classe la CVE-2026-86248 comme modérée et désigne Tomcat 11.0.26, 10.1.60 et 9.0.122 comme versions corrigées.

Comment l’échec d’OCSP contourne le comportement de refus par défaut

CLIENT_CERTL’authentification par certificat utilise des certificats clients pour vérifier l’identité d’un utilisateur ou d’un système qui se connecte. L’OCSP peut déterminer si une autorité de certification a révoqué un certificat.

Les administrateurs peuvent configurer Tomcat afin que certains échecs OCSP interrompent la négociation TLS en définissant ocspSoftFail sur false. La documentation du connecteur d’Apache précise que des échecs tels que l’inaccessibilité du répondeur OCSP ou une erreur interne de celui-ci doivent alors empêcher l’établissement de la connexion.

La CVE-2026-86248 peut rompre ce comportement de refus par défaut lorsque l’implémentation OpenSSL de Tomcat fondée sur Foreign Function and Memory (FFM) est utilisée. La configuration concernée s’appuie sur FFM pour accéder à OpenSSL lors de la vérification de l’état des certificats.

La faille ne permet pas à un certificat falsifié, expiré ou autrement invalide de contourner automatiquement l’authentification. Les conditions concernées d’authentification par certificatCLIENT_CERT, OCSP, soft-fail et FFM doivent être réunies.

Cette vulnérabilité fait suite à la CVE-2026-34500, révélée le 9 avril. Apache avait initialement corrigé ce problème propre à FFM dans Tomcat 11.0.21, 10.1.54 et 9.0.117, mais ces versions n’avaient pas entièrement résolu le problème.

Appliquer un correctif aux versions concernées et vérifier le comportement de refus par défaut

L’utilisation d’une version concernée ne suffit pas à établir l’exposition. Pour définir les priorités de remédiation, les équipes doivent prendre en compte la configuration, l’accessibilité et l’importance des actifs, ainsi que la priorisation des vulnérabilités fondée sur le risque.

• Mettez à niveau les versions concernées. Passez à Tomcat 11.0.26, 10.1.60 ou 9.0.122. Les organisations qui gèrent de vastes environnements peuvent utiliser des outils de gestion des correctifs pour améliorer le déploiement et le suivi de la remédiation.
• Examinez les paramètres des certificats et de l’OCSP. Identifiez les écouteurs qui utilisent CLIENT_CERT, vérifiez si l’OCSP est activé, contrôlez si ocspSoftFail est false et déterminez si OpenSSL FFM est actif.
• Limitez les points d’accès mTLS sensibles. Limitez les interfaces d’administration, les API et les services internes aux réseaux nécessaires et aux sources approuvées. Une réduction de la surface d’attaque plus large peut réduire l’accessibilité superflue pendant la remédiation.
• Validez le correctif. Vérifiez qu’après la mise à niveau, les certificats révoqués et les conditions pertinentes d’échec OCSP sont bien rejetés conformément à la configuration.
• Examinez les journaux d’authentification. Analysez les échecs OCSP récurrents, les CLIENT_CERTréussites inattendues, les adresses sources inhabituelles et les accès suspects aux services protégés.
• Testez les plans de réponse aux incidents. Mettez en œuvre les procédures permettant d’identifier les systèmes concernés, d’enquêter sur les accès non autorisés fondés sur des certificats, de contenir les services exposés, de révoquer les identifiants et de rétablir les opérations.

Les organisations qui ont corrigé la CVE-2026-34500 en avril doivent réévaluer ces déploiements. Les versions de septembre remplacent les mesures de remédiation précédentes pour les configurations FFM concernées, et le comportement de validation des certificats doit être testé après la mise à niveau.

À lire également : Les contournements de l’authentification peuvent exposer davantage que l’application concernée ; les récentes attaques contre Cisco FMC montrent comment des contrôles d’accès compromis peuvent exposer des identifiants et des voies d’accès plus profondes dans les réseaux d’entreprise.