Vulnerabilidades

Apache bajo análisis: PUT parcial de Tomcat y secuestro de encabezados de Camel

Clock Icon 14 lectura mínima
Related Products
Advanced DNS SecurityAdvanced Threat PreventionAdvanced URL FilteringCloud-Delivered Security ServicesCortexCortex XDRCortex XSIAMNext-Generation FirewallUnit 42 Incident Response iconUnit 42 Incident Response

Resumen ejecutivo

En marzo de 2025, Apache reveló CVE-2025-24813, una vulnerabilidad que afecta a Apache Tomcat. Se trata de una plataforma muy utilizada que permite a los servidores web Apache ejecutar aplicaciones web basadas en Java. El fallo permite la ejecución remota de código, afectando a las versiones 9.0.0.M1 a 9.0.98, 10.1.0-M1 a 10.1.34 y 11.0.0-M1 a 11.0.2 de Apache Tomcat.

El mismo mes, Apache reveló dos vulnerabilidades adicionales en Apache Camel, un marco de middleware de enrutamiento de mensajes. Estas vulnerabilidades son CVE-2025-27636 y CVE-2025-29891, dos fallos que permiten la ejecución remota de código y que afectan a las versiones 4.10.0 a 4.10.1, 4.8.0 a 4.8.4 y 3.10.0 a 3.22.3 de Apache Camel.

Estas vulnerabilidades son importantes porque millones de desarrolladores confían en la plataforma proporcionada por Apache Foundation. La explotación exitosa de estas vulnerabilidades podría permitir que los atacantes ejecuten código arbitrario con privilegios de Tomcat/Camel.

Apache ha publicado parches y los investigadores no han tardado en publicar exploits de pruebas de concepto (PoC). Se observaron escaneos y sondeos de servidores vulnerables en el entorno real poco después de la revelación de la información. Hemos confirmado la posibilidad de ejecución remota de código a partir de estas tres vulnerabilidades.

En marzo de 2025, Palo Alto Networks bloqueó 125,856 sondas/exploraciones/intentos de explotación relacionados con estas vulnerabilidades. A las organizaciones les aconsejamos que apliquen los parches pronto.

Los clientes de Palo Alto Networks están mejor protegidos gracias a los siguientes productos y servicios:

Si cree que puede haber resultado vulnerado o tiene un problema urgente, póngase en contacto con el equipo de respuesta ante incidentes de Unit 42.

Temas relacionados con Unit 42 Vulnerabilities, CVE-2025-24813, CVE-2025-27636, CVE-2025-29891

CVE-2025-24813: Apache Tomcat

Resumen de vulnerabilidades

CVE-2025-24813 es una vulnerabilidad en la característica PUT parcial de Apache Tomcat con la que los atacantes pueden sobrescribir archivos de sesión serializados en disco, llevando a la ejecución de código arbitrario.

Esta vulnerabilidad surge cuando Tomcat está configurado para conservar los datos de sesión HTTP, porque los sistemas Tomcat sin parchear gestionan incorrectamente las peticiones PUT parciales que contienen el encabezado Content-Range.

PUT parcial

El término “PUT parcial” se refiere a una solicitud HTTP PUT que actualiza solo parte de un recurso, en lugar de reemplazarlo por completo. Cuando es compatible, PUT parcial suele utilizar el encabezado Content-Range en una solicitud HTTP para especificar qué parte del recurso debe modificarse.

Esto permite a los clientes cargar o sobrescribir segmentos de recursos en fragmentos. Los PUT parciales pueden aprovecharse para realizar subidas incrementales de archivos, sobrescribir partes específicas de archivos o eludir ciertas comprobaciones de seguridad, si no se gestionan correctamente.

Función de persistencia de sesión en Apache Tomcat

