¿Qué son las vulnerabilidades de Apache Tomcat? Detección, soluciones y consejos

Principales conclusiones

• La mayor parte del riesgo asociado a Tomcat proviene de vulnerabilidades CVE conocidas y sin parchear en versiones antiguas o que han llegado al final de su ciclo de vida.
• Las vulnerabilidades de alto impacto, como CVE-2025-24813 y Ghostcat, requieren una configuración específica de alto riesgo para activarse.
• La detección comienza por conocer todas las versiones de Tomcat que se ejecutan y qué configuraciones de riesgo están activadas.
• Actualiza siempre que puedas, aplica medidas de mitigación en la configuración cuando no sea posible, y nunca dejes expuestas las versiones que han llegado al final de su vida útil (EOL).

Un equipo habilita el acceso de escritura en el servlet predeterminado de Tomcat para permitir la función de subida de archivos, lo lanza al mercado y sigue adelante. Lo que se les pasa por alto es que la función «partial PUT» está activada por defecto, por lo que ahora se da una de las condiciones previas que dan lugar a la vulnerabilidad CVE-2025-24813. Si además esa aplicación utiliza la persistencia de sesiones basada en archivos de Tomcat en la ubicación de almacenamiento predeterminada y, por casualidad, incluye una biblioteca que puede ser objeto de abuso para la deserialización, el resultado es la ejecución remota de código sin autenticación. La CISA la tiene incluida en el catálogo de vulnerabilidades explotadas conocidas desde el 1 de abril de 2025.

Ese es el patrón recurrente que se esconde tras los incidentes relacionados con Tomcat. Rara vez se trata de un nuevo ataque ingenioso. Por lo general, se trata de un problema conocido que se ha dejado sin resolver en una versión antigua, o de una configuración arriesgada que nadie se ha molestado en revisar.

Esta guía repasa los riesgos, las vulnerabilidades CVE que conviene conocer y cómo detectar, corregir y reforzar la seguridad de tus servidores.

¿Cuáles son los riesgos que plantean las vulnerabilidades de Apache Tomcat?

Tomcat es uno de los contenedores de servlets de Java más utilizados, lo que lo convierte en un objetivo habitual. Cuando se descubre una vulnerabilidad, el alcance del impacto rara vez se limita a un solo servidor.

El peor de los casos es la ejecución remota de código, en la que un atacante ejecuta comandos arbitrarios en el servidor. Un nivel por debajo se encuentra la divulgación de información, en la que se leen archivos como web.xml, código fuente o claves de configuración sin necesidad de autenticación. A continuación está la inyección de contenido, en la que se introducen datos maliciosos en archivos subidos o en datos de sesión. Y cualquier instancia de Tomcat comprometida constituye un punto de apoyo ideal para el movimiento lateral hacia el resto de la red.

La realidad: la afirmación «Hemos actualizado, así que estamos a salvo» se desmorona si algunas instancias ejecutan una rama que ha llegado al final de su vida útil. Tomcat 8.5 alcanzó el final de su vida útil en el código fuente el 31 de marzo de 2024 y nunca recibió una corrección del código fuente para el CVE-2025-24813. Sin un proveedor que ofrezca parches tras el final de la vida útil, esos servidores siguen expuestos, independientemente del número de equipos que se hayan parcheado.

Vulnerabilidades habituales de Apache Tomcat

Las vulnerabilidades CVE de Tomcat se agrupan en torno a unos pocos temas. La gestión insegura de las solicitudes, la confianza en los protocolos, la resolución de rutas, la lógica de autenticación y los ajustes predeterminados de cifrado inseguros abarcan la mayoría de ellas. A continuación se enumeran las que conviene conocer, junto con las versiones afectadas y corregidas que publica Apache.

CVE-2025-24813 (Ejecución de código remoto parcial mediante PUT)

