CVE-2026-24734, contournement de la révocation OCSP d'Apache Tomcat

CVE-2026-24734 n'est pas le genre de faille Tomcat qui fait les gros titres. Elle ne permet pas à un attaquant non authentifié d'exécuter du code à distance. Elle ne transforme pas une requête HTTP malformée en corruption de la mémoire. Elle touche plutôt une garantie de sécurité plus silencieuse et plus fondamentale : un serveur qui s'appuie sur des certificats de clients peut-il encore faire confiance à ses propres contrôles de révocation ? L'avis d'Apache indique que lorsque Tomcat Native et le chemin OpenSSL FFM de Tomcat ont utilisé un répondeur OCSP, ils n'ont pas effectué de vérification ou de contrôle de fraîcheur sur la réponse OCSP. Le résultat est simple et dangereux dans un environnement approprié : la révocation des certificats peut être contournée. Apache a marqué le problème comme Modéré, tandis que NVD et la base de données d'avis de GitHub lui attribuent une sévérité CVSS 3.x élevée. (Google Groups)

Cette distinction est importante car il est facile de se méprendre sur le risque réel. Il ne s'agit pas d'un problème générique du type "tout Tomcat HTTPS est cassé". La documentation OCSP de Tomcat lie la vérification OCSP aux certificats des clients et à un sous-ensemble de configurations de connecteurs soutenues par OpenSSL. Dans le modèle documenté, Tomcat valide les certificats fournis par le client avec un URI de réponse OCSP dans l'extension Authority Information Access, et cette fonctionnalité est implémentée pour le chemin OpenSSL JSSE, le chemin OpenSSL FFM, et le connecteur APR/natif plutôt que l'implémentation JSSE simple décrite ailleurs dans la même documentation. En pratique, les déploiements les plus risqués sont ceux qui utilisent mTLS comme limite de contrôle d'accès pour les API B2B, les plans d'administration internes, les intégrations de partenaires, les identités d'appareils ou l'authentification privilégiée de service à service. (Apache Tomcat)

La piste de divulgation d'Apache mérite également d'être soulignée. Le problème a été signalé à l'équipe de sécurité de Tomcat le 2 novembre 2025. Les versions corrigées ont été livrées en janvier 2026 pour Tomcat Native et Tomcat 9, 10.1 et 11.0, et l'avis public a suivi le 17 février 2026. Ce calendrier est normal pour une divulgation coordonnée. Ce qui est le plus important, c'est que le traitement OCSP dans cette zone de code a continué à évoluer même après la correction initiale. En mars 2026, Apache a divulgué la CVE-2026-29145, un autre problème lié à OCSP dans lequel l'authentification du certificat client échouait parfois même lorsque l'échec progressif était désactivé. La leçon à tirer n'est pas simplement de "passer la version la moins corrigée et de continuer", mais plutôt que les voies d'application de la révocation méritent d'être améliorées. Les voies d'application de la révocation méritent d'être testées à nouveau, et non d'être cochées. (Apache Tomcat)

CVE-2026-24734 en bref

Apache et NVD identifient les gammes concernées comme suit. Pour Tomcat Native, les versions 1.3.0 à 1.3.4 et 2.0.0 à 2.0.11 sont concernées, avec des correctifs dans les versions 1.3.5 et 2.0.12. Pour Apache Tomcat, les trains concernés sont les suivants : 11.0.0-M1 à 11.0.17, 10.1.0-M7 à 10.1.51, et 9.0.83 à 9.0.114, avec des correctifs dans les versions 11.0.18, 10.1.52 et 9.0.115. NVD note également que d'anciennes gammes de Tomcat Native en fin de vie, en particulier 1.1.23 à 1.1.34 et 1.2.0 à 1.2.39, sont également affectées. La base de données consultative de GitHub associe également le problème à des gammes de paquets Java intégrés, notamment org.apache.tomcat.embed:tomcat-embed-core et org.apache.tomcat:tomcat-coyotequi rappelle utilement que tous les déploiements vulnérables ne ressemblent pas à un serveur Tomcat autonome sur une machine virtuelle. (nvd.nist.gov)

Composant	Versions concernées	Versions corrigées	Note opérationnelle
Tomcat Native 1.3.x	1.3.0 à 1.3.4	1.3.5 ou version ultérieure	Chemin OCSP dans le connecteur APR/natif
Tomcat Native 2.0.x	2.0.0 à 2.0.11	2.0.12 ou plus récent	Chemin d'accès natif soutenu par OpenSSL
Tomcat 11	11.0.0-M1 à 11.0.17	11.0.18 ou version ultérieure	Chemin d'accès OpenSSL du FFM affecté
Tomcat 10.1	10.1.0-M7 à 10.1.51	10.1.52 ou version ultérieure	Chemin d'accès OpenSSL du FFM affecté
Tomcat 9	9.0.83 à 9.0.114	9.0.115 ou plus récent	Chemin d'accès OpenSSL du FFM affecté
EOL Lignes natives	1.1.23 à 1.1.34, 1.2.0 à 1.2.39	Pas de futur supporté en place	La migration est plus sûre que l'accrochage à des branches mortes

L'histoire de la gravité est légèrement désordonnée, d'une manière qui est en fait instructive. L'avis d'Apache qualifie le problème de modéré. NVD liste un vecteur 7.5 élevé provenant de l'enrichissement de NVD et un vecteur 7.4 élevé séparé provenant de CISA-ADP. Snyk classe les enregistrements de paquets étroitement liés sous une formulation de type CWE-863, décrivant l'impact comme une autorisation incorrecte, tandis qu'Apache et NVD encadrent la faiblesse autour d'une validation incomplète et d'un traitement de la réponse OCSP. Ces différences sont moins une contradiction qu'un changement de perspective. Au niveau du code, le bogue concerne la validation incomplète de la réponse. Au niveau du système, l'impact est qu'un identifiant révoqué peut toujours être accepté et donc autoriser l'accès. (Google Groups)

Explication du contournement de la révocation OCSP par Apache Tomcat

Pour comprendre l'importance de CVE-2026-24734, il est utile de préciser ce que fait Tomcat lorsque OCSP est activé. La documentation SSL/TLS de Tomcat indique que le support OCSP existe pour vérifier l'état des certificats fournis par les clients. Elle énumère les familles de connecteurs prises en charge pour cette fonctionnalité : NIO ou NIO2 avec org.apache.tomcat.util.net.openssl.OpenSSLImplementationNIO ou NIO2 avec org.apache.tomcat.util.net.openssl.panama.OpenSSLImplementationet le connecteur HTTP APR/natif avec une version native de Tomcat compatible OCSP. La même documentation indique que l'OCSP n'est pas pris en charge si l'implémentation JSSE simple est utilisée ou si le style de configuration JSSE est utilisé. Cette définition du champ d'application est essentielle. Elle signifie que la vulnérabilité se situe dans un chemin de confiance spécifique : la validation côté serveur des certificats clients dans les configurations Tomcat soutenues par OpenSSL. (Apache Tomcat)