El gestor de sesiones HTTP de Apache Tomcat incluye una función de persistencia de sesión. Esta función guarda los datos de la sesión en un archivo o una base de datos cuando se apaga el servidor, y vuelve a cargar estos datos en caché cuando se reinicia el servidor. Los datos de la sesión contienen información como el estado de inicio de sesión del usuario y sus preferencias, y esta función ayuda a conservar los datos de la sesión de un usuario cuando se reinicia el servidor.

Tomcat codifica estos datos de sesión guardados como un flujo de bytes mediante un proceso denominado serialización y almacena los datos serializados en el sistema de archivos local. Serializa todos los atributos de sesión almacenados en el objeto HttpSession. Esto incluye cualquier dato que su aplicación web coloque explícitamente en la sesión utilizando session.setAttribute(). La información se almacena normalmente en algún lugar en $TOMCAT_HOME/webapps/ROOT/.

Sin embargo, los datos de sesión serializados se almacenan en el mismo directorio utilizado por la función executePartialPut de Tomcat. Los usuarios pueden elaborar solicitudes HTTP para controlar el ID de sesión y el nombre de archivo de los datos almacenados en caché en este directorio. Esto podría permitir que un atacante establezca intencionalmente el ID de sesión para que coincida con el nombre de archivo en caché de código malicioso previamente guardado en la caché. Esto puede provocar la deserialización del archivo almacenado en caché, activando el código malicioso incrustado.

Condiciones previas

El encabezado Content-Range se utiliza a menudo con actualizaciones parciales. Este encabezado indica que el cuerpo de la solicitud contiene una parte del recurso, en lugar del recurso completo. Si una solicitud HTTP PUT contiene un encabezado Content-Range, Tomcat guarda el contenido (cuerpo) de la solicitud PUT en la ubicación de caché. El siguiente fragmento de código muestra que Tomcat guarda los datos de una solicitud HTTP PUT que tiene contenido.

Una configuración vulnerable de Tomcat debe tener dos condiciones previas para explotar esta vulnerabilidad:

  1. Un parámetro de solo lectura desactivado en el archivo de configuración de Tomcat en $TOMCAT_HOME/conf/web.xml. A continuación, se muestra la sección de web.xml que contiene un parámetro de solo lectura desactivado.

Aprovechar la vulnerabilidad

Realizamos pruebas de explotación de CVE-2025-24813 en marzo de 2025. La explotación de esta vulnerabilidad consta de dos pasos:

  • En primer lugar, prepare la carga útil enviándola como un archivo a través de una solicitud HTTP PUT con Content-Range y un nombre de archivo autodefinido en la URL. Este archivo contiene código malicioso serializado para su posterior deserialización.
  • A continuación, active el exploit enviando una solicitud HTTP GET adicional que contenga una cookie formada por JSESSIONID= seguida inmediatamente del nombre de archivo autodefinido precedido de un punto. En este caso, la línea de la cookie diría: Cookie: "JSESSIONID=.[filename]" como muestra la Figura 1 a continuación. Esto activará la deserialización de la caché para ejecutar el código malicioso.
Diagrama de flujo que representa un proceso de ciberataque en dos pasos. En el paso 1, se envía a un servidor una solicitud HTTP denominada 'PUT /filename.session' con 'Content-Range: bytes 0-5/100'. En el paso 2, un atacante envía una solicitud HTTP etiquetada como 'GET /' con 'Cookie: JSESSIONID=_filename' al servidor. Las flechas indican la dirección de la comunicación entre las etapas y el servidor.
Figura 1. Dos pasos del exploit.

Paso 1: Preparar el código malicioso serializado

Este primer paso consiste en enviar un archivo de código malicioso serializado como el cuerpo de una solicitud HTTP PUT. Apache Tomcat almacenará en la caché el código malicioso como un archivo de sesión en el sistema de archivos local, ya que el nombre del archivo en el URI termina en .session, como muestra la Figura 2 en la línea del encabezado PUT.

En la Figura 2, se observa la solicitud PUT del primer paso con gopan.session como nombre de archivo. El formato de esta solicitud HTTP PUT del tráfico es:

PUT /[filename].session HTTP/1.1

Una captura de pantalla de una solicitud HTTP PUT con parte del encabezado y el contenido del archivo visibles. El encabezado incluye información sobre el host, el tipo de conexión y la longitud del contenido. Una sección resaltada indica que el nombre de archivo "gopan.session" se envía como cuerpo de contenido de la solicitud.
Figura 2. Carga útil en el paso 1.

Paso 2: Desencadenar el exploit

El segundo paso consiste en enviar una solicitud HTTP GET de seguimiento para desencadenar el exploit y ejecutar el código malicioso. En la Figura 3, se observa la solicitud HTTP GET con el valor de cookie JSESSIONID utilizado en el paso anterior. El formato de esta cookie es:

Cookie: JSESSIONID=.[filename]

Captura de pantalla de un terminal informático que muestra solicitudes y respuestas HTTP. La respuesta muestra un error HTTP 500, y algunos de los datos de la cookie hacen referencia a los nombres de archivo 'gopan' y 'gopan-family'.
Figura 3. Explotación de la vulnerabilidad para ejecutar la carga útil enviada previamente en el paso 1.

El valor de la cookie para este exploit utiliza un punto (.) antes del valor del nombre de archivo de JSESSIONID. Este punto inicial hará que Tomcat guarde el archivo de sesión con el punto inicial.

Análisis del código fuente

Cómo Tomcat almacena en caché el cuerpo PUT en un archivo

Como se muestra en la Figura 5, Tomcat comprueba primero si el indicador de solo lectura (readonly) está activado en el archivo de configuración. Si está activado, Tomcat no escribe ningún código en la caché, incluido el código malicioso.

Diagrama de flujo que detalla las interacciones entre las operaciones HttpServlet. Comienza con 'doPut' manejando una solicitud y una respuesta, comprobando la viabilidad y el rango antes de decidir ejecutar 'executePartialPut' o 'write req, save the file'. Otra rama muestra 'replacePartialPut' gestionando una solicitud de cadena, creando un archivo temporal y verificando el objeto del archivo, así como escribiendo la sesión en el objeto del archivo.
Figura 4. Primer paso: de PUT a escribir un archivo.
  • Si el indicador de solo lectura (readonly) no está activado, Tomcat también comprobará el campo Content-Range en el encabezado HTTP.
  • Si la solicitud carece de encabezado Content-Range, Tomcat finaliza el proceso.
  • Si la solicitud tiene un encabezado Content-Range, Tomcat guarda los datos de sesión de la solicitud HTTP PUT, en este caso gopan.session, en dos ubicaciones, como se muestra en la Figura 5.
    • El primero se guarda como un archivo de caché normal en $TOMCAT_HOME/webapps/ROOT/ sin el punto inicial.
    • El segundo se guarda como un archivo temporal con un punto inicial en el directorio de trabajo en $TOMCAT_HOME/work/Catalina/localhost/ROOT/.
Captura de pantalla de una estructura de directorios en un IDE, destacando la instalación de Apache Tomcat con archivos bajo el directorio de trabajo. Directorio raíz de la instalación de Tomcat. Archivo de sesión sin punto inicial en el nombre, almacenado como archivo normal en el directorio de caché actual. Archivo de sesión con punto inicial en el nombre, almacenado como archivo temporal en el directorio de trabajo.
Figura 5. Archivo de sesión en caché.

Significativamente, cuando Tomcat restaura una sesión, también carga el archivo de sesión en caché desde la misma carpeta de trabajo.

En la Figuras 6 y 7, se muestran segmentos de código del servlet Java predeterminado que Tomcat utiliza para cargar los archivos de sesión en caché al restaurar una sesión en java/org/apache/catalina/servlets/DefaultServlet.java. Los comentarios en amarillo describen las acciones realizadas por el código.

