CVE-2026-24734, Anulación de revocación OCSP de Apache Tomcat

CVE-2026-24734 no es el tipo de fallo de Tomcat que genera titulares dramáticos. No permite a un atacante no autenticado la ejecución remota de código. No convierte una petición HTTP malformada en corrupción de memoria. Lo que hace, en cambio, es afectar a una garantía de seguridad más silenciosa y fundamental: si un servidor que depende de certificados de cliente puede seguir confiando en sus propias comprobaciones de revocación. El aviso de Apache dice que cuando Tomcat Native, y la ruta OpenSSL FFM de Tomcat, utilizaban un respondedor OCSP, no completaban las comprobaciones de verificación o frescura de la respuesta OCSP. El resultado es sencillo y peligroso en el entorno adecuado: se puede eludir la revocación de certificados. Apache marcó el problema como Moderado, mientras que NVD y la base de datos de avisos de GitHub le asignan una gravedad CVSS 3.x alta. (Grupos de Google)

Esa distinción importa porque el riesgo real es fácil de malinterpretar. Este no es un problema genérico de "todos los HTTPS de Tomcat están rotos". La propia documentación OCSP de Tomcat vincula la comprobación OCSP a los certificados de cliente y a un subconjunto de configuraciones de conectores respaldados por OpenSSL. En el modelo documentado, Tomcat valida los certificados proporcionados por el cliente con un URI de respuesta OCSP en la extensión de acceso a información de autoridad, y esa característica se implementa para la ruta JSSE de OpenSSL, la ruta FFM de OpenSSL y el conector APR/nativo en lugar de la implementación JSSE simple descrita en otra parte de la misma documentación. En la práctica, las implementaciones de mayor riesgo son las que utilizan mTLS como límite de control de acceso para API B2B, planos de administración internos, integraciones de socios, identidades de dispositivos o autenticación privilegiada de servicio a servicio. (Apache Tomcat)

También es digno de mención el propio rastro de divulgación de Apache. El problema fue reportado al equipo de seguridad de Tomcat el 2 de noviembre de 2025. Las versiones corregidas se enviaron en enero de 2026 a Tomcat Native y Tomcat 9, 10.1 y 11.0, y el aviso público se publicó el 17 de febrero de 2026. Este calendario es normal para una divulgación coordinada. Lo más importante desde el punto de vista de la ingeniería es que el manejo de OCSP en esta área de código siguió evolucionando incluso después de la corrección inicial. En marzo de 2026, Apache reveló CVE-2026-29145, otro problema relacionado con OCSP en el que la autenticación de certificados de cliente a veces fallaba incluso cuando el fallo suave estaba deshabilitado. La lección no es sólo "cruza la versión parcheada mínima y sigue adelante". Es que las rutas de aplicación de revocación merecen volver a probarse, no marcar casillas. (Apache Tomcat)

CVE-2026-24734 de un vistazo

Apache y NVD identifican las gamas afectadas de la siguiente manera. Para Tomcat Native, están afectadas las versiones 1.3.0 a 1.3.4 y 2.0.0 a 2.0.11, con correcciones en 1.3.5 y 2.0.12. Para Apache Tomcat, los trenes afectados son 11.0.0-M1 a 11.0.17, 10.1.0-M7 a 10.1.51, y 9.0.83 a 9.0.114, con correcciones en 11.0.18, 10.1.52 y 9.0.115. NVD también señala que los rangos más antiguos de Tomcat Native, específicamente de 1.1.23 a 1.1.34 y de 1.2.0 a 1.2.39, también están afectados. La base de datos de avisos de GitHub también asigna el problema a rangos de paquetes Java integrados, incluyendo org.apache.tomcat.embed:tomcat-embed-core y org.apache.tomcat:tomcat-coyoteque es un recordatorio útil de que no todos los despliegues vulnerables se parecen a un servidor Tomcat independiente en una máquina virtual. (nvd.nist.gov)

Componente	Versiones afectadas	Versiones fijas	Nota operativa
Tomcat nativo 1.3.x	1.3.0 a 1.3.4	1.3.5 o posterior	Ruta OCSP en conector APR/nativo
Tomcat nativo 2.0.x	2.0.0 a 2.0.11	2.0.12 o posterior	Ruta nativa respaldada por OpenSSL
Tomcat 11	11.0.0-M1 a 11.0.17	11.0.18 o posterior	FFM OpenSSL ruta afectada
Tomcat 10.1	10.1.0-M7 a 10.1.51	10.1.52 o posterior	FFM OpenSSL ruta afectada
Tomcat 9	9.0.83 a 9.0.114	9.0.115 o posterior	FFM OpenSSL ruta afectada
EOL Líneas nativas	1.1.23 a 1.1.34, 1.2.0 a 1.2.39	Ningún futuro in situ compatible	La migración es más segura que aferrarse a ramas muertas

La historia de la gravedad es un poco confusa de una manera que es realmente instructiva. El aviso de Apache etiqueta el problema como Moderado. NVD lista un vector 7.5 Alto de enriquecimiento NVD y un vector 7.4 Alto separado de CISA-ADP. Snyk clasifica los registros de paquetes estrechamente relacionados bajo el estilo CWE-863, describiendo el impacto como autorización incorrecta, mientras que Apache y NVD enmarcan la debilidad en torno a la validación incompleta y el manejo de la respuesta OCSP. Estas diferencias son menos una contradicción que un cambio de perspectiva. A nivel de código, el fallo está relacionado con la validación incompleta de la respuesta. A nivel del sistema, el impacto es que una credencial revocada todavía puede ser aceptada y por lo tanto todavía autorizar el acceso. (Grupos de Google)

Explicación del bypass de revocación OCSP de Apache Tomcat