En este caso se combina un error de equivalencia de rutas con una deserialización insegura, y las condiciones previas son específicas, pero totalmente realistas. Las operaciones de escritura deben estar habilitadas en el servlet predeterminado, que por defecto está desactivado. La operación PUT parcial debe estar activada, lo cual ya está habilitado por defecto.

La aplicación debe utilizar la persistencia de sesiones basada en archivos de Tomcat en la ubicación de almacenamiento predeterminada. Además, la aplicación debe incluir una biblioteca que pueda ser objeto de un ataque de deserialización. Si se dan estas cuatro condiciones, un atacante puede preparar una carga útil serializada mediante una solicitud PUT parcial y, a continuación, activar su ejecución con una solicitud posterior que contenga el JSESSIONID correspondiente.

Se hizo pública el 10 de marzo de 2025, y la CISA la incluyó en el catálogo de «Vulnerabilidades explotadas conocidas» el 1 de abril de 2025.

CVE-2020-1938 (Ghostcat)

Ghostcat es una vulnerabilidad de lectura e inclusión de archivos en el conector AJP, que históricamente se distribuía habilitado en el puerto 8009 y vinculado a todas las direcciones configuradas. Un atacante remoto no autenticado que pudiera acceder a ese puerto era capaz de recuperar archivos arbitrarios de cualquier parte de la aplicación web, incluidas las carpetas WEB-INF y META-INF, y hacer que Tomcat procesara cualquier archivo de la aplicación como un JSP. Esto se agrava hasta la ejecución de código cuando la aplicación también almacena archivos subidos dentro de la propia aplicación web. Las correcciones se implementaron en las versiones 7.0.100, 8.5.51 y 9.0.31, en las que Apache también comentó el conector en el archivo server.xml predeterminado, cambió su dirección de enlace predeterminada a loopback e hizo obligatorio el uso de una clave secreta AJP. Figura en el catálogo KEV desde el 3 de marzo de 2022.

CVE-2025-55752 (traversal de directorios)

Una vulnerabilidad en la «Rewrite Valve» normalizaba las URL reescritas antes de descodificarlas. Cuando las reglas de reescritura incorporan parámetros de consulta a la URL, un atacante podría manipular el URI de la solicitud para eludir las protecciones de /WEB-INF/ y /META-INF/, con la posibilidad de ejecutar código si además se hubiera habilitado el método PUT. Apache señala que esa combinación es poco probable, ya que el método PUT suele estar restringido a usuarios de confianza, pero aun así merece la pena conocer el caso. Esto demuestra cómo una corrección en una versión puede reintroducir silenciosamente un riesgo en otra.

CVE-2026-29146 (Oracle de relleno en EncryptInterceptor)

Un buen recordatorio de que una configuración predeterminada puede suponer una vulnerabilidad. El EncryptInterceptor, utilizado para cifrar el tráfico del clúster, tenía por defecto el modo CBC, que es vulnerable a los ataques de oráculo de relleno. Cualquier implementación que ejecutara ese interceptor en su modo de cifrado predeterminado quedaba potencialmente expuesta sin que el administrador hubiera seleccionado nada inusual. Para las versiones cubiertas por el servicio Endless Lifecycle Support de TuxCare, las correcciones retrocompatibles se registran por versión en el rastreador CVE, que muestra exactamente qué versiones cubiertas disponen de la corrección.

CVE-2026-34486 (Elusión de EncryptInterceptor)

La corrección para CVE-2026-29146 se incluyó en las versiones 9.0.116, 10.1.53 y 11.0.20, y presentaba un error que permitía eludir por completo el EncryptInterceptor. Fíjate en el número de Tomcat 11 que aparece ahí. La corrección se escribió para la versión 11.0.19, pero la votación para su lanzamiento fracasó, por lo que la 11.0.20 fue la primera versión que se pudo descargar. Exactamente esas tres versiones se ven afectadas, y las versiones 9.0.117, 10.1.54 y 11.0.21 corrigen el problema. La CISA añadió esta vulnerabilidad al catálogo KEV el 4 de agosto de 2026, por lo que una actualización del clúster que se detuviera en la primera corrección no se consideraría completa.