Captura de pantalla de un programa Java que muestra código relacionado con el manejo de solicitudes y respuestas del servidor HTTP.
Figura 6. Primer segmento de código del servlet Java por defecto de Apache utilizado por Tomcat.
Captura de pantalla que muestra una sección de código de programación, visualizada en un editor de texto con sintaxis resaltada.
Figura 7. Segundo segmento de código del servlet Java por defecto de Apache utilizado por Tomcat.
Cómo se desencadena la vulnerabilidad mediante una solicitud HTTP

Cuando Tomcat recibe una solicitud HTTP con un ID de sesión, si la persistencia de sesión está habilitada en la configuración, intentará encontrar la sesión en la memoria. Si Tomcat no puede encontrar la sesión en la memoria, restaurará la sesión desde el archivo de caché guardado. En ese momento, Tomcat deserializa el archivo de sesión, como se muestra en la Figura 8.

Diagrama de flujo que representa los procesos de gestión de sesiones. Incluye funciones como findSession, swapIn, loadSessionFromStore y load, con detalles sobre pasos como comprobar si la sesión está en memoria, cargar desde el almacén y deserializar el contenido.
Figura 8. Segundo paso: de sessionID a la deserialización.

En la Figura 8, se ilustra el flujo de gestión de sesiones de Tomcat. El código que localiza las sesiones, las carga desde el disco y deserializa su contenido se implementa en los siguientes archivos:

  • java/org/apache/catalina/session/PersistentManagerBase.java
  • java/org/apache/catalina/Store.java
  • java/org/apache/catalina/session/FileStore.java

En la Figura 9, se muestra un segmento de código de java/org/apache/catalina/session/PersistentManagerBase.java que dirige a Tomcat a encontrar un archivo para los datos de la sesión, si estos datos no están disponibles en la memoria.

Captura de pantalla de un código informático en Java. El código incluye un método llamado findSession con comentarios que explican partes de la lógica del código relacionadas con la comprobación de la disponibilidad de la sesión en memoria y su recuperación de un archivo si no se encuentra.
Figura 9. Segmento de código de PersistentManagerBase.java para encontrar los datos de sesión como un archivo, si no están en la memoria.

En las Figuras 10 y 11, se muestran segmentos de código del mismo archivo PersistentManagerBase.java que ilustran cómo carga los datos de la sesión desde un archivo de caché guardado.

Captura de pantalla de código informático que muestra la sintaxis para la gestión de sesiones y el manejo de excepciones.
Figura 10. Segmento de código de PersistentManagerBase.java para cargar la sesión desde el archivo (1 de 2).
Captura de pantalla de un fragmento de código que muestra un método llamado 'loadSessionFromStore'. El código incluye la gestión de excepciones y el registro de mensajes de error.
Figura 11. Segmento de código de PersistentManagerBase.java para cargar la sesión desde el archivo (2 de 2).

Como se muestra en la Figura 11, store.load(id) desencadena la deserialización, despertando el código malicioso previamente incrustado en el archivo por el atacante. Esto resulta en la ejecución de código arbitrario.

La revisión de este código fuente revela, en primer lugar, cómo Tomcat guarda los datos de la sesión de una solicitud HTTP PUT, un proceso mediante el cual un atacante puede almacenar código malicioso. Esta revisión también proporciona información sobre cómo un exploit para la vulnerabilidad CVE-2025-24813 puede desencadenarse con una sola solicitud HTTP GET de seguimiento.

Sin embargo, Tomcat no es el único software de Apache para el que hemos visto intentos de ataque en el entorno real. También hemos observado intentos de explotación de dos vulnerabilidades en Apache Camel.

CVE-2025-27636 y CVE-2025-29891: Apache Camel

Descripción general de Apache Camel

Apache Camel es un marco de integración de código abierto que permite a los desarrolladores conectar distintos sistemas de forma fiable y escalable. Con Camel, los desarrolladores pueden establecer reglas de enrutamiento y mediación en varios lenguajes específicos del dominio con el fin de integrar diversos sistemas y aplicaciones. Apache Camel es compatible con una amplia gama de protocolos y tecnologías.