Para entender por qué CVE-2026-24734 es importante, ayuda ser preciso sobre lo que Tomcat está haciendo cuando OCSP está habilitado. La documentación SSL/TLS de Tomcat dice que el soporte OCSP existe para verificar el estado de los certificados proporcionados por el cliente. Enumera las familias de conectores compatibles con esta función: NIO o NIO2 con org.apache.tomcat.util.net.openssl.OpenSSLImplementationNIO o NIO2 con org.apache.tomcat.util.net.openssl.panama.OpenSSLImplementationy el conector APR/native HTTP con una compilación Tomcat Native habilitada para OCSP. La misma documentación dice que OCSP no está soportado si se usa la implementación JSSE simple o si se usa el estilo de configuración JSSE. Esa definición de ámbito es crítica. Significa que la vulnerabilidad se encuentra en una ruta de confianza específica: la validación del lado del servidor de los certificados de cliente en configuraciones de Tomcat respaldadas por OpenSSL. (Apache Tomcat)

En un despliegue típico de mTLS, el cliente presenta un certificado durante el handshake TLS. El servidor no sólo necesita saber si el certificado está vinculado a un emisor de confianza. También necesita saber si ese certificado ha sido revocado desde su emisión. OCSP es una de las formas estándar de responder a esta pregunta casi en tiempo real. Si el certificado de un dispositivo se revoca porque el dispositivo ha sido dado de baja, si el certificado de un socio se revoca porque ha finalizado la relación o si se sospecha que la clave privada de un cliente está comprometida, se supone que el servicio de confianza rechaza ese certificado de cliente. Si se puede eludir la comprobación de revocación, el modelo de control de acceso construido sobre ese certificado deja de ser de confianza. (Apache Tomcat)

Por eso el impacto es más duro en ciertos entornos que en otros. Un sitio web público que utiliza Tomcat para TLS ordinario pero no requiere certificados de cliente no es la víctima canónica. Una API asociada que sólo admite titulares de certificados de cliente aprobados sí lo es. También lo es un plano de operaciones interno en el que las identidades de las máquinas se refuerzan mediante mTLS, un sistema industrial que incorpora dispositivos mediante certificados o una pasarela en la que la posesión de certificados se considera la prueba principal de pertenencia a la organización. En todos estos diseños, la revocación no es una característica cosmética. Es el interruptor de seguridad para las identidades en las que ya no se debe confiar. Una vez que ese interruptor se puede eludir, la contención de incidentes, el offboarding y la respuesta ante el compromiso de claves se degradan. (Apache Tomcat)

También hay un error conceptual fácil de evitar. La palabra "certificado" hace pensar a muchos lectores en navegadores que validan certificados de servidor. Ese no es el centro de gravedad aquí. La documentación de la característica OCSP de Tomcat es explícita en que el mecanismo valida los certificados proporcionados por el cliente. Eso significa que la vulnerabilidad tiene que ver con quién entra, no con qué certificado de servidor acepta un navegador. Dicho de otro modo, CVE-2026-24734 es un fallo en el límite de autenticación y autorización en despliegues de servidores habilitados para mTLS, no una ruptura genérica de la confidencialidad HTTPS para visitantes arbitrarios. (Apache Tomcat)

Por qué es fácil equivocarse en la validación OCSP

OCSP parece sencillo si se reduce a una etiqueta de estado. Pregunta si un certificado es bueno, revocado o desconocido. Lea la respuesta. Siga adelante. Ese modelo mental es lo suficientemente incompleto como para resultar peligroso. El RFC 6960 define OCSP como un protocolo para determinar el estado actual de un certificado digital sin necesidad de CRL completas. El mismo RFC detalla la semántica de thisUpdate, nextUpdate, producidoEny revocationTime. También afirma que la extensión nonce vincula criptográficamente una solicitud y una respuesta para evitar ataques de repetición. Estos detalles no son un adorno opcional. Forman parte de lo que hace que una respuesta OCSP sea fiable y no simplemente esté bien formada. (datatracker.ietf.org)

RFC 6960 dice thisUpdate es el momento más reciente en el que el respondedor sabe que el estado indicado era correcto, y nextUpdate es el momento en el que se dispondrá de información más reciente, o antes. Añade una regla sutil pero importante: las respuestas cuya nextUpdate es anterior a la hora local deben considerarse poco fiables, y las respuestas cuyo thisUpdate es posterior a la hora local también debería considerarse poco fiable. La RFC también señala que si nextUpdate no está establecido, el respondedor está diciendo efectivamente que la nueva información de revocación puede estar disponible todo el tiempo. Esto significa que una implementación no puede reducir con seguridad el manejo de OCSP a "el campo de estado dice bueno, así que he terminado". La semántica temporal forma parte de la decisión de confianza. (datatracker.ietf.org)

La propia documentación de OpenSSL hace la misma observación en términos de biblioteca y no de protocolo. La dirección OCSP_check_validity() la documentación dice que la función comprueba thisupd y nexttupdpermite un margen configurable para la desviación del reloj y puede limitar la antigüedad máxima de una respuesta. La página de manual de OpenSSL también explica que las aplicaciones normalmente recuperan el estado del certificado y luego comprueban su validez, y advierte explícitamente que si nextUpdate está ausente, una respuesta antigua podría parecer válida a menos que se apliquen límites máximos de antigüedad. OpenSSL también documenta OCSP_basic_verify() como el mecanismo que comprueba que la respuesta básica está correctamente firmada y que el certificado del firmante puede ser validado. De nuevo, el patrón es claro: una respuesta OCSP fiable requiere al menos la búsqueda de estado, la verificación de la firma, la validación del firmante y la lógica de frescura. (docs.openssl.org)

El nonce es importante por otra razón. RFC 6960 dice que el nonce vincula la solicitud y la respuesta para evitar la repetición. Sin esa vinculación, una respuesta técnicamente analizable puede ser la respuesta incorrecta para la transacción actual. En entornos donde el estado de revocación cambia rápidamente o donde los atacantes pueden reproducir material previamente observado, esto no es una preocupación teórica. La frescura sin vinculación solicitud-respuesta es más débil de lo que muchos equipos suponen. La verificación de firmas sin frescura también es más débil de lo que los equipos suponen. Las tres propiedades tienen que coincidir. (datatracker.ietf.org)

