Detección y mitigación de las vulnerabilidades de Apache Camel
Resumen ejecutivo
El 9 de marzo de 2025, Apache Camel informó de la vulnerabilidad CVE-2025–27636, derivada del filtrado incorrecto de encabezados de solicitud, que puede provocar a la ejecución remota de código.
Esta vulnerabilidad reside en una biblioteca, que crea dependencia directa e indirecta y complica la detección y la mitigación.
En esta entrada de blog, los investigadores de Akamai proporcionan información detallada sobre la vulnerabilidad, las técnicas de explotación y las estrategias de detección.
Una regla rápida de Akamai Adaptive Security Engine proporciona automáticamente protección a los clientes de Akamai App & API Protector.
También proporcionamos una consulta en la función Insight de Akamai Guardicore Segmentation para la detección.
- Los clientes de Akamai Hunt afectados ya han recibido un listado detallado de los activos vulnerables.
- ACTUALIZACIÓN: El 11 de marzo de 2025, el grupo de inteligencia sobre seguridad de Akamai (SIG) informó de la omisión al equipo de seguridad de Apache Camel. El 12 de marzo de 2025, Apache publicó una nueva CVE: CVE-2025-29891.
Introducción
El 9 de marzo de 2025 se solucionó una vulnerabilidad en Apache Camel, una biblioteca Java ampliamente utilizada. Esta vulnerabilidad fue abordada por Apache y se corrigió en las versiones 4.10.2, 4.8.5 y 3.22.4. Aunque los informes iniciales afirmaban que esta vulnerabilidad podría tener un impacto crítico, el equipo de desarrolladores le asignó un nivel de gravedad moderado.
A pesar de esa clasificación de gravedad, se recomienda encarecidamente aplicar los parches lo antes posible si el entorno ejecuta las versiones que se han corregido. Sin embargo, las aplicaciones que ejecutan las versiones 4.10.0, 4.10.1, de la 4.8.0 a la 4.8.4, y de la 3.10.0 a la 3.22.3 aún pueden verse afectadas.
Para ser explotada, la aplicación vulnerable tiene que cumplir algunos requisitos específicos (que analizaremos a continuación en esta publicación). A pesar de ello, el impacto podría ser significativo. La explotación de la vulnerabilidad es muy sencilla y podría tener consecuencias devastadoras, incluida la ejecución remota de código.
La ubicuidad de Camel, junto con la naturaleza integrada de las vulnerabilidades en las bibliotecas, expresa la gravedad de esta detección. Esta entrada de blog tiene como objetivo ayudar a las organizaciones con su proceso de respuesta.
Examinaremos la vulnerabilidad y explicaremos su posible impacto en las aplicaciones, analizaremos su explotación para crear detecciones y abordaremos lo que quizás sea el desafío más difícil relacionado con esta y otras vulnerabilidades que se ocultan en las bibliotecas: identificar las aplicaciones vulnerables.
¿Qué es Apache Camel?
Apache Camel es un marco de integración de código abierto ampliamente utilizado que permite un intercambio de datos fluido entre diferentes sistemas, aplicaciones y servicios en la nube. Simplifica el enrutamiento, la transformación y la conectividad de los mensajes entre diversos entornos empresariales. Muchas organizaciones confían en Camel para los flujos de trabajo empresariales, las integraciones de API y la coordinación de microservicios de carácter crítico.
Análisis de CVE-2025-27636
Apache Camel utiliza DefaultHeaderFilterStrategy.java para impedir que los encabezados internos se reenvíen externamente. Esto evita que los encabezados filtren información de enrutamiento confidencial que los atacantes podrían explotar. Algunos ejemplos de estos encabezados son:
- CamelHttpResponseCode
- CamelHttpUri
- CamelContextId
- org.apache.camel.SomeInternalHeader
Este filtrado se aplica cuando los componentes basados en HTTP procesan solicitudes, como:
- camel-http y camel-http4 (procesamiento HTTP estándar)
- camel-rest (gestión de REST DSL)
- camel-cxf (servicios web con Apache CXF)
La vulnerabilidad se debe al filtrado incorrecto de encabezados de solicitud por parte de Camel. Antes de la corrección, Apache Camel utilizaba una regla de filtrado que distingue entre mayúsculas y minúsculas (Figura 1).
Fig. 1: Vulnerable filtering logic in Apache Camel DefaultHeaderFilterStrategy.java
Esta lógica solo coincidía con los encabezados que comenzaban por Camel o org.apache.camel (tal y como se muestra). Si un atacante cambia las mayúsculas y minúsculas y utiliza, por ejemplo, CAmelHttpUri o cAMELHttpResponseCode, el encabezado no se filtraría.
Esto significa que un atacante podría inyectar encabezados arbitrarios en nuestras solicitudes y hacer que Camel los reenvíe a los componentes internos. Es importante tener en cuenta, como menciona Apache en su asesoramiento, que la vulnerabilidad no permite el acceso a métodos internos arbitrarios, sino solo a los que están en el mismo bean declarado en el URI de bean. Este es uno de los requisitos específicos para la explotación, lo que significa que solo la ejecución de una versión vulnerable de Apache Camel no hace que una aplicación sea automáticamente vulnerable.
Realización de pruebas de la amenaza
Para demostrar la vulnerabilidad, hemos creado una aplicación vulnerable de ejemplo que se podrían explotar de forma remota. Esta aplicación escucha en el puerto HTTP 80 y, al recibir una solicitud, utiliza el componente "Exec" de Camel para ejecutar el comando whoami y mostrar el resultado al cliente.
Al invocar una solicitud simple mediante curl, se devuelve el resultado esperado: estar expuesto a la vulnerabilidad (Figura 2).
Fig. 2: Normal application operation that returns the result of the whoami command
Como podemos ver en el código, el comando whoami está definido estáticamente, lo que hace que el código parezca relativamente seguro. Los problemas surgen cuando inspeccionamos los posibles encabezados de mensajes internos compatibles con Exec. Al examinar el encabezado CamelExecCommandExecutable , vemos que este reemplaza al ejecutable definido en el URI estático en el código (Figura 3).
Fig. 3: Apache Camel Exec component documentation
Apache Camel filtraría los encabezados internos que coincidieran con las mayúsculas y minúsculas, como CamelExecCommandExecutable. Sin embargo, la vulnerabilidad CVE-2025–27636 permitiría omitir el filtro mediante la introducción del encabezadomelExecCommandExecutable de la CA (o con alguna otra diferencia de mayúsculas y minúsculas) y ejecutaría comandos arbitrarios en el servidor (Figura 4).
Fig. 4: Exploiting CVE-2025-27636 by including the CAmelExecCommandExecutable header
De forma similar, también podemos especificar el encabezadomelExecCommandArgs de la CA para suministrar parámetros al comando ejecutado (Figura 5).
Fig. 5: Using the CAmelExecCommandArgs header to specify command-line arguments
Este es un ejemplo sencillo que muestra cómo podría ser la explotación de esta vulnerabilidad. La capacidad de inyectar encabezados internos arbitrarios puede permitir que los atacantes pongan en peligro diversas aplicaciones, dependiendo de los componentes de Camel que utilice el servidor.
¿Cómo solucionó Apache Camel la vulnerabilidad CVE-2025-27636?
El problema se solucionó forzando la uniformidad de uso de mayúsculas y minúsculas. Se este modo se elimina la capacidad del atacante de manipular las mayúsculas y minúsculas para evadir el filtro. Por ejemplo, CAmelHttpUri se convierte en camelhttpuri, que ahora coincidiría con el filtro y, por lo tanto, sería detectado.
Introducción de .toLowerCase()
La instantánea de cambios (commit) de GitHub actualizó la lógica de filtrado de encabezados en DefaultHeaderFilterStrategy.java para incluir toLowerCase(Locale.ENGLISH) y, de ese modo, asegurarse de que todos los nombres de encabezado se conviertan a minúsculas antes de aplicar el filtro (Figura 6).
Fig. 6: The fix to CVE-2025-27636, implementing case-insensitive filtering
Además de la protección contra la inyección, la corrección también mantiene la eficiencia con una comprobación optimizada. La primera comprobación gestiona rápidamente las mayúsculas y minúsculas normales, como "Camel" y "camel". La comprobación .toLowerCase() comprueba solo las ejecuciones si es necesario, lo que evita costes de rendimiento innecesarios.
Detección de aplicaciones vulnerables
Identificar todas las instancias vulnerables de Apache Camel en una red puede ser todo un desafío. Los equipos de seguridad deben evaluar una amplia gama de activos, ya que Apache Camel está integrado en muchos lugares; por ejemplo, las aplicaciones en las que se utilicen las bibliotecas que los defensores desconocen.
La biblioteca puede estar presente como una dependencia indirecta, lo que significa que no se incluye explícitamente en el código fuente, sino a través de otro paquete de software. Esto añade una capa de complejidad para la detección y, por supuesto, la mitigación.
Apache Camel se puede identificar con frecuencia dentro de las aplicaciones Java mediante la búsqueda recursiva en directorios de archivos JAR que contengan "camel" en sus nombres. Una vez localizado un archivo JAR relacionado con Camel, se puede examinar su archivo de manifiesto para determinar la versión en uso.
Teniendo la versión extraída, los equipos de seguridad pueden compararla con el aviso de seguridad de Apache para evaluar posibles vulnerabilidades. Las versiones afectadas son las siguientes:
- 4.10.0 — vulnerable antes de la versión 4.10.2
- 4.8.0 — vulnerable antes de la versión 4.8.5
- 3.10.0 — vulnerable antes de la versión 3.22.4
Detección automatizada
Para facilitar la identificación de aplicaciones vulnerables, hemos desarrollado scripts de PowerShell y Bash que exploran directorios de forma recursiva, detectan archivos JAR de Apache Camel y muestran las aplicaciones potencialmente vulnerables. Hemos incluido opciones tanto para Windows como para Linux. Los clientes afectados de Akamai Hunt ya han recibido un listado detallado de sus activos vulnerables.
Detección con Akamai Guardicore Segmentation
Para los clientes de Akamai Guardicore Segmentation , hemos creado una consulta de Insight que puede identificar loas activos vulnerables. En los casos en los que el resultado de la consulta indique que no se ha encontrado la versión del archivo ("Version not found"), el hash devuelto se puede comprobar en VirusTotal o a través del archivo de manifiesto incluido en el JAR para obtener la versión correcta.
Windows
WITH relevant_cwds as (
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
mmap.path AS mmap_path
FROM process_memory_map AS mmap
LEFT JOIN processes AS proc USING(pid)
WHERE mmap_path LIKE "%jvm%"
UNION
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
proc.path AS placeholder_path
FROM processes AS proc
WHERE proc.name IN ("java", "javaw", "java.exe", "javaw.exe")
),
RELEVANT_JAR_PATHS AS (
SELECT file.path as lib_path, cwd, cwd || '..\%\%\camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '..\%\camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '%\%\camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
)
SELECT lib_path, relevant_cwds.path as proc_path,
CASE WHEN lib_path LIKE '%camel-core-2%' OR lib_path LIKE '%camel-core-3%' OR lib_path LIKE '%camel-core-4%' THEN SUBSTR(lib_path, INSTR(lib_path, 'camel-core-') + 11, INSTR(lib_path, '.jar') - (INSTR(lib_path, 'camel-core-') + 11))
WHEN lib_path like '%camel-core.jar' THEN 'Version not found' ELSE NULL END as version, cmdline, sha256 FROM RELEVANT_JAR_PATHS
INNER JOIN relevant_cwds ON relevant_cwds.cwd = RELEVANT_JAR_PATHS.cwd
WHERE
version is not null
Linux
WITH relevant_cwds as (
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
mmap.path AS mmap_path
FROM process_memory_map AS mmap
LEFT JOIN processes AS proc USING(pid)
WHERE mmap_path LIKE "%jvm%"
UNION
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
proc.path AS placeholder_path
FROM processes AS proc
WHERE proc.name IN ("java", "javaw", "java.exe", "javaw.exe")
),
RELEVANT_JAR_PATHS AS (
SELECT file.path as lib_path, cwd, cwd || '/../%/%/camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '/../%/camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '/%/%/camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
)
SELECT lib_path, relevant_cwds.path as proc_path,
CASE WHEN lib_path LIKE '%camel-core-2%' OR lib_path LIKE '%camel-core-3%' OR lib_path LIKE '%camel-core-4%' THEN SUBSTR(lib_path, INSTR(lib_path, 'camel-core-') + 11, INSTR(lib_path, '.jar') - (INSTR(lib_path, 'camel-core-') + 11))
WHEN lib_path like '%camel-core.jar' THEN 'Version not found' ELSE NULL END as version, cmdline, sha256 FROM RELEVANT_JAR_PATHS
INNER JOIN relevant_cwds ON relevant_cwds.cwd = RELEVANT_JAR_PATHS.cwd
WHERE
version is not null
Mitigación con Akamai App & API Protector
El viernes 7 de marzo de 2025, el equipo de investigación de amenazas de Akamai implementó una regla rápida de Adaptive Security Engine para los clientes de App & API Protector:
3000911 v2 - Apache Camel (CVE-2025-27636) Attack Detected - Default Action: Deny
Los clientes que tienen activadas las reglas rápidas con la acción predeterminada definida en "Akamai Managed" están protegidos automáticamente frente a esta amenaza. Los clientes que utilizan reglas rápidas con la acción predeterminada definida en "Alert" deben evaluar cualquier activador de reglas y definir la acción de la regla en la opción de denegar.
La regla rápida 3000911 está diseñada para activarse en encabezados que, de algún otro modo, hayan eludido la lógica de filtrado interna de Camel (Figura 7). La regla no se activará en los encabezados Camel normales para evitar cualquier impacto en las operaciones legítimas de los clientes.
Fig. 7: Rapid Rule 3000911 triggering on attack payload
Tráfico de ataque observado
Las cargas útiles de ataque actuales que ha observado el grupo de inteligencia sobre seguridad de Akamai solo intentan confirmar la vulnerabilidad en lugar de explotarla. La mayoría de las cargas útiles observadas utilizan dos estrategias diferentes para confirmar la vulnerabilidad.
En primer lugar, hemos observado el uso del nombre de encabezado CAmELDestinationOverrideUrl, donde la carga útil es un dominio de baliza fuera de banda (OOB). Este tráfico proviene de un proveedor de análisis de vulnerabilidades comerciales y la URL de la carga útil se envía como baliza de vuelta a su dominio (Figura 8).
Fig. 8: Rapid Rule 3000911 blocking payload attempting to perform server-side request forgery
En segundo lugar, hemos visto cargas útiles que utilizan el encabezado CAmelHttpResponseCode en un intento de obtener un código de estado de respuesta HTTP específico del servidor (Figura 9). Si la carga útil ha tenido éxito, el código de estado de respuesta HTTP devuelto por el servidor coincidiría con el proporcionado en la carga útil.
Fig. 9: Rapid Rule 3000911 blocking payload attempting to override HTTP response status code
Por último, hemos observado que las dos cargas útiles anteriores intentan evadir la detección mediante el uso de una codificación de URL sencilla, como ca%4d%45%6cHttpResponseCode (Figura 10). Sin embargo, Adaptive Security Engine consigue detectar y bloquear estos intentos.
Fig. 10: Rapid Rule 3000911 blocking obfuscated payload
ACTUALIZACIÓN: CVE-2025-29891
El SIG de Akamai, en colaboración con Citi Cyber Security Operations, identificó un vector de explotación adicional derivado del mismo problema de filtrado que provocó la vulnerabilidad CVE-2025-27636. Durante la prueba de nuestra aplicación vulnerable, identificamos que, además de los encabezados de solicitud, los parámetros de cadena de consulta y cuerpo de POST también proporcionan una ruta de ataque válida.
En la figura 11, observamos que especificar el parámetro de consulta CAmelExecCommandExecutable conduce a la ejecución de comandos arbitrarios, al igual que el vector de encabezado original.
Fig. 11: Command injection in either a header or a parameter using CAmelExecCommandExecutable
El SIG de Akamai informó de la omisión al equipo de seguridad de Apache Camel. Validaron los resultados y crearon una nueva CVE: CVE-2025-29891. Las correcciones codificadas en Apache Camel de CVE-2025-27636 también corrigen esta omisión, pero Akamai tuvo que publicar una versión actualizada de la Regla Rápida 3000911 v3 de App & API Protector el 12 de marzo de 2025 para corregir esta brecha.
El parche original para corregir la CVE-2025-27636 también resuelve este problema, por lo que las aplicaciones que utilizan versiones actualizadas de Apache Camel no son vulnerables a este vector de explotación.
Hemos actualizado nuestro repositorio de GitHub, que ahora también contiene detalles sobre la CVE-2025-29891 y su explotación.
Aunque la explotación de la vulnerabilidad anterior se podría detectar mediante la inspección de los encabezados de solicitud, este problema también requiere el filtrado de los parámetros de solicitud.
Resumen
Las vulnerabilidades dentro de las bibliotecas no solo tienen implicaciones directas para las aplicaciones. También se pueden ocultar en lugares desconocidos, lo que hace que sea extremadamente difícil detectarlas y mitigarlas. Al uso generalizado de Apache Camel se suma el hecho de que un atacante con el conjunto correcto de herramientas también podría utilizarlo para ejecutar código de forma remota, lo que aumenta el nivel de gravedad. Se recomienda seguir el plan de acción sugerido por Apache y aplicar parches lo antes posible en el entorno.
El grupo de inteligencia sobre seguridad de Akamai seguirá supervisando, informando y creando mitigaciones para amenazas de este tipo tanto para nuestros clientes como para la comunidad de seguridad en general. Para estar al día de las últimas noticias del grupo de inteligencia sobre seguridad de Akamai, consulte nuestra página de inicio sobre investigación y síganos en las redes sociales.