La mayoría de los gestores de mensajes de Camel se proporcionan como paquetes Java, lo que le permite al desarrollador seleccionar qué paquetes incluir en su producto.

Detalles de la explotación

Ya sea cifrado o sin cifrar, HTTP es un método habitual para enviar datos a través de Internet. Si bien Camel utiliza varios tipos de componentes HTTP, como Jetty y Netty, en última instancia enruta los mensajes HTTP analizados de vuelta a sus componentes centrales, conocidos como camel-core, para que se realice su posterior procesamiento.

Con el propósito de facilitar el intercambio de datos entre Camel y sus componentes HTTP, como Jetty y Netty, los desarrolladores idearon un método que utiliza pares clave-valor para almacenar información contextual importante, como el código de respuesta HTTP. Dado que los encabezados HTTP se utilizan en el procesamiento, Camel también almacena los encabezados HTTP dentro del mismo par clave-valor. Para evitar conflictos entre la información contextual interna y los datos externos, los desarrolladores de Camel añadieron un prefijo Camel a todas las claves contextuales internas e implementaron un filtro para evitar que los encabezados externos causaran problemas (Figura 12).

Diagrama que muestra dos secciones denominadas HTTP Headers y Camel Headers, cada una de las cuales contiene ejemplos de nombres de encabezado específicos como User-Agent, Host, Accept, CamelExecCommandExecutable y CamelHttpResponseCode.
Figura 12. Encabezados HTTP normales comparados con los encabezados HTTP de Apache Camel.

Sin embargo, dado que el filtro distingue entre mayúsculas y minúsculas, un atacante podría eludirlo alterando las mayúsculas y minúsculas de los encabezados.

Análisis del código fuente

Por defecto, Camel registra el gestor de filtros de encabezado predeterminado. Pide al filtro que ignore todas las líneas de encabezado que empiecen con Camel, camel y org.apache.camel. El código para esto está en components/camel-http-base/src/main/java/org/apache/camel/http/base/HttpHeaderFilterStrategy.java, y en la Figura 13 se muestra el segmento aplicable.

Imagen de un fragmento de código llamado HttpHeaderFilterStrategy, que muestra métodos relacionados con el filtrado de encabezados HTTP. Incluye comentarios de código y elementos como condiciones de filtro que especifican el uso de camel case y nombres de dominio.
Figura 13. Segmento de código de HttpHeaderFilterStrategy.java para ignorar líneas de encabezado específicas.

Camel enumera los encabezados de las solicitudes HTTP, ejecuta la función applyFilterToExternalHeaders y escribe los encabezados en un mapa interno utilizando components/camel-http-common/src/main/java/org/apache/camel/http/common/DefaultHttpBinding.java, como se muestra en la Figura 14.

Captura de pantalla de un fragmento de código informático que incluye código para leer encabezados HTTP en una solicitud servlet, con comentarios y sentencias condicionales.
Figura 14. Segmento de código de DefaultHttpBinding.java.

La lógica de filtrado de encabezados realiza diferentes combinaciones en función de la configuración de Camel. Por defecto, Camel solo utiliza tryHeaderMatch para comprobar únicamente el principio del encabezado. Esto se hace a través de core/camel-support/src/main/java/org/apache/camel/support/DefaultHeaderFilterStrategy.java, como se muestra en la Figura 15.

Captura de pantalla del código para gestionar los filtros de encabezado HTTP. tryHeaderMatch está subrayado con rojo y marcado con una flecha roja.
Figura 15. Segmento de código de DefaultHeaderFilterStrategy.java que muestra tryHeaderMatch.

Suponiendo que un atacante anula el encabezado CAmelExecCommandExecutable utilizando una A mayúscula en la palabra CAmel, y el desarrollador está utilizando el paquete camel-exec, camel-exec leerá el valor y lo ejecutará a través de components/camel-exec/src/main/java/org/apache/camel/component/exec/impl/DefaultExecBinding.java, como se muestra en la Figura 16 a continuación.