Esta visión más amplia explica por qué CVE-2026-24734 no es "sólo un caso extremo de OCSP". Es un ejemplo concreto de una trampa de implementación recurrente en los sistemas de identidad. Los ingenieros suelen tener cuidado con la validación de la cadena y el análisis sintáctico básico de los certificados, y luego tratan la revocación como un paso suplementario. En realidad, la revocación forma parte de la propia decisión de identidad. Un certificado que se encadena correctamente pero se revoca no es un éxito menor. Es un fracaso. Cualquier brecha de implementación que acepte un certificado así socava el significado de toda la política mTLS que lo envuelve. (Apache Tomcat)

Qué ha cambiado Apache en el parche

La forma más rápida de entender CVE-2026-24734 es echar un vistazo a la corrección. Apache's Tomcat commit e76e9ea se titula "Extend OCSP checks for OpenSSL to align with JSSE". Ese commit es más revelador que el breve texto del aviso porque muestra exactamente qué comprobaciones faltaban en la ruta FFM de OpenSSL y cuáles se han añadido. Los cambios no son cosméticos. Añaden validación de nonce solicitud-respuesta, verificación de firma y firmante de respuesta, comprobaciones de validez explícitas sobre thisUpdate y nextUpdateEl usuario puede configurar el tiempo de espera de OCSP y los indicadores de verificación de OpenSSL. (GitHub)

Una de las incorporaciones más importantes es OCSP_check_nonce(ocspRequest, basicResponse). El parche trata una falta de coincidencia de nonce como una respuesta OCSP no válida y devuelve un estado desconocido con un error establecido en el contexto de verificación. Esto es importante porque RFC 6960 define nonce como el enlace anti-reproducción entre la solicitud y la respuesta. Si la implementación estaba previamente dispuesta a aceptar una respuesta sin comprobar esa vinculación, entonces no estaba estableciendo completamente que la respuesta perteneciera realmente a la solicitud en vuelo. (GitHub)

El parche también añade OCSP_basic_verify(basicResponse, certStack, X509_STORE_CTX_get0_store(x509ctx), state.ocspVerifyFlags). Documentos de OpenSSL OCSP_basic_verify() como comprobar que la respuesta está correctamente firmada y que el certificado del firmante puede ser validado, utilizando el almacén de confianza y cualquier intermediario suministrado. Se trata de una mejora importante de la garantía en comparación con la simple extracción de un campo de estado. A bien de un respondedor no fiable o validado incorrectamente no es una base aceptable para permitir que un certificado de cliente revocado pase por el protocolo TLS. El manejo de errores del parche refleja esa lógica al asignar la verificación básica fallida a X509_V_ERR_OCSP_SIGNATURE_FAILURE. (GitHub)

Igual de importantes son las comprobaciones de frescura. La ruta del código antiguo, tal y como refleja el diff, obtenía previamente la respuesta única y luego devolvía el estado sin el flujo de validación temporal más completo que ahora se puede ver en el parche. El código corregido extrae thisUpdate y nextUpdatey, a continuación, llama a OCSP_check_validity() dos veces: una para detectar respuestas aún no válidas y otra para detectar respuestas caducadas, con asignación explícita a X509_V_ERR_OCSP_NOT_YET_VALID y X509_V_ERR_OCSP_HAS_EXPIRED. La documentación de OpenSSL dice OCSP_check_validity() es la función responsable de evaluar esas marcas de tiempo y de limitar la antigüedad de la respuesta. Esto significa que el parche no sólo mejora la higiene. Repara la semántica de confianza que decide si se puede seguir confiando en una respuesta OCSP. (GitHub)

Los cambios en la configuración también son significativos. La confirmación introduce soporte para OCSP_TIMEOUT y OCSP_VERIFY_FLAGS en la ruta del código FFM de OpenSSL, y la referencia de configuración de Tomcat ahora documenta ocspVerify como el atributo que pasa los indicadores de verificación a OCSP_basic_verify para implementaciones TLS basadas en OpenSSL. También documenta ocspSoftFailcon un valor por defecto de falsolo que significa que un fallo en la comprobación OCSP debería fallar el protocolo TLS a menos que se active explícitamente el fallo suave. Estos controles no existen en el vacío. Muestran que Apache trató la corrección no como una reparación de errores de una sola línea, sino como parte de un esfuerzo más amplio para hacer el manejo de OCSP explícito, configurable y mejor alineado con el modelo de seguridad pretendido. (GitHub)

El lado de Tomcat Native cuenta una historia paralela. Native 2.0.12 y 1.3.5 se lanzaron en enero de 2026 con notas de lanzamiento que decían que ampliaban la verificación de las respuestas OCSP y añadían opciones para configurar el comportamiento OCSP. Luego, en febrero y marzo de 2026, continuó el endurecimiento de Native, incluyendo un cambio para eliminar un error adicional en el procesamiento OCSP para que el soft fail se comportara correctamente con el conector APR/native. Ese trabajo posterior se convirtió en CVE-2026-29145. Esta secuencia es importante porque muestra que el área de código no se parcheó una vez y ya está; se estaba corrigiendo activamente hacia un modelo OCSP más estricto y coherente. (Apache Tomcat)

Cuando CVE-2026-24734 se convierte en una vía de ataque real

La forma más limpia de pensar en la explotación no es "¿Puedo disparar una cadena de exploit a Tomcat?", sino "¿Puedo presentar una identidad de cliente que debería haber sido eliminada y aún así ser aceptada?". En los entornos en los que importa esta CVE, el activo del atacante suele ser un certificado de cliente y su correspondiente clave privada que una vez fueron válidos pero en los que ya no se debería confiar. Esto puede ocurrir porque un empleado se ha marchado, un contratista ha perdido el acceso, un dispositivo se ha retirado, una relación con un socio ha terminado o una clave ha quedado expuesta durante algún otro incidente. En un sistema sano, la revocación cierra esa puerta. En uno vulnerable, el servidor puede seguir dispuesto a abrirla. (Grupos de Google)

