camel-iggy Reproducción de Inyección de Encabezados de Usuario (CVE-2026-55994)

Este proyecto demuestra una inyección de encabezados de mensaje en el componente camel-iggy de Apache Camel, registrada como CVE-2026-55994. El consumidor Iggy copia los encabezados de usuario (user-headers) de un mensaje entrante al Exchange de Camel sin ningún HeaderFilterStrategy, por lo que cualquiera que pueda publicar en el topic Iggy consumido puede inyectar encabezados de control de Camel — notablemente CamelHttpUri:

// IggyFetchRecords.createExchange (affected 4.18.2) — Iggy message user-headers -> Exchange headers, unfiltered
message.userHeaders().ifPresent(userHeaders -> {
    Map<String, Object> stringUserHeaders = userHeaders.entrySet().stream().collect(Collectors.toMap(
            e -> e.getKey(),
            e -> e.getValue().value()));
    exchange.getIn().setHeaders(stringUserHeaders);
});

Cuando la ruta conecta este consumidor con un productor HTTP, un CamelHttpUri inyectado sobrescribe la URI de destino del productor — falsificación de solicitud del lado del servidor (SSRF). El productor camel-http también llama a resolvePropertyPlaceholders() en esa URI controlada por el atacante, por lo que una referencia {{...}} inyectada se expande a su valor real y se envía — revelando variables de entorno, propiedades de aplicación o secretos de vault.

Este PoC demuestra el impacto como SSRF más divulgación de secretos (CWE-20 → CWE-918 + CWE-200). Es uno de tres componentes hermanos corregidos juntos bajo CAMEL-23532 (junto con camel-vertx-websocket, CVE-2026-46726, y camel-atmosphere-websocket, CVE-2026-55993).

Aviso: https://camel.apache.org/security/CVE-2026-55994.html

Resumen de la Vulnerabilidad

La corrección aplica un HeaderFilterStrategy al mapeo de entrada, filtrando los encabezados Camel* / camel* para que ya no puedan ser inyectados a través de los encabezados de usuario de un mensaje Iggy.

Cómo este reproductor ejercita el código vulnerable real

El vulnerable IggyFetchRecords.createExchange(...) se ejecuta sin cambios, sobre un mensaje Iggy falsificado cuyos encabezados de usuario están controlados por el atacante. El Exchange resultante fluye a través de la ruta real hacia el productor camel-http real, por lo que el SSRF y la divulgación del marcador de posición de propiedades {{...}} son genuinos.

Por qué no se utiliza un broker Iggy en vivo. El doStart del consumidor iggy: abre una conexión a un servidor Iggy en ejecución, por lo que la ruta no puede iniciarse sin uno — y el servidor Apache Iggy requiere io_uring, que el perfil seccomp predeterminado de Docker bloquea (se ejecuta solo con --privileged), lo que lo hace inadecuado para un PoC portátil y compartible. El createExchange vulnerable en sí no necesita un broker, por lo que el controlador construye el IggyFetchRecords real y lo invoca directamente con el mensaje falsificado. El PoC hermano camel-vertx-websocket (CVE-2026-46726) explota el mismo defecto a través de un transporte en vivo.

La ruta víctima

En un despliegue real: from("iggy:orders?streamName=demo&...").to("http://.../legit-backend"). Aquí la mitad aguas abajo es from("direct:iggy-delivery").to("http://localhost:8080/legit-backend"), alimentada con el Exchange envenenado construido por el createExchange real.

Estructura del repositorio

CVE-2026-55994/
├── pom.xml                 # camel-iggy + camel-http 4.18.2
├── Dockerfile
├── docker-compose.yml      # single self-contained service
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java
    │   ├── VictimRoute.java        # enlace aguas abajo -> http://localhost:8080/legit-backend
    │   ├── SinkController.java     # colector SSRF: /legit-backend, /internal/secret, /collect
    │   └── ExploitController.java  # falsifica un mensaje Iggy + ejecuta el createExchange real (inyecta CamelHttpUri)
    └── resources/
        └── application.properties  # app.secret=... (filtrado mediante resolución de marcadores de posición)

Requisitos previos

• Docker y Docker Compose
• Java 17+ y Maven 3.8+

Pasos de reproducción

mvn clean package -DskipTests
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack
docker compose down

Salida esperada

1) Ordinary message (user-header x-order-id=A-1001)
     reached /legit-backend: true
     reached /internal/secret: false

2) Injected user-header 'CamelHttpUri=http://localhost:8080/internal/secret'  (SSRF)
     server-side request reached /internal/secret: true

3) Injected user-header 'CamelHttpUri=http://localhost:8080/collect?leak={{app.secret}}'  (secret disclosure)
     attacker's collector received leak = SUPER-SECRET-abc123
     equals the app's real secret: true

>>> SSRF=true, secret-disclosure=true

Corrección recomendada

Se recomienda actualizar a 4.18.3 / 4.21.0 (CAMEL-23532). Después de la actualización, el consumidor filtra los encabezados Camel* de los encabezados de usuario del mensaje Iggy, por lo que CamelHttpUri y otros encabezados de control ya no pueden ser inyectados.

Mitigación

Hasta la actualización, no conecte un consumidor iggy: directamente a un productor HTTP sin eliminar primero los encabezados de control de Camel (por ejemplo removeHeaders("CamelHttp*")), y establezca el destino del productor desde una fuente confiable (o use bridgeEndpoint=true).

Descargo de responsabilidad

Este reproductor se proporciona solo para investigación de seguridad y pruebas autorizadas, para una vulnerabilidad divulgada públicamente y corregida. No lo use contra sistemas sin permiso explícito.