Captura de pantalla de código del proyecto Apache Camel con la clase DefaultExecBinding, que incluye implementaciones de métodos y gestión de parámetros relacionados con la ejecución de comandos.
Figura 16. Segmento de código de DefaultExecBinding.java.

Si un desarrollador ha configurado este endpoint para ejecutar un ejecutable benigno, el atacante podría sustituir el endpoint por un comando peligroso mediante un shell inverso. El atacante puede, potencialmente, obtener un shell inverso a través de la ejecución remota de comandos.

Telemetría

Durante marzo de 2025, nuestra telemetría había identificado 125,856 escaneos, sondas o intentos de usar exploits procedentes de más de 70 países para la vulnerabilidad CVE-2025-24813 de Tomcat y las vulnerabilidades CVE-2025-27636 y CVE-2025-29891 de Camel. Como muestra el análisis de los datos del desencadenante en la Figura 17, la frecuencia de esta actividad se disparó inmediatamente después de que se anunciaran estos exploits a mediados de marzo de 2025, alcanzando su punto máximo en la primera semana.

Los datos indican además la presencia tanto de escáneres automáticos como de exploits activos en el entorno real.

Gráfico lineal que representa el número de disparadores a lo largo del tiempo. El gráfico muestra en el eje x las fechas comprendidas entre el 2025-03-16 y el 2025-03-30, con un aumento inicial del número de disparadores, un máximo a mitad del período y un descenso en la fecha final. Conjunto de logos de Unit 42 y Palo Alto Networks.
Figura 17. Detección de actividad de exploit en marzo de 2025.

Carga útil de los intentos de usar exploits

Hemos capturado las cargas útiles que los atacantes han utilizado hasta ahora en estos escaneos, sondeos e intentos de usar exploits.

En la Figura 18, se muestra un ejemplo de la solicitud HTTP PUT inicial para un intento de uso de exploit de la vulnerabilidad CVE-2025-24813 de Apache Tomcat. Este tipo de actividad es un escaneo o un sondeo para determinar si un servidor está ejecutando una versión vulnerable de Tomcat.

Captura de pantalla de una solicitud HTTP PUT que muestra los encabezados y parte del código Java relacionado con las clases HashMap y URL. Parte de la información se ha suprimido por motivos de privacidad.
Figura 18. Solicitud HTTP PUT para exploit de CVE-2025-24813.

Si tiene éxito, el exploit de la Figura 20 hace que el servidor víctima intente ponerse en contacto con un servidor de pruebas de seguridad de aplicaciones fuera de banda (OAST).

En la Figura 19, se muestra la solicitud HTTP de un exploit de la vulnerabilidad CVE-2025-27636 de Apache Camel. Si tiene éxito, esto haría que el servidor ejecutara un comando echo. Es una forma de probar un servidor que ejecuta Apache Camel si un atacante ya tiene acceso y puede ver los resultados de un comando echo.

Captura de pantalla de una solicitud HTTP GET con encabezados visibles, incluidos Host, User-Agent establecido en curl/7.61.1 y Accept que admite cualquier tipo, seguido de un intento de ejecución de comando. Se ha suprimido parte de la información.
Figura 19. Solicitud HTTP del exploit de Apache Camel para CVE-2025-27636.

En la Figura 20, se muestra la solicitud HTTP de un exploit de la vulnerabilidad CVE-2025-29891 de Apache Camel. Al igual que el intento de usar un exploit para Apache Tomcat que se muestra en la Figura 20, este exploit para Apache Camel pediría al servidor vulnerable que se contactara con un servidor OAST.

Captura de pantalla que muestra un ejemplo de solicitud GET y POST con la URL parcialmente visible como "http://". Parte de la información está suprimida.
Figura 20. Solicitud HTTP del exploit de Apache Camel para CVE-2025-29891.