Un ejemplo realista es una API de socios protegida por TLS mutuo. El certificado del socio se revoca tras un compromiso o la rescisión del contrato. El socio, o cualquiera que ahora posea la antigua clave privada, debería perder inmediatamente el acceso. Si el borde de Tomcat que aplica esa decisión de identidad está en el rango afectado y confía en la ruta OCSP vulnerable, la decisión de revocación del certificado puede fallar. El acceso ya no está controlado por el último estado de confianza de la autoridad de certificación, sino por la interpretación incompleta de las respuestas OCSP por parte del servidor. Por este motivo, algunos ecosistemas describen el problema en términos de autorización en lugar de simplemente en términos de validación de entrada. El defecto reside en la lógica de validación, pero el resultado operativo es una decisión de confianza que debería fallar y no lo hace. (nvd.nist.gov)

El mismo patrón se aplica a las mallas de servicios internos y a las plataformas de máquina a máquina que utilizan mTLS menos como función de transporte y más como prueba de adhesión. Muchos equipos asumen que como los certificados son artefactos PKI privados y los puntos finales son internos, la amenaza es menor. Lo contrario puede ser cierto. Los mTLS internos a menudo ocultan funciones administrativas, sistemas de orquestación, rutas de datos sensibles o puntos de estrangulamiento de movimiento lateral. Si una credencial de cliente revocada sigue autenticando, ese es exactamente el tipo de brecha que un atacante con un punto de apoyo parcial, material de dispositivo obsoleto o claves filtradas quiere encontrar. Que la ubicación de la red sea "interna" no salva a un sistema de una mala semántica de confianza. (Apache Tomcat)

Lo que esta CVE no describe de forma natural es el compromiso remoto anónimo de sitios Tomcat públicos ordinarios que no utilizan comprobaciones OCSP de certificados de cliente. Por eso, titulares como "Servidor Tomcat vulnerable a través de la red" no son útiles en este caso. El vector de ataque a través de la red en CVSS refleja que el fallo puede ejercerse a través de rutas de autenticación en red sin privilegios previos, no que todas las implementaciones de Tomcat en Internet estén igualmente expuestas. La diferencia es importante a la hora de clasificar la urgencia de los parches en las flotas. Los equipos deben dar prioridad a los sistemas en los que se supone que la revocación de certificados funciona como un límite de control de acceso activo. (nvd.nist.gov)

Quién está probablemente afectado y quién no

La forma más rápida de reaccionar exageradamente a CVE-2026-24734 es tratar cada instancia de Tomcat como igualmente vulnerable. La forma más rápida de no reaccionar es asumir que, como nunca se instaló explícitamente "Tomcat Native" como un producto separado, se está a salvo. Ambos atajos fallan porque la exposición real depende de la combinación de la versión, la implementación del conector, el modelo de autenticación de certificados y el uso de OCSP. (nvd.nist.gov)

Una implantación se encuentra en la categoría de mayor riesgo cuando se dan cuatro condiciones. En primer lugar, utiliza un rango de versiones vulnerable de Tomcat o Tomcat Native. En segundo lugar, utiliza una ruta de conector respaldada por OpenSSL que coincide con el soporte de funciones OCSP de Tomcat, como APR/native, OpenSSL JSSE o la implementación OpenSSL Panama FFM. En tercer lugar, realiza la validación del certificado del cliente de una forma que depende de OCSP. Cuarto, esos certificados de cliente llevan un URI de respuesta OCSP, porque la documentación de Tomcat dice que valida los certificados de cliente usando el URI de respuesta incrustado en la extensión de Acceso a Información de Autoridad. Si falta alguna de estas piezas, el riesgo práctico se reduce drásticamente. (Apache Tomcat)

Una implementación simple de JSSE sin estas comprobaciones OCSP respaldadas por OpenSSL no parece coincidir con la ruta vulnerable que Apache describió para esta CVE. Esta conclusión se basa en el propio alcance de las características de Tomcat: la documentación de soporte OCSP enumera los tipos de conectores y dice explícitamente que OCSP no está soportado con org.apache.tomcat.util.net.jsse.JSSEImplementation o el estilo de configuración de JSSE. Esto no es lo mismo que decir que cada despliegue de JSSE es inmune a cualquier error de validación de certificados para siempre. Es simplemente la lectura más cuidadosa de la ruta vulnerable descrita para CVE-2026-24734. (Apache Tomcat)

Una aplicación Java embebida merece una atención especial. Muchos equipos piensan en paquetes de servidor mientras que su realidad de producción es una aplicación Spring Boot con Tomcat incrustado. La base de datos de avisos de GitHub rastrea los rangos vulnerables en tomcat-embed-core y tomcat-coyote lo que significa que el análisis de la composición del software, los manifiestos de compilación y los árboles de dependencias pertenecen a la revisión de la exposición. Un equipo puede estar ejecutando no /opt/tomcat instalación en absoluto y aún así llevar la ruta de código vulnerable en un artefacto de aplicación. (GitHub)

Por lo tanto, la pregunta de triaje práctica más rápida no es "¿Ejecutamos Tomcat?" sino "¿Dónde terminamos la autenticación de cliente mTLS en Tomcat, con revocación de certificado respaldada por OCSP, a través de un conector respaldado por OpenSSL, en uno de los rangos de versiones afectados?". Esa pregunta es más estrecha, más procesable y más cercana al radio de explosión real. (Apache Tomcat)

Cómo determinar la exposición en su entorno

Comience con el inventario de versiones. En una instalación independiente de Tomcat, confirme primero el tren de ejecución y el nivel de parche. En aplicaciones integradas, inspeccione los manifiestos de dependencia y los archivos de bloqueo. En cargas de trabajo en contenedores, inspeccione el contenido de la imagen y las bibliotecas incluidas de la aplicación. No se trata sólo de encontrar "Tomcat en alguna parte". Es mapear cada carga de trabajo a los rangos de versión Apache y NVD realmente marcados como afectados. (nvd.nist.gov)

Una primera pasada sencilla en una instalación tradicional tiene este aspecto:

# Versión de Tomcat autónomo
$CATALINA_HOME/bin/catalina.sh versión