Dans un déploiement mTLS classique, le client présente un certificat lors de l'échange TLS. Le serveur n'a pas seulement besoin de savoir si le certificat est lié à un émetteur de confiance. Il doit également savoir si ce certificat a été révoqué depuis son émission. L'OCSP est l'un des moyens standard de répondre à cette question en temps quasi réel. Si le certificat d'un appareil est révoqué parce que l'appareil a été mis hors service, si le certificat d'un partenaire est révoqué parce que la relation a pris fin, ou si la clé privée d'un client est soupçonnée d'avoir été compromise, le service qui se fie au certificat est censé rejeter le certificat du client. Si la vérification de la révocation peut être contournée, le modèle de contrôle d'accès construit sur la base de ce certificat devient indigne de confiance. (Apache Tomcat)

C'est pourquoi l'impact est plus fort dans certains environnements que dans d'autres. Un site web public qui utilise Tomcat pour le protocole TLS ordinaire mais qui n'exige pas de certificats clients n'est pas la victime canonique. Une API partenaire qui n'admet que les détenteurs de certificats clients approuvés l'est. Il en va de même pour un plan d'opérations interne où les identités des machines sont renforcées par mTLS, un système industriel qui intègre des dispositifs par le biais de certificats, ou une passerelle où la possession d'un certificat est considérée comme la principale preuve d'appartenance à une organisation. Dans tous ces cas, la révocation n'est pas un élément cosmétique. Il s'agit d'un interrupteur d'arrêt pour les identités qui ne devraient plus être fiables. Une fois que cet interrupteur peut être contourné, l'endiguement des incidents, l'exclusion et la réponse à la compromission des clés se dégradent. (Apache Tomcat)

Il existe également une erreur conceptuelle facile à éviter. Le mot "certificat" fait penser aux navigateurs qui valident les certificats des serveurs. Ce n'est pas le centre de gravité ici. La documentation de la fonctionnalité OCSP de Tomcat est explicite sur le fait que le mécanisme valide les certificats fournis par le client. Cela signifie que la vulnérabilité concerne les personnes qui y ont accès, et non le certificat de serveur accepté par le navigateur. En d'autres termes, CVE-2026-24734 est une défaillance des limites d'authentification et d'autorisation dans les déploiements de serveurs compatibles avec mTLS, et non une rupture générique de la confidentialité HTTPS pour des visiteurs arbitraires. (Apache Tomcat)

Pourquoi il est facile de se tromper dans la validation OCSP

OCSP semble simple si on le réduit à une étiquette d'état. Demandez si un certificat est bon, révoqué ou inconnu. Lisez la réponse. Passez à autre chose. Ce modèle mental est suffisamment incomplet pour être dangereux. Le RFC 6960 définit l'OCSP comme un protocole permettant de déterminer l'état actuel d'un certificat numérique sans nécessiter de LCR complètes. La même RFC précise la sémantique de l'OCSP, qui est un protocole permettant de déterminer l'état actuel d'un certificat numérique sans nécessiter de LCR. cetteMise à jour, prochaine mise à jour, produitAuet heure de révocation. Il précise également que l'extension nonce lie cryptographiquement une requête et une réponse afin d'empêcher les attaques par rejeu. Ces détails ne sont pas facultatifs. Ils font partie de ce qui rend une réponse OCSP digne de confiance plutôt que simplement bien formée. (datatracker.ietf.org)

RFC 6960 dit cetteMise à jour est le moment le plus récent où le répondeur sait que l'état indiqué était correct, et prochaine mise à jour est le moment auquel ou avant lequel de nouvelles informations seront disponibles. Il ajoute une règle subtile mais importante : les réponses dont les prochaine mise à jour est antérieure à l'heure locale doit être considérée comme non fiable, et les réponses dont l'heure est antérieure à l'heure locale doivent être considérées comme non fiables. cetteMise à jour est postérieure à l'heure locale doit également être considérée comme non fiable. Le RFC note également que si prochaine mise à jour n'est pas défini, le répondant indique effectivement que des informations de révocation plus récentes peuvent être disponibles en permanence. Cela signifie qu'une implémentation ne peut pas réduire en toute sécurité le traitement OCSP à "le champ d'état a dit bon, donc j'ai fini". La sémantique temporelle fait partie de la décision de confiance. (datatracker.ietf.org)

La documentation d'OpenSSL fait la même remarque en termes de bibliothèque plutôt qu'en termes de protocole. La documentation d'OpenSSL précise le même point en termes de bibliothèque plutôt que de protocole. OCSP_check_validity() La documentation indique que la fonction vérifie ceupd et nextupdLa page de manuel d'OpenSSL explique également que les applications récupèrent généralement l'état du certificat et vérifient ensuite sa validité. La page de manuel d'OpenSSL explique également que les applications récupèrent généralement l'état du certificat et vérifient ensuite sa validité. prochaine mise à jour est absente, une réponse ancienne pourrait sembler valide, à moins que des limites d'âge maximales ne soient appliquées. OpenSSL documente également OCSP_basic_verify() comme le mécanisme qui vérifie que la réponse de base est correctement signée et que le certificat du signataire peut être validé. Là encore, le schéma est clair : une réponse OCSP digne de confiance nécessite au moins la consultation de l'état, la vérification de la signature, la validation du signataire et la logique de fraîcheur. (docs.openssl.org)

Le nonce est important pour une autre raison. Le RFC 6960 indique que le nonce lie la demande et la réponse pour empêcher le rejeu. Sans cette liaison, une réponse qui est techniquement analysable peut toujours être la mauvaise réponse pour la transaction en cours. Dans les environnements où l'état de révocation change rapidement ou dans lesquels les attaquants peuvent rejouer des éléments observés précédemment, il ne s'agit pas d'un problème théorique. La fraîcheur sans liaison demande-réponse est plus faible que ne le supposent de nombreuses équipes. La vérification des signatures sans fraîcheur est également plus faible que ce que les équipes supposent. Les trois propriétés doivent s'aligner. (datatracker.ietf.org)