Exploit CVE-2025-24813 en el entorno real

Desde que publicamos nuestra cobertura de esta vulnerabilidad, hemos observado 7,859 intentos de usar exploits para la vulnerabilidad CVE-2025-24813 de Apache Tomcat.

En esta sección, analizamos esta actividad desde dos perspectivas: la longitud del nombre de sesión y el valor del encabezado Content-Range.

Longitud del nombre de sesión de Tomcat

Como señalamos en el análisis anterior, los exploits para CVE-2025-24813 utilizan un nombre anexado con .session en la solicitud HTTP inicial. Este archivo .session contiene el código que el host vulnerable ejecutará si el exploit tiene éxito.

La mayoría de los prefijos de estos nombres de sesión utilizan menos de 10 caracteres. Nuestra telemetría revela que los prefijos más comunes utilizan 6 caracteres como nombre de sesión, como se muestra en la Figura 21.

Gráfico de barras que muestra el número de caracteres de los nombres de sesión. El eje x representa el recuento de nombres de sesión, y el eje y enumera rangos de recuento de caracteres desde menos de 4 hasta 10 o más. Conjunto de logos de Unit 42 y Palo Alto Networks.
Figura 21. Tendencias sobre la longitud del nombre de sesión en los intentos de exploit CVE-2025-24813.

Observamos este patrón de longitud de 6 caracteres en más de 6,000 detecciones. ¿Por qué la gran mayoría de esta actividad de exploits utiliza un nombre de sesión con una cadena de 6 caracteres? Este patrón de actividad se correlaciona con el encabezado Content-Range.

Encabezado Content-Range de Tomcat

Como señalamos en el análisis del código fuente de Tomcat para CVE-2025-24813, el encabezado HTTP para Content-Range es un factor importante en esta vulnerabilidad. En la Figura 22, se agrupan los diferentes valores de Content-Range.

Un gráfico de barras horizontales que muestra los recuentos de diferentes rangos de bytes, con un recuento variable para cada categoría. Conjunto de logos de Unit 42 y Palo Alto Networks.
Figura 22. Tendencias en los valores de Content-Range vistos en los intentos de exploit CVE-2025-24813.

Nuestra telemetría revela que observamos el encabezado Content-Range: bytes 0-452/457 en más de 6,000 detecciones. Este hallazgo se correlaciona con el nombre de sesión de 6 caracteres.

Estos dos hallazgos coinciden con el patrón de una plantilla CVE-2025-24813 para el escáner Nuclei disponible en GitHub. En la Figura 23, se destaca la correlación con nuestros resultados.

Captura de pantalla de un editor de texto que muestra código con líneas resaltadas relacionadas con una sesión HTTP y variables Python. Tres secciones destacadas con recuadros rojos. Son el nombre de archivo, PUT y Content-Range.
Figura 23. Segmento de la plantilla CVE-2025-24813 en el repositorio nuclei-templates de GitHub.

Esto significa que un gran número de los escaneos de CVE-2025-24813 que hemos visto hasta ahora han utilizado el escáner Nuclei. Esto tiene sentido, ya que Nuclei es un escáner disponible de manera gratuita bajo la licencia MIT que cualquiera puede utilizar. Es probable que tanto atacantes como defensores utilicen este escáner y esta plantilla para comprobar la vulnerabilidad.

Conclusión

Las instancias vulnerables de Apache Tomcat que permiten escribir directorio (desactivado por defecto) y PUT parcial (activado por defecto) son vulnerables a CVE-2025-24813. Las instancias vulnerables de Apache Camel que utilizan componentes específicos son vulnerables a CVE-2025-27636 y CVE-2025-29891.

Estas vulnerabilidades presentan un riesgo de seguridad significativo debido a los fallos críticos. Los atacantes pueden aprovecharse de ellas a través de solicitudes HTTP específicamente diseñadas.