# Buscar presencia de librerías nativas
find "$CATALINA_HOME" "$CATALINA_BASE" -iname '*tcnative*' -o -iname 'libtcnative*' 2>/dev/null

# Imagen contenedora o inventario de paquetes
rpm -qa | grep -Ei 'tomcat|tcnative'
dpkg -l | grep -Ei 'tomcat|tcnative'

En el caso de las aplicaciones Java integradas, la inspección de dependencias es igual de importante, ya que las bases de datos de asesoramiento asignan el CVE a las coordenadas de los paquetes, así como a las versiones del servidor. (GitHub)

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

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

A continuación, identifique si la aplicación está utilizando las familias de conectores que Tomcat documenta para OCSP. La guía SSL/TLS de Tomcat muestra los tipos de conectores relevantes y el estilo de configuración. Usted está buscando signos de APR/nativo, OpenSSLImplementationo la implementación OpenSSL de Panamá, además de la configuración de verificación de certificados y la configuración relacionada con OCSP. Un barrido rápido de configuración suele responder a esto en cuestión de minutos. (Apache Tomcat)

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

El propio ejemplo de conector OCSP de Tomcat es un buen ejemplo de cómo debe ser una configuración relevante. La documentación muestra un conector APR/nativo con certificateVerification="exigir" y un certificado configurado en SSLHostConfigentonces se inicia un proceso de respuesta OCSP con el código OpenSSL ocsp herramienta. Si su servidor no tiene nada parecido a ese modelo, las probabilidades de que CVE-2026-24734 sea su problema urgente son menores. Si es así, deberías seguir investigando. (Apache Tomcat)

Un ejemplo simplificado cercano al patrón documentado tiene este aspecto:

Después de la configuración, compruebe si los certificados de cliente en juego llevan realmente un URI de respuesta OCSP en la extensión de acceso a la información de autoridad. La guía OCSP de Tomcat dice que el certificado necesita tener codificada la ubicación del respondedor. Sin eso, puede que la ruta de validación OCSP prevista ni siquiera esté activa. (Apache Tomcat)

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

Por último, confirme si la aplicación depende realmente de la autenticación cliente-certificado como límite de seguridad. En muchas flotas, TLS está habilitado en todas partes, pero mTLS sólo está habilitado en un pequeño subconjunto de conectores, rutas o servicios. El impacto empresarial de CVE-2026-24734 vive donde la aceptación del certificado equivale a la autorización para hacer algo significativo. Haga un inventario de los planos de administración, los puntos finales de los socios, los servicios de incorporación de dispositivos, las API internas y las identidades de máquinas en los que esa afirmación es cierta. Ese ejercicio de alcance suele ser más importante que el recuento de hosts en bruto. (Apache Tomcat)

Validación de laboratorio segura para CVE-2026-24734

La forma correcta de validar esta cuestión no es improvisar contra la producción. Es reproducir la decisión de confianza en un laboratorio que usted controle, y luego comparar el comportamiento antes y después de parchear. La documentación de Tomcat ya proporciona la mayoría de los bloques de construcción: cómo crear certificados habilitados para OCSP, cómo configurar un conector habilitado para OCSP y cómo iniciar un respondedor OCSP básico usando OpenSSL. El trabajo aquí es convertir esas piezas en una prueba controlada de revocación-aceptación. (Apache Tomcat)

La parte de generación de certificados comienza con una configuración de CA OpenSSL que incrusta un URI de respuesta OCSP en el certificado emitido a través de la extensión de acceso a información de autoridad. La documentación de Tomcat muestra la línea relevante como authorityInfoAccess = OCSP;URI:http://127.0.0.1:8088. No es una extensión decorativa. Es la forma en que Tomcat sabe dónde preguntar por el estado del certificado del cliente. Después de eso, el flujo documentado crea una clave privada, crea un CSR, lo firma, y luego verifica el certificado resultante. (Apache Tomcat)

# Crear una clave privada
openssl genrsa -aes256 -out ocsp-cert.key 4096

# Crear una CSR
openssl req -config openssl.cnf -new -sha256 \
  -key ocsp-cert.key -out ocsp-cert.csr

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

# Inspeccionar el certificado para AIA / OCSP
openssl x509 -noout -text -in ocsp-cert.crt

En el lado del servidor, utilice un conector Tomcat que coincida con las rutas documentadas aptas para OCSP. Si desea reproducir el ejemplo APR/native de la documentación oficial, utilice el protocolo APR. Si desea probar la ruta FFM específicamente, utilice la implementación documentada de OpenSSL Panama en una versión de Java que admita esa función. El punto clave es que tu entorno de prueba debe parecerse a una de las familias de conectores que Tomcat dice que soporta OCSP. De lo contrario, no estará validando la ruta de código que cubre realmente esta CVE. (Apache Tomcat)

La documentación de Tomcat también proporciona un comando de respuesta OpenSSL básico:

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

Con esto en su lugar, una secuencia de laboratorio útil es simple. En primer lugar, emita un certificado de cliente desde su CA de prueba y confirme que un cliente con ese certificado puede completar el protocolo de enlace mTLS y llegar al punto final protegido. En segundo lugar, revoque ese certificado de cliente en su índice de CA y actualice el estado del respondedor OCSP en consecuencia. Tercero, vuelva a ejecutar exactamente el mismo intento de conexión contra una compilación vulnerable y contra una compilación corregida. La cuestión no es si Tomcat registra algo interesante. La cuestión es si un certificado de cliente ahora revocado sigue siendo aceptado. Esa es la decisión de confianza de la que trata CVE-2026-24734. (Apache Tomcat)

Un cliente de prueba defensivo puede ser tan sencillo como openssl s_client con el certificado y la clave del cliente:

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