Cette vision plus large explique pourquoi CVE-2026-24734 n'est pas "juste un cas limite OCSP". Il s'agit d'un exemple concret d'un piège récurrent dans la mise en œuvre des systèmes d'identité. Les ingénieurs sont souvent attentifs à la validation de la chaîne et à l'analyse des certificats de base, puis considèrent la révocation comme une étape supplémentaire. En réalité, la révocation fait partie de la décision d'identité elle-même. Un certificat dont la chaîne est correcte mais qui est révoqué n'est pas un moindre succès. C'est un échec. Toute lacune dans la mise en œuvre qui accepte un tel certificat affaiblit la signification de toute la politique mTLS qui l'entoure. (Apache Tomcat)

Ce qu'Apache a changé dans le correctif

La façon la plus rapide de comprendre CVE-2026-24734 est de regarder le correctif. Le commit Tomcat d'Apache e76e9ea est intitulé "Extend OCSP checks for OpenSSL to align with JSSE" (Étendre les vérifications OCSP pour OpenSSL afin de s'aligner sur JSSE). Ce commit est plus révélateur que le court texte de l'avis car il montre exactement quelles vérifications manquaient dans le chemin FFM d'OpenSSL et quelles vérifications ont été ajoutées. Les changements ne sont pas cosmétiques. Ils insèrent la validation du nonce demande-réponse, la signature de la réponse et la vérification du signataire, des vérifications explicites de la validité sur la base des données de l'utilisateur. cetteMise à jour et prochaine mise à jourLa gestion du délai d'attente OCSP est configurable, ainsi que les drapeaux de vérification OpenSSL. (GitHub)

L'un des ajouts les plus importants est OCSP_check_nonce(ocspRequest, basicResponse). Le correctif traite une non-concordance de nonce comme une réponse OCSP non valide et renvoie un statut inconnu avec un ensemble d'erreurs dans le contexte de vérification. C'est important parce que la RFC 6960 définit le nonce comme la liaison anti-rejeu entre la demande et la réponse. Si l'implémentation était auparavant prête à accepter une réponse sans vérifier cette liaison, alors elle n'établissait pas complètement que la réponse appartenait réellement à la requête en cours. (GitHub)

Le correctif ajoute également OCSP_basic_verify(basicResponse, certStack, X509_STORE_CTX_get0_store(x509ctx), state.ocspVerifyFlags). Documents OpenSSL OCSP_basic_verify() comme la vérification que la réponse est correctement signée et que le certificat du signataire peut être validé, en utilisant le magasin de confiance et tous les intermédiaires fournis. Il s'agit là d'une amélioration majeure de l'assurance par rapport à la simple extraction d'un champ d'état. A bon d'un répondeur non fiable ou incorrectement validé n'est pas une base acceptable pour laisser passer un certificat client révoqué dans la poignée de main TLS. La gestion des erreurs du correctif reflète cette logique en faisant correspondre l'échec de la vérification de base à l'erreur X509_V_ERR_OCSP_SIGNATURE_FAILURE. (GitHub)

Les contrôles de fraîcheur sont tout aussi importants. L'ancien chemin de code, tel que reflété par la différence, obtenait auparavant la réponse unique et renvoyait ensuite le statut sans le flux de validation temporelle plus complet désormais visible dans le correctif. Le code corrigé extrait cetteMise à jour et prochaine mise à jourpuis appelle OCSP_check_validity() deux fois : une fois pour détecter les réponses non encore valides et une fois pour détecter les réponses expirées, avec une correspondance explicite à X509_V_ERR_OCSP_NOT_YET_VALID et X509_V_ERR_OCSP_HAS_EXPIRED. La documentation d'OpenSSL indique OCSP_check_validity() est la fonction responsable de l'évaluation de ces horodatages et de la limitation de l'âge de la réponse. Cela signifie que le correctif ne se contente pas d'améliorer l'hygiène. Il répare la sémantique de confiance qui décide si une réponse OCSP est encore fiable. (GitHub)

Les ajouts au niveau de la configuration sont également significatifs. Le commit introduit la prise en charge de OCSP_TIMEOUT et OCSP_VERIFY_FLAGS dans le chemin du code OpenSSL FFM, et la référence de configuration de Tomcat documente désormais les éléments suivants ocspVerify comme l'attribut qui transmet les drapeaux de vérification à OCSP_basic_verify pour les implémentations TLS basées sur OpenSSL. Il documente également les ocspSoftFailavec une valeur par défaut de fauxCela signifie qu'un échec de la vérification OCSP devrait faire échouer la poignée de main TLS, à moins que l'option "soft fail" ne soit explicitement activée. Ces boutons n'existent pas dans le vide. Ils montrent qu'Apache a traité la correction non pas comme une simple réparation de bogue, mais comme une partie d'un effort plus large pour rendre la gestion OCSP explicite, configurable, et mieux alignée avec le modèle de sécurité prévu. (GitHub)

Du côté de Tomcat Native, l'histoire est parallèle. Native 2.0.12 et 1.3.5 ont été publiés en janvier 2026 avec des notes de version indiquant qu'ils étendaient la vérification des réponses OCSP et ajoutaient des options pour configurer le comportement OCSP. Ensuite, en février et mars 2026, le durcissement de Native s'est poursuivi, y compris un changement pour effacer une erreur supplémentaire dans le traitement OCSP afin que le soft fail se comporte correctement avec le connecteur APR/native. Ce travail ultérieur est devenu CVE-2026-29145. Cette séquence est importante car elle montre que la zone de code n'a pas été simplement corrigée une fois pour toutes ; elle a été activement corrigée vers un modèle OCSP plus strict et plus cohérent. (Apache Tomcat)

Quand CVE-2026-24734 devient une véritable voie d'attaque

La façon la plus propre de penser à l'exploitation n'est pas "Puis-je envoyer une chaîne d'exploitation à Tomcat ?" mais "Puis-je présenter une identité de client qui aurait dû être tuée et être encore acceptée ?" Dans les environnements où cette CVE est importante, l'atout de l'attaquant est souvent un certificat client et la clé privée correspondante qui étaient valides mais qui ne devraient plus être fiables. Cela peut être dû au départ d'un employé, à la perte d'accès d'un sous-traitant, à la mise hors service d'un appareil, à la fin d'une relation de partenariat ou à l'exposition d'une clé lors d'un autre incident. Dans un système sain, la révocation ferme cette porte. Dans un système vulnérable, le serveur peut encore être disposé à l'ouvrir. (Google Groups)

Un exemple réaliste est celui d'un partenaire API protégé par TLS mutuel. Le certificat du partenaire est révoqué à la suite d'un compromis ou d'une résiliation de contrat. Le partenaire, ou toute personne qui détient maintenant l'ancienne clé privée, devrait immédiatement perdre l'accès. Si le bord de Tomcat appliquant cette décision d'identité est dans la plage affectée et s'appuie sur le chemin OCSP vulnérable, la décision de révocation du certificat peut ne pas mordre. L'accès n'est plus contrôlé par le dernier état de confiance de l'autorité de certification, mais par l'interprétation incomplète des réponses OCSP par le serveur. C'est pourquoi certains écosystèmes décrivent le problème en termes d'autorisation plutôt qu'en termes de simple validation d'entrée. Le défaut réside dans la logique de validation, mais le résultat opérationnel est une décision de confiance qui devrait échouer et qui n'échoue pas. (nvd.nist.gov)