CVE-2026-55957 (Elusión de la autenticación de GSSAPI)

Cuando JNDIRealm se configuraba para autenticar conexiones mediante GSSAPI, un atacante podía autenticarse sin la contraseña correcta. Sin ataques de fuerza bruta, sin credenciales robadas. La lógica de autenticación simplemente no aplicaba la comprobación. Lo extraño es la cronología de los hechos. La corrección se incorporó discretamente en las versiones 9.0.102, 10.1.39 y 11.0.5, y el problema no se hizo público hasta el 29 de junio de 2026, más de un año después. Cualquier versión igual o anterior a la 9.0.100, la 10.1.36 o la 11.0.4 requiere atención. Las versiones más recientes ya estaban protegidas antes de que se asignara un número CVE al problema.

CVE-2026-43512 (Contraseña «null» en la autenticación Digest)

El modo de fallo en este caso es casi demasiado sencillo como para creerlo. El autenticador Digest de Tomcat aceptaba la cadena literal «null» como contraseña válida para cualquier nombre de usuario que no existiera en el Realm configurado. Así pues, un usuario que no figurara en el sistema podía autenticarse adivinando esa cadena. El alcance del impacto depende de lo que haya detrás de la autenticación Digest, pero la condición previa es muy fácil de cumplir. Se hizo pública el 12 de mayo de 2026 y se corrigió en las versiones 9.0.118, 10.1.55 y 11.0.22.

¿Sabías que...? En marzo de 2025, Palo Alto Networks bloqueó 125 856 escaneos, sondeos e intentos de explotación relacionados con CVE-2025-24813 y dos vulnerabilidades relacionadas de Apache Camel, procedentes de más de 70 países, en las tres semanas siguientes a su divulgación.

Cómo detectar y evaluar las vulnerabilidades de Apache Tomcat

La detección es, sobre todo, un problema de inventario. No se puede aplicar un parche a lo que no se ha encontrado, y los entornos más grandes suelen acumular instancias de Tomcat que nunca han llegado a figurar en ninguna lista. Sigue estos tres pasos en el orden indicado.

Realizar un inventario de todas las instancias y versiones

Busca todas las instalaciones de Tomcat, incluidas las aplicaciones que lo incorporan, como las aplicaciones Spring Boot que ejecutan el servidor Tomcat integrado. Anota la versión exacta, no el nombre de la carpeta. Las instalaciones se copian y se renombran, por lo que la ruta puede ser engañosa.

Consejo profesional: Ejecuta el script de versión incluido en el paquete en lugar de intentar adivinarla a partir de la ruta de instalación. El comando $CATALINA_HOME/bin/version.sh muestra las versiones exactas de Tomcat y la JVM, que son los datos que necesitas para cualquier evaluación real.

Asignar versiones a las CVE conocidas

Compara cada versión con la NVD, los avisos de seguridad de Tomcat correspondientes a tu rama y el catálogo KEV de la CISA. Cualquier elemento que figure en el KEV debe considerarse como objeto de explotación activa y pasar al principio de la cola.

Comprueba los indicadores de configuración de riesgo

Varias vulnerabilidades CVE de Tomcat solo suponen un riesgo cuando se activan determinados parámetros. Comprueba si el servlet predeterminado tiene la opción «readonly» establecida en «false», si «allowPartialPut» está habilitado, si se puede acceder al conector AJP y si JNDIRealm, la autenticación Digest o el EncryptInterceptor están activos. Ese panorama de configuración es lo que distingue entre una vulnerabilidad CVE que simplemente está presente y otra que realmente se puede explotar.

Cómo solucionar y corregir las vulnerabilidades de Apache Tomcat

Aplicar parches a Tomcat suele ser sencillo cuando existe una versión corregida. Lo complicado son los servidores en los que no se puede actualizar o cuya versión ya ha llegado al final de su ciclo de vida.

Actualizar a una versión con parches