Trate el resultado con cuidado. Un fallo en el apretón de manos tras la revocación es el resultado saludable esperado. Un handshake exitoso con el certificado revocado es la condición de fallo. Si desea una mayor capacidad de observación durante las pruebas, la guía SSL/TLS de Tomcat recomienda habilitar el registrador de depuración de handshake TLS dedicado en logging.propertiesutilizando nombres de registro como org.apache.tomcat.util.net.NioEndpoint.handshake.level=FINE o org.apache.tomcat.util.net.Nio2Endpoint.handshake.level=FINE dependiendo del conector en juego. Ese registro no le dirá mágicamente "CVE-2026-24734 ocurrió", pero puede ayudarle a distinguir una mala configuración TLS ordinaria del resultado de confianza específico que está intentando validar. (Apache Tomcat)

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

Una precaución práctica importa aquí. La documentación de Tomcat indica que cuando se utiliza OCSP, el respondedor codificado en el certificado debe estar en ejecución. Parece obvio, pero afecta a la interpretación de las pruebas. Si el respondedor no está disponible, el comportamiento de fallo suave y el comportamiento de tiempo de espera se convierten en parte del resultado. Y esa es exactamente la razón por la que el trabajo posterior de endurecimiento de OCSP, incluyendo ocspSoftFail, ocspVerify, la gestión del tiempo de espera y las correcciones de CVE-2026-29145 de marzo de 2026, deben tenerse en cuenta mientras se valida. Un sistema puede pasar de una ruta de confianza rota a otra si los equipos validan sólo el caso del día soleado. (Apache Tomcat)

Lo que los defensores pueden detectar, y lo que normalmente no pueden

CVE-2026-24734 no es una vulnerabilidad rica en IOC. No hay un URI canónico de explotación para buscar en los registros de acceso. No hay una excepción de aplicación obvia que grite "se aceptó un certificado revocado". En muchos entornos, la señal peligrosa es la opuesta a una señal de fallo: una conexión tiene éxito cuando la organización cree que debería haber fallado. Esto desplaza la detección desde el análisis genérico de registros hacia la validación de controles y las pruebas entre sistemas. (Grupos de Google)

La mejor técnica defensiva inmediata es la verificación activa. Cree un pequeño conjunto de certificados de cliente de prueba cuyo ciclo de vida controle. Revoca uno. Intente el apretón de manos. Confirme el rechazo. Repítalo después de actualizaciones, cambios en el almacén de certificados, cambios en el conector, actualizaciones de Java y cambios en el respondedor OCSP. Este estilo de prueba es más valioso en este caso que esperar a que SIEM infiera un sutil fallo de confianza a partir de telemetría de propósito general. Tanto el RFC 6960 como el modelo de validez de OpenSSL dejan claro que la frescura y la vinculación solicitud-respuesta forman parte de la decisión de confianza. La única forma fiable de saber que tu pila sigue aplicando esa semántica después de un cambio es volver a ejercitarla. (datatracker.ietf.org)

La telemetría pasiva sigue teniendo un papel, pero es indirecto. Si su PKI o fuente de verdad IAM dice que un certificado de cliente está revocado, mientras que los registros de acceso del lado de la aplicación, los registros de puerta de enlace o los registros de auditoría descendentes siguen mostrando sesiones autenticadas con éxito vinculadas a esa identidad de certificado, esa discrepancia es significativa. En tiendas maduras, el inventario de certificados, los registros de revocación y los registros de acceso a la aplicación deberían ser lo suficientemente comparables como para detectar este tipo de desviación. No se trata de que Tomcat emita una alerta perfecta de "desviación de revocación". La cuestión es que tu plano de control debería dificultar que las credenciales muertas sigan apareciendo en rutas de autenticación correctas sin que nadie se dé cuenta. (datatracker.ietf.org)

El registro de depuración de handshake de Tomcat es útil durante el triaje porque muestra dónde está fallando o procediendo el handshake, y porque los problemas de validación de certificados a menudo colapsan en ruido TLS genérico. No es una estrategia de detección completa, y no debería dejarse activada en todas partes para siempre. Pero durante las ventanas de verificación, la revisión de incidentes o las repeticiones de pruebas controladas, ofrece a los defensores una mejor perspectiva del comportamiento relacionado con OCSP que los registros de solicitudes normales. (Apache Tomcat)

Corrección y refuerzo de las rutas OCSP de Apache Tomcat

El remedio mínimo está claro: pasar a versiones fijas o posteriores. Eso significa Tomcat Native 1.3.5 o 2.0.12 y Apache Tomcat 9.0.115, 10.1.52, o 11.0.18 como mínimo, dependiendo de su tren. Pero "o más tarde" está haciendo un trabajo importante ahí. Apache continuó enviando correcciones relacionadas con OCSP después de la revelación original. Para los equipos que tratan los certificados de cliente como un control de acceso significativo, la postura más prudente es pasar a una versión de mantenimiento actual en lugar de quedarse exactamente en la primera versión parcheada para siempre. (nvd.nist.gov)

Si está en las antiguas ramas Native al final de su vida útil que NVD todavía enumera como afectadas conocidas, este no es el lugar para llevar parches heroicos. La aplicación de la revocación es la lógica central de la identidad. Ejecutar ramas muertas que ya se sabe que tienen problemas OCSP históricos, mientras que también carecen del beneficio del trabajo de endurecimiento posterior, es el tipo de deuda técnica que falla más durante la respuesta a incidentes. La migración suele ser la respuesta más segura y, en última instancia, más barata. (nvd.nist.gov)

Tras la actualización, vuelva a probar con los certificados revocados. Esto suena mundano, pero es el paso más importante que los equipos se saltan. Un salto de versión puede decirle que el proveedor ha enviado una corrección. No le dice que su entorno está ejerciendo la ruta fija de la manera que usted cree, que su respondedor OCSP está devolviendo la semántica que usted espera, o que su selección y configuración del conector todavía se alinean después de otros cambios. La aceptación de parches sin volver a probar el certificado revocado es una suposición de confianza, no una prueba. (GitHub)