Le même schéma s'applique aux réseaux de services internes et aux plates-formes machine-machine qui utilisent mTLS moins comme une fonction de transport que comme un test d'adhésion. De nombreuses équipes supposent que la menace est moindre parce que les certificats sont des artefacts PKI privés et que les points d'extrémité sont internes. Le contraire peut être vrai. Le mTLS interne porte souvent des fonctions administratives, des systèmes d'orchestration, des chemins d'accès aux données sensibles ou des points d'étranglement pour les mouvements latéraux. Si un justificatif d'identité client révoqué est toujours authentifié, c'est exactement le type de faille qu'un attaquant disposant d'une emprise partielle, de matériel périmé ou de clés fuitées souhaite trouver. Le fait que l'emplacement du réseau soit "interne" ne sauve pas un système d'une mauvaise sémantique de confiance. (Apache Tomcat)

Ce que ce CVE ne décrit pas naturellement, c'est la compromission anonyme à distance de sites Tomcat publics ordinaires qui n'utilisent pas les vérifications OCSP des certificats clients. C'est pourquoi des titres généraux tels que "Le serveur Tomcat est vulnérable sur le réseau" ne sont pas utiles ici. Le vecteur d'attaque réseau dans le CVSS indique que la faille peut être exploitée sur des chemins d'authentification en réseau sans privilèges préalables, et non que chaque déploiement de Tomcat face à l'internet est également exposé. La différence est importante lorsqu'il s'agit d'évaluer l'urgence des correctifs dans les flottes. Les équipes devraient donner la priorité aux systèmes dans lesquels la révocation des certificats est censée fonctionner comme une limite de contrôle d'accès en temps réel. (nvd.nist.gov)

Qui est probablement concerné et qui ne l'est probablement pas ?

Le moyen le plus rapide de réagir de manière excessive à la CVE-2026-24734 est de considérer toutes les instances de Tomcat comme également vulnérables. Le moyen le plus rapide de ne pas réagir suffisamment est de supposer que parce que vous n'avez jamais explicitement installé "Tomcat Native" en tant que produit distinct, vous êtes en sécurité. Ces deux raccourcis échouent parce que l'exposition réelle dépend de la combinaison de la version, de l'implémentation du connecteur, du modèle d'authentification du certificat et de l'utilisation d'OCSP. (nvd.nist.gov)

Un déploiement se trouve dans la catégorie de risque la plus élevée lorsque quatre conditions sont réunies. Premièrement, il utilise une gamme de versions vulnérables de Tomcat ou de Tomcat Native. Deuxièmement, il utilise un chemin de connecteur soutenu par OpenSSL qui correspond à la prise en charge de la fonctionnalité OCSP de Tomcat, comme APR/native, OpenSSL JSSE, ou l'implémentation OpenSSL Panama FFM. Troisièmement, il effectue la validation du certificat client d'une manière qui dépend de l'OCSP. Quatrièmement, ces certificats clients comportent un URI de réponse OCSP, car la documentation de Tomcat indique qu'il valide les certificats clients à l'aide de l'URI de réponse intégré dans l'extension Authority Information Access. Si l'une de ces pièces manque, le risque pratique diminue fortement. (Apache Tomcat)

Un déploiement JSSE simple sans ces vérifications OCSP soutenues par OpenSSL ne semble pas correspondre au chemin vulnérable décrit par Apache pour ce CVE. Cette conclusion est basée sur l'étendue des fonctionnalités de Tomcat : la documentation sur le support OCSP liste les types de connecteurs et indique explicitement que l'OCSP n'est pas supporté avec les connecteurs de type org.apache.tomcat.util.net.jsse.JSSEImplementation ou le style de configuration de JSSE. Cela ne veut pas dire que tout déploiement de JSSE est à l'abri de tout bogue de validation de certificat pour toujours. Il s'agit simplement de la lecture la plus prudente du chemin vulnérable décrit pour CVE-2026-24734. (Apache Tomcat)

Une application Java embarquée mérite une attention particulière. De nombreuses équipes pensent en termes de paquets de serveurs alors que leur réalité de production est une application Spring Boot avec Tomcat intégré. La base de données d'avis de GitHub suit les gammes vulnérables de tomcat-embed-core et matou-coyote ce qui signifie que l'analyse de la composition du logiciel, les manifestes de construction et les arbres de dépendance font partie de l'examen de l'exposition. Une équipe peut ne pas /opt/tomcat et qu'il porte encore le chemin d'accès au code vulnérable dans un artefact d'application. (GitHub)

La question pratique de triage la plus rapide n'est donc pas "Do we run Tomcat ?" mais "Where do we terminate mTLS client auth on Tomcat, with OCSP-backed certificate revocation, through an OpenSSL-backed connector, in one of the affected version ranges ?" Cette question est plus restreinte, plus concrète et plus proche du véritable rayon d'action. (Apache Tomcat)

Comment déterminer l'exposition dans votre environnement

Commencez par l'inventaire des versions. Sur une installation autonome de Tomcat, confirmez d'abord le train d'exécution et le niveau de correctifs. Pour les applications intégrées, inspectez les manifestes de dépendance et les fichiers de verrouillage. Pour les charges de travail conteneurisées, inspectez le contenu de l'image et les bibliothèques intégrées à l'application. Il ne s'agit pas simplement de trouver "Tomcat quelque part". Il s'agit de mettre en correspondance chaque charge de travail avec les gammes de versions Apache et NVD réellement marquées comme affectées. (nvd.nist.gov)

La première étape d'une installation traditionnelle se présente comme suit :

# Version Tomcat autonome
$CATALINA_HOME/bin/catalina.sh version

# Recherche de la présence de la bibliothèque native
find "$CATALINA_HOME" "$CATALINA_BASE" -iname '*tcnative*' -o -iname 'libtcnative*' 2>/dev/null

Image du conteneur # ou inventaire des paquets
rpm -qa | grep -Ei 'tomcat|tcnative'
dpkg -l | grep -Ei 'tomcat|tcnative'

Pour les applications Java intégrées, l'inspection des dépendances est tout aussi importante, car les bases de données consultatives mettent en correspondance les CVE avec les coordonnées des paquets ainsi qu'avec les versions des serveurs. (GitHub)

# Maven
mvn -q dependency:tree | grep -E 'org\.apache\.tomcat|tomcat-embed-core|tomcat-coyote'