Estos exploits no solo permiten la posible ejecución remota de código, sino que también plantean amenazas más amplias, como la vulneración de datos y el movimiento lateral dentro de la red. El uso del escáner Nuclei para comprobar esta vulnerabilidad subraya la facilidad con la que los adversarios menos cualificados pueden aprovechar estas vulnerabilidades, por lo que es crucial actuar de inmediato.

Protección y mitigación de Palo Alto Networks

Los clientes de Palo Alto Networks están mejor protegidos frente a las amenazas mencionadas gracias a los siguientes productos:

  • La suscripción del firewall de nueva generación con prevención de amenazas avanzada puede identificar y bloquear el tráfico asociado, si se siguen las prácticas recomendadas, mediante la siguiente firma de prevención de amenazas: 96,315
  • Cortex Xpanse y el complemento ASM para Cortex XSIAM pueden identificar servidores Apache Tomcat externos utilizando la regla de superficie de ataque “Servidor web Tomcat”. Los clientes también pueden ver sus activos potencialmente afectados a través del Centro de respuesta ante amenazas.

Si cree que puede haber resultado vulnerado o tiene un problema urgente, póngase en contacto con el equipo de respuesta ante incidentes de Unit 42 o llame al:

  • Norteamérica: llamada gratuita: +1 (866) 486-4842 (866.4.UNIT42)
  • Reino Unido: +44.20.3743.3660
  • Europa y Oriente Medio: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japón: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 00080005045107

Palo Alto Networks ha compartido estos resultados con nuestros compañeros de Cyber Threat Alliance (CTA). Los miembros de CTA utilizan esta inteligencia para implementar rápidamente medidas de protección para sus clientes y desarticular sistemáticamente a los ciberdelincuentes. Obtenga más información sobre Cyber Threat Alliance.

Indicadores de vulneración

CVE-2025-24813

Direcciones IP de origen observadas para CVE-2025-24813

  • 54.193.62[.]84
  • 96.113.95[.]10
  • 209.189.232[.]134
  • 162.241.149[.]101
  • 167.172.67[.]75
  • 100.65.135[.]245
  • 138.197.82[.]147
  • 123.16.159[.]102
  • 193.53.40[.]18
  • 91.208.206[.]203
  • 212.56.34[.]85
  • 195.164.49[.]70
  • 185.91.127[.]9

URL de actividad - CVE-2025-24813

  • PUT /qdigu/session
  • PUT /UlOLJo.session

Hash SHA256 de las muestras de carga útil

  • 6a9a0a3f0763a359737da801a48c7a0a7a75d6fa810418216628891893773540
  • 6b7912e550c66688c65f8cf8651b638defc4dbeabae5f0f6a23fb20d98333f6b

CVE-2025-27636, CVE-2025-29891

Direcciones IP de origen observadas para CVE-2025-27636, CVE-2025-29891

  • 30.153.178[.]49
  • 54.147.173[.]17
  • 54.120.8[.]214
  • 139.87.112[.]169
  • 139.87.112[.]115
  • 64.39.98[.]52
  • 139.87.112[.]98
  • 139.87.113[.]24
  • 64.39.98[.]139
  • 54.96.66[.]57
  • 138.197.82[.]147
  • 22.85.196[.]34
  • 64.39.98[.]245
  • 64.39.98[.]9
  • 54.120.8[.]207
  • 130.212.99[.]156
  • 139.87.112[.]121
  • 139.87.113[.]26

Encabezados de actividad para CVE-2025-27636, CVE-2025-29891

  • CAmelHttpResponseCode
  • CAmelExecCommandExecutable
  • CAmelExecCommandArgs
  • CAmelBeanMethodName

Recursos adicionales

Etiquetas

ÍNDICE

Artículos relacionados

Relacionados Vulnerabilidades Recursos

Enlarged Image

Obtenga las últimas noticias, invitaciones a eventos y alertas de amenazas

Default Heading

Read the article Right Arrow