Sea explícito sobre la política OCSP. Documentos de referencia de configuración de Tomcat ocspSoftFail y ocspVerifyy el trabajo de parcheado añadió soporte para los indicadores de tiempo de espera y verificación en la ruta FFM. Esto significa que el comportamiento crítico para la seguridad no está totalmente capturado por "OCSP está activado". Los equipos deben documentar si se permite el fallo suave, qué comportamiento de tiempo de espera es aceptable, si el almacén de confianza y los indicadores de verificación se establecen intencionadamente y cómo debe comportarse el sistema cuando el respondedor no está disponible o se retrasa. La ambigüedad en torno a estas opciones puede convertirse en una política de seguridad de producción por accidente. (Apache Tomcat)

Los controles compensatorios pueden reducir la exposición mientras se llevan a cabo las actualizaciones, pero no sustituyen a la aplicación de revocaciones fijas. En las interfaces de mayor valor, combine mTLS con una menor exposición a la red, autorización explícita en la capa de aplicación, certificados de cliente de corta duración y flujos de trabajo de sustitución rápida de certificados. Estos controles son importantes porque reducen el valor de un certificado obsoleto o comprometido, incluso si la gestión de la revocación es temporalmente imperfecta. No restauran la garantía que falta de que un certificado revocado está realmente muerto. Eso sólo lo consigue una ruta de confianza fija y verificada. (datatracker.ietf.org)

Hay un aspecto del flujo de trabajo que a menudo se pasa por alto. Lo difícil no es encontrar un comando shell para probar un conector. Es mantener el alcance de los activos, el inventario de versiones, las huellas digitales del conector, la inspección de certificados, la repetición de pruebas y la recopilación de pruebas unidas cada vez que se produce un lanzamiento, una rotación de certificados o un cambio en la PKI. Los materiales públicos de Penligent hacen hincapié en los flujos de trabajo agénticos bajo control humano, el acceso con un solo clic a una gran superficie de herramientas Kali y la verificación más la generación de informes como un bucle conectado. En la práctica, esa es la forma de trabajo que los defensores necesitan después de un fallo como este: no sólo parches, sino pruebas repetibles de que la ruta de confianza vulnerable ha desaparecido en los sistemas que realmente importan. (penligent.ai)

CVEs relacionados que hacen que CVE-2026-24734 sea más importante, no menos

Una razón para tomar en serio CVE-2026-24734 es que no vive aislado. El historial de seguridad de Tomcat Native contiene problemas anteriores relacionados con OCSP que afectaban a la aplicación de la revocación, lo que hace que esto sea menos un hecho aislado y más un recordatorio de que es fácil equivocarse sutilmente en el manejo del estado de los certificados. La página de seguridad de Apache Native es especialmente útil aquí porque muestra el linaje en un solo lugar. (Apache Tomcat)

CVE-2017-15698 era una omisión de comprobación OCSP en Tomcat Native. Apache dice que al analizar la extensión AIA de un certificado de cliente, el conector no manejaba correctamente los campos de más de 127 bytes, lo que provocaba que se omitiera la comprobación OCSP. El impacto era directo: los certificados de cliente que deberían haber sido rechazados si se hubiera ejecutado la comprobación OCSP podían ser aceptados en su lugar. Se trata de un error de implementación diferente de CVE-2026-24734, pero el tema es idéntico. La lógica de revocación es crítica para la seguridad, y errores de análisis o validación aparentemente secundarios pueden neutralizarla. (Apache Tomcat)

CVE-2018-8019 y CVE-2018-8020 empujaban en la misma dirección. En un caso, las respuestas OCSP no válidas se manejaban incorrectamente, lo que permitía que los certificados de cliente revocados se identificaran incorrectamente. En el otro, Tomcat Native comprobaba incorrectamente las respuestas OCSP preproducidas que contenían listas de estados de certificados, creando de nuevo espacio para que certificados de cliente revocados se colaran en conexiones que requerían TLS mutuo. Estos problemas antiguos son valiosos porque enseñan el instinto correcto: cuando se trata de la gestión de OCSP, no hay que detenerse en la sintaxis o los campos de estado. Confirme que la autorización para responder, la estructura de la respuesta, la frescura de la respuesta y la identidad exacta del certificado que se está evaluando se están gestionando correctamente. (Apache Tomcat)

Luego viene CVE-2026-24734, que corrige comprobaciones incompletas de verificación y frescura en las rutas Native y FFM. Y poco después aparece CVE-2026-29145, con Apache declarando que CLIENTE_CERT la autenticación no fallaba las comprobaciones OCSP como se esperaba en algunos escenarios incluso cuando el fallo suave estaba desactivado. Este problema posterior no prueba que la solución original fuera errónea. Es una prueba de que el comportamiento de OCSP en casos operativos extremos sigue siendo lo suficientemente delicado como para que los equipos defensivos deban validar toda la ruta de confianza, no sólo asumir que "parcheado una vez" equivale a "resuelto para siempre". (Apache Tomcat)

Para los equipos que utilizan certificados de cliente en gran medida, otra lección cercana proviene de los problemas de elusión de verificación de certificados de Tomcat fuera de la familia OCSP. Apache reveló CVE-2025-66614 como una desviación de verificación de certificado de cliente vinculada a la asignación de host virtual, y más tarde reveló CVE-2026-32990 como una corrección incompleta en esa área. La mecánica directa difiere de CVE-2026-24734, pero el mensaje operativo es el mismo: los límites de confianza basados en certificados en Tomcat merecen una revisión continua, porque el comportamiento del conector, la coincidencia de host y la lógica de revocación pueden convertirse en fallos de autorización si se implementan o configuran incorrectamente. (Apache Tomcat)

CVE	Zona	Por qué es importante	Clase práctica
CVE-2017-15698	Comprobación OCSP omitida	Un error de análisis de AIA podría saltarse OCSP por completo	Nunca asuma que "OCSP activado" significa "OCSP aplicado".
CVE-2018-8019	Gestión de respuesta OCSP no válida	Los certificados de cliente revocados podrían ser identificados erróneamente	La gestión del formato de respuesta forma parte de la corrección de la autenticación
CVE-2018-8020	Gestión de respuestas OCSP preproducidas	Los certificados de cliente revocados podían seguir autenticándose	La lógica de respuesta en caché o empaquetada necesita una validación estricta
CVE-2026-24734	Verificación y controles de frescura incompletos	La revocación puede eludirse	La firma, el nonce y la frescura son importantes
CVE-2026-29145	Casos extremos de comportamiento ante fallos blandos	CLIENTE_CERT auth aún podría fallar suavemente	Parchear, luego volver a probar las condiciones de los bordes, no sólo los caminos felices.