# Gradle
./gradlew dependencies | grep -E 'org\c.apache\c.tomcat|tomcat-embed-core|tomcat-coyote'

Ensuite, il faut déterminer si l'application utilise les familles de connecteurs que Tomcat documente pour OCSP. Le guide SSL/TLS de Tomcat indique les types de connecteurs et les styles de configuration appropriés. Vous recherchez des signes d'APR/native, OpenSSLImplémentationou l'implémentation de Panama OpenSSL, ainsi que les paramètres de vérification des certificats et la configuration liée à OCSP. Un balayage rapide de la configuration permet souvent de répondre à ces questions en quelques minutes (Apache Tomcat)

grep -RInE 'Http11AprProtocol|OpenSSLImplementation|openssl\.panama|ocspEnabled|ocspSoftFail|ocspVerify|certificateVerification|sslImplementationName' \N- "$CATALINA_BASE/conf" "$CATALINA_HOME/conf" 2>/dev/nullité
  "$CATALINA_BASE/conf" $CATALINA_HOME/conf" 2>/dev/null

L'exemple du connecteur OCSP de Tomcat est un bon point d'ancrage pour une configuration pertinente. La documentation montre un connecteur APR/natif avec certificateVerification="require" et un certificat configuré sous SSLHostConfigpuis un processus de réponse OCSP démarre avec le code OpenSSL ocsp outil. Si votre serveur ne ressemble en rien à ce modèle, les chances que CVE-2026-24734 soit votre problème urgent sont plus faibles. Si c'est le cas, vous devriez continuer à creuser. (Apache Tomcat)

Un exemple simplifié, proche du modèle documenté, ressemble à ceci :

Après la configuration, vérifiez que les certificats clients en jeu comportent bien un URI de réponse OCSP dans l'extension d'accès aux informations de l'autorité. Le guide OCSP de Tomcat indique que le certificat doit contenir l'emplacement du répondeur. Sans cela, le chemin de validation OCSP prévu peut même ne pas être actif. (Apache Tomcat)

openssl x509 -in client.crt -noout -text | sed -n '/Authority Information Access/,+5p'

Enfin, il convient de vérifier si l'application dépend réellement de l'authentification par certificat client en tant que limite de sécurité. Dans de nombreuses flottes, TLS est activé partout, mais mTLS n'est activé que sur un petit sous-ensemble de connecteurs, de chemins ou de services. L'impact commercial de CVE-2026-24734 se fait sentir là où l'acceptation du certificat équivaut à l'autorisation de faire quelque chose de significatif. Inventoriez les plans d'administration, les points de terminaison des partenaires, les services d'intégration des appareils, les API internes et les identités des machines où cette affirmation est vraie. Cet exercice de cadrage est généralement plus important que le nombre brut d'hôtes. (Apache Tomcat)

Validation en laboratoire pour CVE-2026-24734

La bonne façon de valider ce problème n'est pas d'improviser par rapport à la production. Il s'agit de reproduire la décision de confiance dans un laboratoire que vous contrôlez, puis de comparer le comportement avant et après l'application du correctif. La documentation de Tomcat fournit déjà la plupart des éléments de base : comment créer des certificats OCSP, comment configurer un connecteur OCSP, et comment démarrer un répondeur OCSP de base en utilisant OpenSSL. Il s'agit ici de transformer ces éléments en un test contrôlé de révocation et d'acceptation. (Apache Tomcat)

La génération de certificats commence par la configuration d'une autorité de certification OpenSSL qui incorpore un URI de réponse OCSP dans le certificat émis par l'intermédiaire de l'extension Authority Information Access. La documentation de Tomcat indique la ligne correspondante comme suit authorityInfoAccess = OCSP;URI:http://127.0.0.1:8088. Il ne s'agit pas d'une extension décorative. C'est la façon dont Tomcat sait où demander l'état du certificat du client. Ensuite, le flux documenté crée une clé privée, crée un CSR, le signe, puis vérifie le certificat résultant. (Apache Tomcat)

# Créer une clé privée
openssl genrsa -aes256 -out ocsp-cert.key 4096

# Créer une CSR
openssl req -config openssl.cnf -new -sha256 \N-key ocsp-cert.key -out ocsp-cert.key 4096
  -key ocsp-cert.key -out ocsp-cert.csr

# Signer le CSR
openssl ca -config openssl.cnf -extensions ocsp -days 375 -notext \N- -md sha256 -md sha256 -notext \N
  -md sha256 -in ocsp-cert.csr -out ocsp-cert.crt

# Inspecter le certificat pour AIA / OCSP
openssl x509 -noout -text -in ocsp-cert.crt

Côté serveur, utilisez un connecteur Tomcat qui correspond aux chemins d'accès OCSP documentés. Si vous voulez reproduire l'exemple APR/natif de la documentation officielle, utilisez le protocole APR. Si vous souhaitez tester spécifiquement le chemin FFM, utilisez l'implémentation OpenSSL Panama documentée sur une version Java qui supporte cette fonctionnalité. Le point essentiel est que votre environnement de test doit ressembler à l'une des familles de connecteurs que Tomcat dit prendre en charge dans le cadre de l'OCSP. Dans le cas contraire, vous ne validerez pas le chemin de code que ce CVE couvre réellement. (Apache Tomcat)

La documentation de Tomcat fournit également une commande de base pour le répondeur OpenSSL :

openssl ocsp -port 127.0.0.1:8088 \N-text -ha256 -index index.txt
  -text -sha256 -index index.txt \N -CA ca-chain.cert.pem -rkey ocsp-cert.key \N
  -CA ca-chain.cert.pem -rkey ocsp-cert.key \n- -rsigner ocsp-cert.crt \n- -signaler ocsp-cert.crt
  -rsigner ocsp-cert.crt

Une fois ces éléments en place, la séquence utile du laboratoire est simple. Tout d'abord, émettez un certificat client à partir de votre AC de test et confirmez qu'un client détenant ce certificat peut terminer la poignée de main mTLS et atteindre le point de terminaison protégé. Deuxièmement, révoquez ce certificat client dans l'index de votre autorité de certification et mettez à jour l'état du répondeur OCSP en conséquence. Troisièmement, relancez la même tentative de connexion avec une version vulnérable et avec une version corrigée. La question n'est pas de savoir si Tomcat enregistre quelque chose d'intéressant. La question est de savoir si un certificat client désormais révoqué est toujours accepté. C'est la décision de confiance dont il est question dans la CVE-2026-24734. (Apache Tomcat)

Un client de test défensif peut être aussi simple que openssl s_client avec le certificat et la clé du client :