En el caso de las ramas que se mantienen activamente, pasa a una versión fija y considera los números correspondientes a cada CVE de la tabla anterior como un mínimo y no como el objetivo final. Elige la última versión disponible en tu rama, lo que a día de hoy significa 9.0.121, 10.1.59 u 11.0.25. Si te detienes en la corrección mínima para un CVE, acabarás teniendo que cargar con todas las vulnerabilidades publicadas desde entonces. El CVE-2026-29146 es un ejemplo aleccionador. Sus correcciones iniciales se incluyeron en las versiones 9.0.116, 10.1.53 y 11.0.20, y resultó que estas tres versiones eran vulnerables a la elusión del parche CVE-2026-34486, por lo que el mínimo real en este caso es 9.0.117, 10.1.54 o 11.0.21.

El CVE Tracker de TuxCare para Apache Tomcat resulta muy útil para comprobar qué vulnerabilidades CVE afectan a una versión concreta antigua o al final de su ciclo de vida (EOL).

Aplica las medidas de mitigación de configuración cuando aún no puedas actualizar

Si hay que posponer la actualización de versión, bloquea la vía de explotación en la capa de configuración. Mantén «readonly» establecido en «true» en el servlet predeterminado, que es el valor por defecto y que elimina por sí solo la condición previa de que el servlet sea grabable. Si realmente se necesitan operaciones de escritura, establece «allowPartialPut» en «false» siempre que la aplicación no necesite subidas parciales. Ese parámetro lleva años existiendo, incluso en la versión 8.5.100 y en las versiones anteriores de la 9.0, por lo que es una opción válida en servidores sin parches. A continuación, desactiva el conector AJP si no lo utilizas, o bien vincúlalo a la interfaz que tu proxy realmente necesite y asígnale un secreto si sí lo utilizas.

Atención: la función PUT parcial está habilitada por defecto, pero la persistencia de sesión basada en archivos no lo está, ni tampoco lo está un servlet predeterminado en modo escritura. En el momento en que alguien configura el servlet predeterminado en modo escritura para una función de subida de archivos, se cumple una de las condiciones previas no predeterminadas. Si se añade la persistencia de sesión basada en archivos en la ubicación de almacenamiento predeterminada y una biblioteca que pueda ser objeto de abuso para la deserialización, la cadena completa de CVE-2025-24813 queda activa. Considera la «activación de la escritura» como una decisión de seguridad más que como una opción de comodidad, y aprovecha para auditar las otras dos condiciones mientras estás en ello.

Elige entre la aplicación manual o automática de parches y cubre las versiones al final de su vida útil (EOL)

La forma de aplicar los parches depende del tamaño de la flota, del nivel de control de cambios que debas cumplir y de si la versión sigue recibiendo correcciones del desarrollador original.

Tomcat es un contenedor de servlets bastante autónomo, y la mayoría de los avisos de seguridad se refieren a sus propios componentes, como Catalina, Coyote y Jasper. Las implementaciones en producción deben seguir supervisando el JDK y cualquier biblioteca que incluya la aplicación, ya que esas dependencias conllevan sus propias vulnerabilidades. En un caso como el de CVE-2025-24813, es precisamente una biblioteca incluida la que proporciona la cadena de gadgets que convierte la deserialización insegura en ejecución de código.

Cuando las correcciones de los desarrolladores originales dejan de llegar a la versión que estás utilizando, ahí es donde entra en juego el servicio «Endless Lifecycle Support» de TuxCare para Apache Tomcat. Este servicio incorpora las correcciones de CVE en versiones fijas de Tomcat, que se distribuyen desde un repositorio de TuxCare, para que puedas seguir utilizando tu versión actual en lugar de dar un salto a una versión que no has probado. Actualmente, la cobertura abarca versiones seleccionadas de Tomcat 7, 8.5, 9.0 y 10.1, concretamente las 7.0.109, 8.5.100, 9.0.46, 9.0.50, 9.0.75, 9.0.83, 9.0.87, 9.0.90, 9.0.100, 10.1.18 y 10.1.42, y la documentación incluye la matriz actual. Ese intervalo es importante porque el problema no es solo el fin de la vida útil de la rama. Tanto Tomcat 7 como 8.5 lo superaron hace mucho tiempo —el 8.5 desde el 31 de marzo de 2024— y ahora se ha anunciado que el fin del soporte para Tomcat 9.0 será el 31 de marzo de 2027. Sin embargo, una aplicación fijada en una versión anterior de la 9.0 o la 10.1 no recibe las correcciones que Apache añade en versiones posteriores de esa misma rama.

