Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones:
- La vulnerabilidad CVE-2025-24813 puede permitir a atacantes no autenticados ejecutar código de forma remota, revelar información o inyectar contenido en servidores Tomcat, pero solo si el servlet predeterminado tiene habilitada la escritura (desactivada de forma predeterminada) y se cumplen algunas otras condiciones no predeterminadas.
- Los equipos afectados deben realizar un inventario de las instalaciones de Tomcat, comprobar si se están aplicando las restricciones de seguridad y actualizar a versiones parcheadas lo antes posible.
- Los entornos Tomcat antiguos o difíciles de actualizar requieren un plan claro de reducción de riesgos, en lugar de seguir dependiendo de versiones sin parches y al final de su ciclo de vida.
Si gestionas instancias de Apache Tomcat en entorno de producción, CVE-2025-24813 es una de esas vulnerabilidades que requiere tu atención inmediata. No porque sea llamativa o esté acaparando titulares, sino porque supone un riesgo real y explotable en configuraciones que son sorprendentemente habituales.
No se trata de un caso teórico aislado que solo afecte a alguien que ejecute Tomcat en una Raspberry Pi en modo de depuración. Estamos hablando de una vulnerabilidad que puede afectar a entornos de producción reales, lo que podría proporcionar a los atacantes un punto de acceso a la infraestructura de tu aplicación. Analicemos qué es realmente CVE-2025-24813, quién debe preocuparse por ello y cómo abordarlo sin que tu semana se convierta en una crisis.
¿Qué es CVE-2025-24813?
CVE-2025-24813 es una vulnerabilidad de equivalencia de rutas en Apache Tomcat que puede dar lugar a la ejecución remota de código sin autenticación, a la divulgación de información o a la inyección de contenido en archivos subidos. En la práctica, un atacante que consiga acceder a una instancia vulnerable de Tomcat podría subir un archivo malicioso y engañar a Tomcat para que lo ejecute, sin necesidad de credenciales.
La vulnerabilidad se debe a la forma en que el manejo parcial de la operación PUT de Tomcat construye las rutas de los archivos temporales. La implementación original generaba un nombre de archivo temporal basado en el nombre y la ruta del archivo proporcionados por el usuario, sustituyendo el separador de la ruta por un punto. En combinación con la persistencia de sesión basada en archivos de Tomcat, este diseño permite a un atacante subir una carga útil serializada en Java, especialmente manipulada, al directorio de sesión y, a continuación, desencadenar la deserialización mediante una solicitud GET posterior que contenga un cookie . El resultado es la ejecución remota de código.
Lo que hace que esto resulte especialmente preocupante es que no se requiere autenticación y que la carga útil puede codificarse en Base64 para eludir las reglas de detección habituales. Una vez que el atacante comprende la colisión de rutas de archivo y el desencadenante de la deserialización, la explotación es un proceso mecánico.
Dicho esto, la vulnerabilidad tiene unos requisitos previos concretos. Para que pueda explotarse, deben cumplirse todas las condiciones siguientes: las operaciones de escritura deben estar habilitadas en el servlet predeterminado (desactivadas por defecto —el parámetro en conf/web.xml debe cambiarse a false), Tomcat está configurado para utilizar la persistencia de sesión basada en archivos (no la predeterminada) y la ruta de clases de la aplicación incluye una cadena de gadgets de deserialización que el atacante puede aprovechar. Apache calificó inicialmente el CVE como «Importante» en lugar de «Crítico» precisamente por esta razón. Pero cuando se dan todas las condiciones previas, el impacto es el compromiso total del servidor, y la CISA lo añadió al catálogo de vulnerabilidades explotadas conocidas a las pocas semanas de su divulgación. –
¿Qué versiones de Tomcat se ven afectadas?
La vulnerabilidad CVE-2025-24813 afecta a varias ramas de Apache Tomcat, aunque el rango exacto de versiones vulnerables depende de la versión principal que estés utilizando. A continuación se detalla la información:
- Apache Tomcat 11.0.x es vulnerable en las versiones 11.0.0-M1 a 11.0.2. La corrección se incorporó en la versión 11.0.3, por lo que es necesario tener la versión 11.0.3 o posterior para que la corrección se aplique.
- Apache Tomcat 10.1.x es vulnerable en las versiones 10.1.0-M1 a 10.1.34. La corrección se incluye en la versión 10.1.35 y versiones posteriores.
- Apache Tomcat 9.0.x es vulnerable en las versiones 9.0.0.M1 a 9.0.98. Necesitas la versión 9.0.99 o posterior para solucionar la vulnerabilidad.
- Apache Tomcat 8.5.x llegó al final de su vida útil el 31 de marzo de 2024, antes de que se revelara este CVE. El proyecto Apache Tomcat no publicó un parche comunitario para la versión 8.5, por lo que cualquier implementación de la versión 8.5.x queda expuesta de forma permanente, a menos que se migre a una rama compatible o se obtenga cobertura a través de un proveedor comercial de soporte ampliado.
Cabe destacar que Tomcat 8.5 y todas las versiones anteriores —las ramas 8.0.x y 7.0.x— han llegado al final de su ciclo de vida y no recibirán ningún parche de la comunidad para el CVE-2025-24813. Si utilizas alguna de estas ramas, tus únicas opciones son migrar a una versión compatible u obtener cobertura a través de un proveedor de soporte técnico comercial ampliado. Hablaremos de ambas opciones en un momento.
Lo fundamental es comprender que esto no afecta únicamente a las versiones más recientes o a configuraciones poco comunes. La vulnerabilidad afecta a las principales versiones de Tomcat que se utilizan actualmente en entornos de producción, incluidas las versiones 9.0 y 8.5, ampliamente consolidadas, que dan servicio a innumerables aplicaciones empresariales.
Comprender el escenario de la explotación
Para comprender realmente el riesgo, es necesario saber cuándo y cómo esta vulnerabilidad tiene realmente importancia en los entornos de producción.
El escenario de explotación de CVE-2025-24813 gira en torno al servlet predeterminado de Tomcat —el componente que gestiona las solicitudes directas de archivos— y a una función denominada «PUT parcial», que permite a los clientes cargar partes de un archivo a través de varias solicitudes. De forma predeterminada, el servlet predeterminado es de solo lectura e ignora por completo las solicitudes PUT, por lo que la mayoría de las instalaciones no están expuestas. La vulnerabilidad solo se hace accesible cuando un administrador ha establecido explícitamente el readonly en false en conf/web.xml, activando así las subidas a través del servlet predeterminado.
Aquí es donde la cosa se pone interesante: incluso con la escritura habilitada, para aprovechar la vulnerabilidad se necesitan otros elementos. Tomcat debe estar configurado para la persistencia de sesiones basada en archivos (el FileStore en lugar de sesiones en memoria), la ruta de clases de la aplicación debe incluir una cadena de gadgets de deserialización, y el atacante debe poder acceder al punto final de carga a través de la red.
Cuando se dan esas condiciones, la cadena de ataque es breve. El atacante envía una solicitud PUT parcial que carga una carga útil Java serializada en una ruta que controla. Dado que la implementación de PUT parcial de Tomcat traduce el URI de la solicitud en un nombre de archivo temporal —sustituyendo los separadores de ruta por puntos—, el archivo cargado acaba exactamente donde Tomcat buscará más tarde los datos de sesión. Una solicitud GET posterior con un cookie hace que Tomcat deserialice el archivo, ejecute la cadena de gadgets y permita al atacante la ejecución remota de código. No se requiere autenticación en ningún paso.
En la práctica, no se trata de que «un atacante pueda ver un punto final adicional», sino de que «un atacante suba una carga útil, envíe una solicitud más y ejecute código como el proceso de Tomcat».
Si tu aplicación no permite la escritura en el servlet predeterminado o no utiliza la persistencia de sesiones basada en archivos, no estás expuesto a la vía de ejecución remota de código de este CVE. No obstante, podrías seguir estando expuesto a las variantes de divulgación de información o de inyección de contenido en condiciones ligeramente diferentes, por lo que aplicar el parche sigue siendo la decisión acertada; sin embargo, la urgencia depende totalmente de tu configuración.
Evaluar tu exposición
Antes de empezar a aplicar los parches, conviene dedicar un momento a averiguar si tus implementaciones concretas de Tomcat están realmente expuestas al riesgo que supone el CVE-2025-24813.
- En primer lugar, comprueba las versiones de Tomcat. Esto parece obvio, pero en entornos complejos con múltiples instancias de Tomcat, te sorprendería saber con qué frecuencia los equipos carecen de un inventario completo. Si estás ejecutando cualquier versión anterior a las versiones parcheadas mencionadas anteriormente, eres potencialmente vulnerable. No te olvides de aquellas instancias de Tomcat que se ejecutan en contenedores Docker, ocultas en implementaciones de microservicios o integradas en otras aplicaciones.
- Second, review your security constraint configurations. Look at the ‘web.xml’ files (and any programmatic security configurations) for your deployed applications. Are you using ‘<security-constraint>’ elements to protect resources? Are you relying on Tomcat’s built-in authentication mechanisms? If the answer is yes, you need to treat this vulnerability seriously.
- En tercer lugar, ten en cuenta tu arquitectura de implementación. ¿Sus instancias de Tomcat están expuestas directamente a Internet o se encuentran detrás de proxies inversos, puertas de enlace API u otras capas de seguridad? Aunque la defensa en profundidad siempre es recomendable, no dé por sentado que un WAF o un proxy inverso le protegen automáticamente de esta vulnerabilidad. La manipulación de la solicitud necesaria para explotar CVE-2025-24813 podría atravesar esas capas sin problemas.
- Por último, piensa en lo que estás protegiendo. Aunque técnicamente seas vulnerable, el riesgo real depende de a qué podría acceder un atacante si eludiera tus restricciones de seguridad. Si hablamos de una interfaz de administración con acceso a datos de clientes o controles del sistema, lo que está en juego es muy importante. Si se trata de un punto final de monitorización interna que solo muestra métricas depuradas, la urgencia es diferente.
El objetivo aquí no es restar importancia a la vulnerabilidad ni convencerte de que no instales los parches. Se trata de comprender tu perfil de riesgo para que puedas priorizar adecuadamente las medidas correctivas, sobre todo si gestionas decenas o cientos de instancias de Tomcat.
Medidas de mitigación y corrección
La solución principal y recomendada para CVE-2025-24813 es sencilla: actualizar a una versión parcheada de Apache Tomcat. Pero, como sabe cualquiera que haya gestionado implementaciones de Tomcat en producción, «simplemente actualizar» es más fácil de decir que de hacer.
La ruta de actualización limpia
Si puedes actualizar sin problemas, esto es lo que verás:
- Identifica la versión actual de Tomcat en todas las implementaciones. Utilice catalina.sh version o compruebe el número de versión en el directorio de instalación de Tomcat. No se fíe de la documentación o los manuales de procedimientos, ya que podrían estar desactualizados.
- Descarga la versión parcheada correspondiente desde el sitio web oficial de Apache Tomcat. Para Tomcat 11, descargue la versión 11.0.3 o posterior. Para la versión 10.1, descargue la versión 10.1.35 o posterior. Para la versión 9.0, descargue la versión 9.0.99 o posterior. Si todavía utiliza Tomcat 8.5, no hay ningún parche de la comunidad; consulte la sección «Cuando la actualización no es factible de inmediato» más abajo. Descargue siempre desde fuentes oficiales, nunca desde servidores espejo aleatorios o repositorios de terceros.
- Prueba primero la actualización en un entorno que no sea de producción. No se trata de una paranoia innecesaria, sino de una medida de seguridad operativa básica. Las actualizaciones de Tomcat a veces introducen cambios de comportamiento o características de rendimiento que pueden sorprenderte. Comprueba que tus aplicaciones siguen funcionando, que los indicadores de rendimiento son razonables y que las integraciones de supervisión o registro siguen funcionando.
- Planifica la implementación en producción. Ten en cuenta los intervalos de implementación, los patrones de tráfico y los procedimientos de reversión. Si ejecutas Tomcat detrás de un equilibrador de carga, puedes actualizar las instancias de una en una. Si te encuentras en un entorno más limitado, es posible que necesites un intervalo de mantenimiento. Asegúrate de contar con un plan de reversión probado por si algo sale mal.
- Aplica la actualización y comprueba que estás ejecutando la versión parcheada. No des por sentado que la actualización ha funcionado: comprueba el número de versión tras la implementación.
Medidas de mitigación basadas en la configuración
Aunque la solución adecuada es actualizar el sistema, es posible que haya cambios en la configuración que puedan reducir tu vulnerabilidad a corto plazo. Revisa tus restricciones de seguridad para asegurarte de que sean lo más específicas y restrictivas posible. Los patrones de URL demasiado amplios o las restricciones mal definidas pueden aumentar tu superficie de ataque.
Considera la posibilidad de implementar capas de autenticación adicionales a nivel del proxy inverso o de la pasarela de API, si dispones de esos componentes en tu arquitectura. Una vez más, esto no sustituye a la aplicación de parches, pero refuerza la defensa en profundidad.
Si tienes instancias de Tomcat que alojan varias aplicaciones web, comprueba qué aplicaciones están implementadas y si todas ellas son realmente necesarias. Reducir el número de aplicaciones implementadas reduce la superficie de ataque potencial.
Consideraciones operativas
A continuación, te indicamos algunos aspectos prácticos a los que debes prestar atención durante el proceso de aplicación de parches:
- Requisitos de reinicio. La actualización de Tomcat requiere un reinicio. Esto implica un tiempo de inactividad para tus aplicaciones, a menos que hayas diseñado una arquitectura que permita implementaciones sin tiempo de inactividad. Planifica en consecuencia.
- Compatibilidad de los archivos de configuración. La mayoría de las actualizaciones de Tomcat son compatibles con versiones anteriores de los archivos de configuración existentes, pero no siempre. Presta especial atención a cualquier personalización que hayas realizado en server.xml, web.xmlu otros archivos de configuración.
- Dependencias de la versión de la JVM. Las diferentes versiones de Tomcat tienen distintos requisitos de versión de Java. Tomcat 10.1 requiere Java 11. Tomcat 11 requiere Java 17 o posterior. Si está actualizando desde una versión anterior de Tomcat, es posible que también tenga que actualizar su JVM, lo que añade complejidad.
- Compatibilidad de bibliotecas y conectores. Si utiliza controladores JDBC, conectores JMS u otras bibliotecas con Tomcat, compruebe que sean compatibles con la versión a la que va a actualizar. Esto es especialmente importante en el caso de aplicaciones empresariales más antiguas.
- Agentes de monitorización y APM. Si utiliza agentes de monitorización o herramientas APM que se integran con Tomcat, compruebe que siguen funcionando tras la actualización. Algunos agentes son sensibles a los cambios de versión de Tomcat.
Cuando la actualización no es viable de inmediato
Seamos realistas: no todas las organizaciones pueden dejarlo todo y actualizar todas las instancias de Tomcat en cuanto se publica un CVE. A veces se trata de aplicaciones proporcionadas por los proveedores que incluyen versiones específicas de Tomcat y no son compatibles con las más recientes. Otras veces se ejecutan aplicaciones heredadas en ramas antiguas de Tomcat cuya actualización requeriría un trabajo considerable de pruebas y validación. Y a veces simplemente se dispone de recursos limitados y hay que dar prioridad a las instancias más críticas.
Para los equipos que utilizan versiones antiguas de Tomcat que no pueden actualizarse de inmediato, existen opciones de soporte de seguridad ampliado que ayudan a cubrir esa brecha. Servicios como el Endless Lifecycle Support (ELS) de TuxCare proporcionan parches de seguridad continuos para versiones de software que han llegado al final de su ciclo de vida, incluidas las versiones antiguas de Tomcat que ya no reciben actualizaciones del proyecto Apache.
Esto no sustituye a la aplicación adecuada de parches ni a la actualización a las versiones actuales. Se trata de una opción pragmática para reducir el riesgo que puede formar parte de un plan de corrección por fases. Si tienes instancias de Tomcat 8.0 o 7.0 que no pueden migrarse de inmediato, el soporte ampliado puede mantener esos sistemas protegidos frente a vulnerabilidades conocidas mientras llevas a cabo el proceso de actualización en un plazo realista.
La clave está en actuar con deliberación. Si estás utilizando el soporte ampliado, ten un plan claro para pasar, en su momento, a las versiones actuales de Tomcat. No dejes que el soporte ampliado se convierta en una excusa para posponer la deuda técnica indefinidamente.
Más allá de esta vulnerabilidad (CVE): cómo crear implementaciones resilientes de Tomcat
CVE-2025-24813 es una vulnerabilidad, pero forma parte de una tendencia más amplia. Las vulnerabilidades de Tomcat se descubren con frecuencia, y siempre será así. La cuestión no es si tendrás que volver a aplicar un parche a Tomcat, sino con qué rapidez y sin problemas podrás hacerlo cuando se publique el próximo CVE.
Esto implica establecer prácticas operativas que faciliten la aplicación rápida de parches: mantener inventarios claros de todas las implementaciones de Tomcat, disponer de procedimientos de actualización probados, realizar análisis periódicos de vulnerabilidades y mantener entornos de prueba que reflejen el entorno de producción para probar las actualizaciones.
Esto también implica tomar decisiones arquitectónicas que refuercen la seguridad: ejecutar instancias de Tomcat detrás de proxies inversos, implementar la segmentación de la red, utilizar una orquestación de contenedores que facilite las actualizaciones progresivas y aplicar el principio del mínimo privilegio a los permisos de los procesos de Tomcat.
Y eso significa mantenerse informado. Suscríbete a la lista de correo sobre seguridad de Apache Tomcat. Revisa las bases de datos CVE en busca de vulnerabilidades relacionadas con Tomcat. No esperes a que una vulnerabilidad se haga pública para empezar a planificar cómo responder.
Pasar a la acción
La vulnerabilidad CVE-2025-24813 es grave, pero también se puede solucionar. Existen parches, las medidas de mitigación están claras y los requisitos para su explotación son lo suficientemente específicos como para que puedas tomar decisiones fundamentadas sobre las prioridades.
Si utiliza versiones de Tomcat afectadas y recurre a restricciones de seguridad para proteger los recursos, considere esta tarea de aplicación de parches como de máxima prioridad. Pruebe la actualización, planifique su implementación y actualice esas instancias. Si utiliza versiones antiguas de Tomcat que ya no recibirán parches, evalúe sus opciones de soporte ampliado o acelere sus planes de migración.
La peor forma de actuar ante el CVE-2025-24813 es ignorarlo y esperar que no tenga importancia. La mejor forma de actuar es evaluar el riesgo al que se está expuesto, priorizar las medidas de corrección y aplicar los parches de forma sistemática.
Tus instancias de Tomcat forman parte de la infraestructura de tu aplicación. Mantenerlas seguras no es una tarea opcional que se pueda realizar cuando te sobre tiempo. Se trata de una responsabilidad operativa fundamental que merece tiempo, atención y recursos.