openssl s_client \N- -connect tomcat-lab.example:8443
  -connect tomcat-lab.example:8443 \N -cert revoked-client.crt \N
  -cert revoked-client.crt \N- -key revoked-client.key \N- -cert revoked-client.crt \N
  -key revoked-client.key \N -CAfile ca-chain.cert.pem \N
  -CAfile ca-chain.cert.pem \N- -state -tlsextdefault.crt \N -key revoked-client.key \N
  -state -tlsextdebug

Traitez le résultat avec précaution. L'échec d'une poignée de main après la révocation est le résultat sain attendu. Une prise de contact réussie avec le certificat révoqué est la condition d'échec. Si vous souhaitez une meilleure observabilité pendant les tests, le guide SSL/TLS de Tomcat recommande d'activer le journal de débogage dédié à la prise de contrôle TLS dans la section logging.propertiesen utilisant des noms d'enregistreurs tels que org.apache.tomcat.util.net.NioEndpoint.handshake.level=FINE ou org.apache.tomcat.util.net.Nio2Endpoint.handshake.level=FINE en fonction du connecteur en jeu. Cette journalisation ne vous dira pas, comme par magie, "CVE-2026-24734 s'est produit", mais elle peut vous aider à distinguer une mauvaise configuration TLS ordinaire du résultat de confiance spécifique que vous essayez de valider. (Apache Tomcat)

org.apache.tomcat.util.net.NioEndpoint.handshake.level=FINE
org.apache.tomcat.util.net.Nio2Endpoint.handshake.level=FINE

Une précaution pratique s'impose ici. La documentation de Tomcat indique que lorsque OCSP est utilisé, le répondeur encodé dans le certificat doit être en cours d'exécution. Cela semble évident, mais cela affecte l'interprétation des tests. Si le répondeur n'est pas disponible, le comportement d'échec progressif et de dépassement de délai fait partie du résultat. Et c'est exactement la raison pour laquelle les travaux ultérieurs de renforcement de l'OCSP, y compris ocspSoftFail, ocspVerifyLa gestion du délai d'attente et les correctifs de mars 2026 (CVE-2026-29145) doivent être gardés à l'esprit lors de la validation. Un système peut passer d'un chemin de confiance brisé à un autre si les équipes ne valident que le cas ensoleillé. (Apache Tomcat)

Ce que les défenseurs peuvent détecter et ce qu'ils ne peuvent généralement pas détecter

CVE-2026-24734 n'est pas une vulnérabilité riche en IOC. Il n'y a pas d'URI canonique d'exploitation à rechercher dans les journaux d'accès. Il n'y a pas d'exception d'application évidente qui crie "le certificat révoqué a été accepté". Dans de nombreux environnements, le signal dangereux est le contraire d'un signal d'échec : une connexion réussit alors que l'organisation pense qu'elle aurait dû échouer. Cela éloigne la détection de l'analyse générique des journaux et l'oriente vers la validation des contrôles et les preuves intersystèmes. (Google Groups)

La meilleure technique défensive immédiate est la vérification active. Créez un petit ensemble de certificats clients de test dont vous contrôlez le cycle de vie. Révoquez-en un. Tentez la poignée de main. Confirmez le rejet. Répétez l'opération après les mises à jour, les changements de magasin de certificats, les changements de connecteur, les mises à jour Java et les changements de répondeur OCSP. Ce type de test est plus utile que d'attendre que le SIEM déduise un échec subtil de la confiance à partir d'une télémétrie générale. La RFC 6960 et le modèle de validité d'OpenSSL indiquent clairement que la fraîcheur et la liaison demande-réponse font partie de la décision de confiance. Le seul moyen fiable de savoir si votre pile applique toujours cette sémantique après un changement est de la réexercer. (datatracker.ietf.org)

La télémétrie passive a toujours un rôle à jouer, mais il est indirect. Si votre PKI ou votre source de vérité IAM indique qu'un certificat client est révoqué, alors que les journaux d'accès côté application, les journaux de passerelle ou les enregistrements d'audit en aval montrent toujours des sessions authentifiées réussies liées à l'identité de ce certificat, cette divergence est significative. Dans les entreprises matures, l'inventaire des certificats, les enregistrements de révocation et les enregistrements d'accès aux applications devraient être suffisamment comparables pour détecter ce type de dérive. Le but n'est pas que Tomcat émette une alerte parfaite de "contournement de la révocation". Il s'agit de faire en sorte que votre plan de contrôle rende difficile l'apparition d'informations d'identification mortes dans des chemins d'authentification réussis sans que personne ne s'en aperçoive. (datatracker.ietf.org)

La journalisation du débogage de la poignée de main de Tomcat est utile lors du triage parce qu'elle montre où la poignée de main échoue ou se déroule, et parce que les problèmes de validation de certificat se résument souvent à du bruit TLS générique. Il ne s'agit pas d'une stratégie de détection complète, et il ne faut pas la laisser activée partout en permanence. Mais pendant les fenêtres de vérification, l'examen des incidents ou les nouveaux tests contrôlés, elle donne aux défenseurs une meilleure vision du comportement lié à l'OCSP que les journaux de demande normaux. (Apache Tomcat)

Remédiation et renforcement des chemins OCSP d'Apache Tomcat

La solution minimale est claire : passer aux versions corrigées ou ultérieures. Cela signifie Tomcat Native 1.3.5 ou 2.0.12 et Apache Tomcat 9.0.115, 10.1.52 ou 11.0.18 au minimum, en fonction de votre train. Mais "ou plus tard" fait un travail important. Apache a continué à fournir des correctifs liés à OCSP après la divulgation initiale. Pour les équipes qui considèrent les certificats clients comme un contrôle d'accès significatif, la position la plus prudente est de passer à une version de maintenance courante plutôt que de s'asseoir exactement sur la première version corrigée pour toujours. (nvd.nist.gov)

Si vous utilisez les anciennes branches Native en fin de vie que NVD répertorie encore comme affectées, ce n'est pas le moment de porter des correctifs héroïques. L'application de la révocation est au cœur de la logique de l'identité. L'exécution de branches mortes qui sont déjà connues pour avoir des problèmes OCSP historiques, tout en manquant également le bénéfice du travail de renforcement ultérieur, est le genre de dette technique qui échoue le plus durement lors de la réponse à l'incident. La migration est généralement la solution la plus sûre et la moins coûteuse. (nvd.nist.gov)

Après la mise à niveau, refaire un test avec les certificats révoqués. Cela semble banal, mais c'est l'étape la plus importante que les équipes négligent. Un saut de version peut vous indiquer que le fournisseur a livré un correctif. Il ne vous dit pas que votre environnement utilise le chemin fixe comme vous le pensez, que votre répondeur OCSP renvoie la sémantique que vous attendez, ou que votre sélection et votre configuration de connecteurs s'alignent toujours après d'autres changements. L'acceptation d'un correctif sans un nouveau test du certificat révoqué est une hypothèse de confiance, pas une preuve. (GitHub)