En resumen, si tu versión de Tomcat sigue recibiendo parches del desarrollador original, actualízala con una periodicidad fija. Si ha llegado al final de su ciclo de vida, o si la versión fijada ya ha quedado obsoleta, opta por los parches proporcionados por el proveedor o planifica la migración. Dejarla sin parches no es una opción válida.

Prácticas recomendadas para proteger Apache Tomcat

El refuerzo de la seguridad de Tomcat no consiste tanto en aplicar medidas exóticas como en mantener intactos los valores predeterminados seguros, desactivar lo que no se utilice y reforzar la seguridad de todo aquello que se exponga. Unos pocos hábitos constantes bastan para tapar la mayoría de las vulnerabilidades más comunes.

Utiliza únicamente las versiones compatibles

Mantén tanto Tomcat como el JDK en versiones que sigan recibiendo parches de seguridad. Para las versiones que el desarrollador original ya no mantiene, el servicio «Endless Lifecycle Support» para Apache Tomcat garantiza que se sigan proporcionando parches sin necesidad de una migración forzada.

Fijar los conectores y el servlet predeterminado

Aplica el principio de «privilegios mínimos» a la superficie de exposición de Tomcat. Deja el servlet predeterminado en modo de solo lectura, a menos que tengas una razón de peso para no hacerlo; desactiva el PUT parcial si no lo utilizas, y nunca permitas que se pueda acceder a AJP desde redes no fiables.

Consejo de experto: Si utilizas AJP, vincula el conector a la interfaz que realmente necesita tu proxy de confianza, restringe el acceso a la misma en la capa de red y configura un secreto. Ghostcat fue tan peligroso en gran medida porque ese puerto permaneció abierto en las instalaciones predeterminadas durante más de una década.

Coloca Tomcat detrás de un proxy inverso y supervísalo

En la mayoría de las implementaciones de producción, coloca un proxy inverso reforzado delante de Tomcat en lugar de exponer directamente el conector de la aplicación. Elimina las aplicaciones de ejemplo y restringe estrictamente el acceso a la aplicación de gestión si decides mantenerla. Revisa los registros de acceso para detectar solicitudes de archivos inusuales, especialmente aquellas que intenten acceder a /WEB-INF/ o que envíen solicitudes PUT inesperadas.

Mantén tu Apache Tomcat protegido con TuxCare

Las vulnerabilidades de Apache Tomcat rara vez se hacen evidentes. Permanecen ocultas en las configuraciones predeterminadas y en las versiones fuera de soporte hasta que alguien analiza tu servidor. La solución es tediosa, pero fiable. Infórmate bien de lo que ejecutas, aplica los parches disponibles, mitiga los riesgos de lo que no tenga solución y nunca dejes expuesta una versión fuera de soporte. Si te has quedado atascado en una versión que el desarrollador original ya no soporta, descubre cómo TuxCare ofrece soporte de ciclo de vida ilimitado para Apache Tomcat.

Resumen

Nombre del artículo

¿Qué son las vulnerabilidades de Apache Tomcat? Detección, soluciones y consejos

Descripción

¡Mantén a salvo tus servidores Apache Tomcat! Aprende a detectar vulnerabilidades, a corregirlas y a seguir las mejores prácticas para garantizar una seguridad sólida.

Autor

Rohan Timalsina

Nombre del editor

TuxCare

Logotipo de la editorial