Pruebas, informes y nuevas pruebas después del parche

Una vez realizada la corrección, el trabajo no estará completo hasta que las pruebas sean lo suficientemente buenas como para que otro ingeniero, un auditor o tu yo futuro puedan responder a tres preguntas sin adivinar: qué sistema se vio afectado, qué cambió y qué prueba exacta demostró que la ruta del certificado revocado ahora falla. Esto significa preservar la configuración del conector que importaba, la identidad del certificado utilizado en la prueba, el evento de revocación, el comportamiento del apretón de manos antes y después, y el estado exacto de la versión de Tomcat o Tomcat Native durante cada ejecución. Una buena prueba de remediación es concreta o no es útil. (Apache Tomcat)

Ese es también el punto en el que la ayuda de la IA ayuda o perjudica. Una vaga nota generada por la IA que diga "actualizado y vuelto a probar con éxito" no es una prueba. La guía de informes de Penligent acierta en la parte correcta de este problema: un informe de pentest o validación sólido necesita una ubicación clara, una declaración de impacto concreta, pasos de reproducción y artefactos de apoyo en lugar de una prosa de modelo genérico. Esa mentalidad es exactamente la que necesita la validación posterior al parche de CVE-2026-24734. Un buen registro debería permitir a otro ingeniero reproducir la decisión de confianza, no simplemente confiar en que ya lo has hecho. (penligent.ai)

La verdadera lección de CVE-2026-24734

CVE-2026-24734 es una vulnerabilidad útil porque expone un hábito de seguridad común: muchos sistemas tratan la confianza en los certificados como una propiedad estática cuando en realidad es una decisión en vivo. Un certificado puede estar bien formado, firmado por el emisor correcto, y aún así no ser de confianza porque el emisor lo ha revocado. Se supone que OCSP lleva esa decisión en vivo al protocolo TLS. Si la implementación no verifica el respondedor correctamente, no vincula la solicitud y la respuesta correctamente, o no aplica la frescura correctamente, entonces el sistema ya no está tomando una decisión de confianza viva. Está tomando una decisión obsoleta. (datatracker.ietf.org)

Por eso esta CVE merece más atención de lo que sugiere su perfil de titular. Para los equipos que utilizan Tomcat para terminar HTTPS ordinario sin certificados de cliente, el fallo puede ser un elemento de parche de bajo drama. Para los equipos que utilizan mTLS como límite real, es una prueba directa de si las identidades revocadas realmente mueren cuando la organización dice que deberían. Apache ha solucionado el problema. El trabajo restante corresponde a los defensores: identificar dónde existía la ruta de confianza vulnerable, pasar a las versiones soportadas actuales, validar con certificados revocados y seguir haciéndolo siempre que cambie la PKI, la pila de conectores o el límite de identidad. (Grupos de Google)

Lecturas complementarias y referencias

• Entrada NVD para CVE-2026-24734, versiones afectadas, CVSS y conjunto de referencias. (nvd.nist.gov)
• Texto del aviso de Apache con gravedad, versiones afectadas, mitigación y crédito a Joshua Rogers. (Grupos de Google)
• Entrada de la página de seguridad de Apache Tomcat 9 para CVE-2026-24734 y su continuación relacionada con OCSP CVE-2026-29145. (Apache Tomcat)
• Entrada de la página de seguridad de Apache Tomcat 10.1 para CVE-2026-24734 y su continuación posterior relacionada con OCSP CVE-2026-29145. (Apache Tomcat)
• Entrada de la página de seguridad de Apache Tomcat 11 para CVE-2026-24734 y su continuación relacionada con OCSP CVE-2026-29145. (Apache Tomcat)
• Página de seguridad nativa de Apache Tomcat para CVE-2026-24734, además de linaje OCSP anterior que incluye CVE-2017-15698, CVE-2018-8019 y CVE-2018-8020. (Apache Tomcat)
• Notas de la versión de Apache Tomcat que muestran las versiones corregidas de enero de 2026 y la evolución continua relacionada con OCSP en versiones posteriores. (Apache Tomcat)
• Documentación de OCSP SSL/TLS de Tomcat que cubre las familias de conectores compatibles, el enfoque cliente-certificado, los requisitos de AIA, el ejemplo de conector, el inicio del respondedor y el registro de handshake. (Apache Tomcat)
• Referencia de configuración del conector Tomcat para ocspEnabled, ocspSoftFaily ocspVerify. (Apache Tomcat)
• Documentación de OpenSSL para OCSP_basic_verify, OCSP_check_validityextracción de estado y gestión de la edad de respuesta. (docs.openssl.org)
• RFC 6960 para la semántica OCSP, incluyendo thisUpdate, nextUpdate, producidoEny nonce. (datatracker.ietf.org)
• Apache Tomcat fix commit e76e9eaque muestra las comprobaciones añadidas de nonce, firma y frescura en la ruta FFM de OpenSSL. (GitHub)
• Confirmación de seguimiento de Tomcat Native 69a977dlo que ayuda a explicar por qué el endurecimiento posterior de OCSP continuó después de la revelación original. (GitHub)
• Página de inicio de Penligent para información pública sobre productos en torno a flujos de trabajo agénticos, acceso a herramientas y verificación, además de informes. (penligent.ai)
• Project Glasswing Shows Why AI Defense Needs Continuous Penetration Testing, para el caso más amplio de que los controles de seguridad necesitan una verificación adversarial recurrente en lugar de suposiciones de una sola vez. (penligent.ai)
• How to Get an AI Pentest Report, para obtener orientación práctica sobre la calidad de las pruebas, los detalles de reproducción y los artefactos de apoyo en los informes de seguridad. (penligent.ai)