Soyez explicite sur la politique OCSP. Documents de référence sur la configuration de Tomcat ocspSoftFail et ocspVerifyet le travail de correction a ajouté la prise en charge du délai d'attente et des drapeaux de vérification dans le chemin FFM. Cela signifie que le comportement critique en matière de sécurité n'est pas entièrement pris en compte par la mention "OCSP est activé". Les équipes doivent documenter si l'échec progressif est autorisé, quel comportement de temporisation est acceptable, si le magasin de confiance et les drapeaux de vérification sont intentionnellement activés, et comment le système doit se comporter lorsque le répondeur n'est pas disponible ou est en retard. L'ambiguïté autour de ces choix a tendance à se transformer accidentellement en politique de sécurité de production. (Apache Tomcat)

Les contrôles compensatoires peuvent réduire l'exposition pendant le déploiement des mises à jour, mais ils ne remplacent pas la mise en œuvre de la révocation. Sur les interfaces les plus importantes, combinez mTLS avec une exposition réseau plus étroite, une autorisation explicite au niveau de l'application, des certificats clients de courte durée et des flux de travail de remplacement rapide des certificats. Ces contrôles sont importants car ils réduisent la valeur d'un certificat périmé ou compromis, même si la gestion de la révocation est temporairement imparfaite. Ils ne rétablissent pas la garantie manquante qu'un certificat révoqué est réellement mort. Seul un chemin de confiance fixe et vérifié le permet. (datatracker.ietf.org)

Il y a ici un aspect "workflow" qui est souvent négligé. Le plus difficile n'est pas de trouver une commande shell pour tester un connecteur. Il s'agit de maintenir le cadrage des actifs, l'inventaire des versions, l'empreinte digitale des connecteurs, l'inspection des certificats, les nouveaux tests et la collecte de preuves liés à chaque fois qu'une version, une rotation de certificat ou un changement d'ICP survient. Les documents publics de Penligent mettent l'accent sur les flux de travail agentiques sous contrôle humain, l'accès en un clic à une large surface d'outils Kali, et la vérification plus le rapport comme une boucle connectée. En pratique, c'est la forme du travail dont les défenseurs ont besoin après un tel bogue : pas seulement des correctifs, mais la preuve répétable que le chemin de confiance vulnérable a disparu sur les systèmes qui comptent vraiment. (penligent.ai)

CVE connexes qui rendent CVE-2026-24734 plus important, et non moins important

Une raison de prendre CVE-2026-24734 au sérieux est qu'il n'est pas isolé. L'historique de sécurité de Tomcat Native contient des problèmes antérieurs liés à OCSP qui ont affecté l'application de la révocation, ce qui rend ce problème moins aléatoire et plus comme un rappel que la gestion de l'état des certificats est facile à faire subtilement mal. La page d'Apache sur la sécurité de Native est particulièrement utile ici car elle présente l'historique en un seul endroit. (Apache Tomcat)

CVE-2017-15698 était une omission de vérification OCSP dans Tomcat Native. Apache indique que lors de l'analyse de l'extension AIA d'un certificat client, le connecteur ne gérait pas correctement les champs de plus de 127 octets, ce qui entraînait l'omission de la vérification OCSP. L'impact était direct : les certificats clients qui auraient dû être rejetés si la vérification OCSP avait été exécutée pouvaient au contraire être acceptés. Il s'agit d'un bogue d'implémentation différent de CVE-2026-24734, mais le thème est identique. La logique de révocation est critique pour la sécurité, et des erreurs d'analyse ou de validation apparemment secondaires peuvent la neutraliser. (Apache Tomcat)

CVE-2018-8019 et CVE-2018-8020 vont dans le même sens. Dans un cas, des réponses OCSP invalides ont été mal gérées, permettant à des certificats clients révoqués d'être incorrectement identifiés. Dans l'autre cas, Tomcat Native a mal vérifié les réponses OCSP pré-produites contenant des listes d'états de certificats, ce qui a permis à des certificats clients révoqués de se faufiler dans des connexions qui nécessitaient TLS mutuel. Ces problèmes plus anciens sont précieux parce qu'ils forment le bon instinct : lorsque le traitement OCSP est impliqué, ne vous arrêtez pas à la syntaxe ou aux champs d'état. Confirmez que l'autorisation de répondre, la structure de la réponse, la fraîcheur de la réponse et l'identité exacte du certificat évalué sont toutes traitées correctement. (Apache Tomcat)

Vient ensuite CVE-2026-24734, qui corrige une vérification incomplète et des contrôles de fraîcheur dans les chemins Native et FFM. Peu après, la CVE-2026-29145 apparaît, Apache déclarant que CLIENT_CERT L'authentification OCSP n'échouait pas comme prévu dans certains scénarios, même lorsque l'échec progressif était désactivé. Ce problème ultérieur n'est pas la preuve que la correction initiale était erronée. Il prouve que le comportement de l'OCSP dans les cas limites opérationnels reste suffisamment délicat pour que les équipes défensives valident l'ensemble du chemin de confiance, et ne se contentent pas de supposer que "corrigé une fois" équivaut à "résolu pour toujours". (Apache Tomcat)

Pour les équipes qui utilisent massivement des certificats clients, une autre leçon à tirer provient des problèmes de contournement de la vérification des certificats de Tomcat en dehors de la famille OCSP. Apache a divulgué CVE-2025-66614 comme un contournement de vérification de certificat client lié au mappage d'hôte virtuel, et a ensuite divulgué CVE-2026-32990 comme un correctif incomplet dans ce domaine. Les mécanismes directs diffèrent de CVE-2026-24734, mais le message opérationnel est le même : les limites de confiance basées sur les certificats dans Tomcat méritent un examen continu, car le comportement des connecteurs, la correspondance des hôtes et la logique de révocation peuvent tous devenir des échecs d'autorisation s'ils sont mis en œuvre ou configurés de manière incorrecte. (Apache Tomcat)

CVE	Zone	Pourquoi c'est important ici	Leçon pratique
CVE-2017-15698	Vérification OCSP omise	Un bogue dans l'analyse de l'AIA pourrait permettre d'ignorer complètement l'OCSP	Ne jamais supposer que "OCSP activé" signifie "OCSP appliqué"
CVE-2018-8019	Traitement d'une réponse OCSP invalide	Les certificats révoqués des clients pourraient être mal identifiés	La gestion du format de la réponse fait partie de l'exactitude de l'authentification
CVE-2018-8020	Traitement des réponses OCSP pré-produites	Les certificats révoqués des clients peuvent toujours être authentifiés	La logique des réponses mises en cache ou regroupées doit faire l'objet d'une validation stricte.
CVE-2026-24734	Vérifications et contrôles de fraîcheur incomplets	La révocation peut être contournée	Signature, nonce et fraîcheur, tout est important
CVE-2026-29145	Cas limites du comportement d'échec en douceur	CLIENT_CERT l'authentification peut encore échouer	Patch, puis re-test des conditions de bord, pas seulement des chemins heureux

Preuves, rapports et nouveaux tests après le correctif

Une fois le correctif mis en place, le travail n'est pas terminé tant que les preuves ne sont pas suffisamment solides pour qu'un autre ingénieur, un auditeur ou vous-même puissiez répondre à trois questions sans deviner : quel système a été affecté, qu'est-ce qui a changé et quel test exact a prouvé que le chemin du certificat révoqué échouait désormais. Cela signifie qu'il faut conserver la configuration du connecteur qui a été utilisée, l'identité du certificat utilisé lors des tests, l'événement de révocation, le comportement de la poignée de main avant et après, et l'état exact de la version de Tomcat ou de Tomcat Native lors de chaque exécution. Les bonnes preuves de remédiation sont concrètes ou inutiles. (Apache Tomcat)

C'est également à ce stade que l'assistance de l'IA peut être utile ou nuisible. Une note vague générée par l'IA qui dit "mis à jour et retesté avec succès" n'est pas une preuve. Les conseils de Penligent en matière de rapports abordent la bonne partie de ce problème : un pentest ou un rapport de validation solide nécessite un emplacement clair, une déclaration d'impact concrète, des étapes de reproduction et des artefacts de soutien plutôt qu'un modèle générique de prose. Cet état d'esprit est exactement ce dont la validation post-patch pour CVE-2026-24734 a besoin. Un bon rapport devrait permettre à un autre ingénieur de rejouer la décision de confiance, et non pas simplement de croire que vous l'avez déjà fait. (penligent.ai)

La véritable leçon de CVE-2026-24734

CVE-2026-24734 est une vulnérabilité utile car elle met en évidence une habitude courante en matière de sécurité : de nombreux systèmes traitent la confiance dans les certificats comme une propriété statique alors qu'il s'agit en réalité d'une décision en cours de validité. Un certificat peut être bien formé, signé par le bon émetteur, et pourtant ne pas être digne de confiance parce que l'émetteur l'a révoqué. L'OCSP est censé intégrer cette décision dans la poignée de main TLS. Si l'implémentation ne vérifie pas correctement le répondeur, ne lie pas correctement la demande et la réponse, ou n'applique pas correctement la fraîcheur, alors le système ne prend plus une décision de confiance en temps réel, mais une décision périmée. Il prend une décision périmée. (datatracker.ietf.org)

C'est pourquoi ce CVE mérite plus d'attention que ne le suggère son titre. Pour les équipes qui utilisent Tomcat pour terminer le HTTPS ordinaire sans certificat client, le bogue peut être un élément de correctif peu dramatique. Pour les équipes qui utilisent mTLS comme frontière réelle, il s'agit d'un test direct permettant de vérifier si les identités révoquées meurent réellement lorsque l'organisation dit qu'elles doivent le faire. Apache a résolu le problème. Le travail restant incombe aux défenseurs : identifier où le chemin de confiance vulnérable existait, passer aux versions actuelles supportées, valider avec des certificats révoqués, et continuer à le faire chaque fois que l'ICP, la pile de connecteurs ou la frontière d'identité changent. (Google Groups)

Autres lectures et références

• Entrée NVD pour CVE-2026-24734, versions affectées, CVSS, et jeu de références. (nvd.nist.gov)
• Texte de l'avis d'Apache avec la sévérité, les versions affectées, l'atténuation, et le crédit à Joshua Rogers. (Google Groups)
• Entrée de la page de sécurité d'Apache Tomcat 9 pour CVE-2026-24734 et CVE-2026-29145, la suite liée à l'OCSP. (Apache Tomcat)
• Entrée de la page de sécurité d'Apache Tomcat 10.1 pour CVE-2026-24734 et CVE-2026-29145. (Apache Tomcat)
• Entrée de la page de sécurité d'Apache Tomcat 11 pour CVE-2026-24734 et CVE-2026-29145. (Apache Tomcat)
• Page de sécurité Apache Tomcat Native pour CVE-2026-24734, plus la lignée OCSP antérieure incluant CVE-2017-15698, CVE-2018-8019, et CVE-2018-8020. (Apache Tomcat)
• Notes de version d'Apache Tomcat indiquant les versions fixes de janvier 2026 et l'évolution continue de l'OCSP dans les versions ultérieures. (Apache Tomcat)
• Documentation Tomcat SSL/TLS OCSP couvrant les familles de connecteurs supportées, l'accent mis sur le certificat client, les exigences AIA, l'exemple de connecteur, le démarrage du répondeur et l'enregistrement de la poignée de main. (Apache Tomcat)
• Référence de configuration du connecteur Tomcat pour ocspEnabled, ocspSoftFailet ocspVerify. (Apache Tomcat)
• Documentation OpenSSL pour OCSP_basic_verify, OCSP_check_validityLe système de gestion de l'information est un système de gestion de l'information, d'extraction de l'état et de gestion de l'âge de la réponse. (docs.openssl.org)
• RFC 6960 pour la sémantique OCSP, y compris cetteMise à jour, prochaine mise à jour, produitAuet nonce. (datatracker.ietf.org)
• Apache Tomcat fix commit e76e9eaqui montre les contrôles de nonce, de signature et de fraîcheur ajoutés dans le chemin FFM d'OpenSSL. (GitHub)
• Suivi du commit Tomcat Native 69a977dCe qui explique pourquoi le durcissement de l'OCSP s'est poursuivi après la divulgation initiale. (GitHub)
• Page d'accueil de Penligent pour les informations publiques sur les produits concernant les flux de travail agentiques, l'accès aux outils, la vérification et l'établissement de rapports. (penligent.ai)
• Project Glasswing Shows Why AI Defense Needs Continuous Penetration Testing (Le projet Glasswing montre pourquoi la défense de l'IA nécessite des tests de pénétration continus), pour le cas plus large où les contrôles de sécurité nécessitent une vérification contradictoire récurrente au lieu d'hypothèses ponctuelles. (penligent.ai)
• Comment obtenir un rapport de pentest sur l'IA, pour des conseils pratiques sur la qualité des preuves, les détails de la reproduction et les artefacts à l'appui des rapports de sécurité. (penligent.ai)