oscerd/cve-2026-78164Lauffähiger Proof-of-Concept für CVE-2026-78164, der das Offenlegen von Geheimnissen demonstriert, wenn Apache Camel HTTP-Producer Property-Platzhalter in vom Angreifer bereitgestellten CamelHttpUri-Headern auflösen.
Lauffähiger Proof-of-Concept-Reproducer für die Apache-Camel-Schwachstelle, bei der die HTTP-Producer-Familien zulassen, dass eine eingehende Nachricht den Endpoint-URI über die Header CamelHttpUri und CamelRestHttpUri überschreibt, und diese nachrichtenbereitgestellte Zeichenkette anschließend durch CamelContext.resolvePropertyPlaceholders() leiteten, bevor sie verwendet wurde.
Die Auflösung von Property-Platzhaltern ist eine Konfigurationsauflösungsfunktion, kein URI-Parsing-Schritt. Sie greift auf Betriebssystem-Umgebungsvariablen, JVM-System-Properties, jede PropertiesFunction im Classpath (einschließlich der Secret-Funktionen von AWS, Azure, GCP, HashiCorp, IBM, CyberArk und Kubernetes) und — über camel-bean — auf den Aufruf einer parameterlosen Methode auf einem beliebigen Bean in der Registry zu. Wendet man dies auf angreiferbeeinflusste Exchange-Inhalte an, wird aus einer URI-Zeichenkette ein Konfigurations- und Bean-Auswertungskontext. Ein Routenautor hat sich zu nichts davon entschieden: ein einfaches statisches to("http://backend/api") genügte.
| Laufzeitumgebung | Verzeichnis | Stack |
|---|---|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-http 4.22.0 (betroffen; behoben in 4.22.1) |
| Camel Quarkus | camel-quarkus/ | Quarkus 3.29.0 + camel-quarkus-http 3.29.0 (Camel 4.15.0, betroffen) |
Das Verhalten ist älter als die 4.x-Reihe (es reicht bis camel-http4 / camel-netty4 zurück), daher ist jede betroffene Version und auch das Camel 4.15.0 im aktuellen Camel Quarkus verwundbar. Der Fix erscheint in Camel 4.18.5 / 4.22.1 / 4.23.0; das Spring-Boot-Modul führt sowohl den betroffenen Build (4.22.0) als auch den behobenen Build (4.22.1) aus. Kein veröffentlichtes Camel Quarkus bündelt bisher ein behobenes Camel.
Die Route ist ein einfaches statisches to("http://127.0.0.1:9100/collect"), das auf einen lokalen Collector zeigt. Der Angreifer setzt den Header CamelHttpUri auf einen URI, der ein Property-Platzhalter-Token enthält — ohne den geheimen Wert zu kennen, er benennt nur den Schlüssel:
CamelHttpUri: http://127.0.0.1:9100/collect?leak={{sys:cve78164.secret}}
Die App setzt eine JVM-Systemeigenschaft cve78164.secret, die stellvertretend für einen beliebigen Konfigurationswert oder ein Vault-Secret steht. Beim betroffenen Build löst der Producer den Platzhalter auf, bevor die Anfrage hinausgeht, sodass der Collector das Secret in der ausgehenden Abfrage sieht. Beim behobenen Build wird das Token wörtlich weitergeleitet.
cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack
docker compose down
Erwartete Ausgabe beim betroffenen Build:
Outbound request observed by the collector:
GET /collect?leak=S3CR3T-cve78164-do-not-leak
>>> PROVEN: the {{sys:...}} placeholder in the attacker-supplied CamelHttpUri was resolved,
>>> expanding the secret 'S3CR3T-cve78164-do-not-leak' into the outbound request.
Beim korrigierten Build sieht der Collector stattdessen GET /collect?leak={{sys:cve78164.secret}} (literal, nicht aufgelöst).
| Eigenschaft | Wert |
|---|---|
| Komponente | camel-http / camel-http-common / camel-vertx-http / camel-undertow / camel-netty-http |
| CWE | CWE-1336 (Improper Neutralization of Special Elements Used in a Template Engine), CWE-200 (Information Exposure) |
| Schweregrad | HOCH |
| Angriffsvektor | CamelHttpUri / CamelRestHttpUri Override-Header, der ein {{...}}-Token trägt; Body/Header werden nicht durch bridgeEndpoint begrenzt, und mehrere Consumer befüllen CamelHttpUri aus der Request-Zeile als Reverse-Proxy-Funktion |
| Auswirkung | Expansion von Umgebungsvariablen, System-Properties und Vault-Secrets in die ausgehende Anfrage; argumentlose Invocation von Registry-Beans; ein Set/Unset-Konfigurationsschlüssel-Orakel über den zurückgegebenen Fehler |
| Betroffene Versionen | Ab 4.0.0 vor 4.18.5, ab 4.19.0 vor 4.22.1 (Verhalten existiert vor 4.x) |
| Korrigierte Versionen | 4.18.5, 4.22.1, 4.23.0 |
| JIRA | CAMEL-24418 |
| Credit | [email protected] |
Advisory: https://camel.apache.org/security/CVE-2026-78164.html
Der Aufruf resolvePropertyPlaceholders() pro Nachricht wird an jeder betroffenen Stelle entfernt, sodass ein {{...}}-Token, das
nur in CamelHttpUri oder CamelRestHttpUri erscheint, nun als literaler Teil der URI behandelt wird. Platzhalter in der
eigenen Endpoint-URI der Route sind nicht betroffen — sie werden einmal zur Build-Zeit aufgelöst, wenn der Endpoint erstellt wird.
Entfernen Sie die Override-Header an der Vertrauensgrenze vor dem Producer mit removeHeader("CamelHttpUri") und
removeHeader("CamelRestHttpUri"), oder setzen Sie skipControlHeaders=true auf camel-http-Endpoints (die einzige Komponente,
die diese Option bietet). bridgeEndpoint=true ist kein Workaround. Wenden Sie eine strikte eingehende HeaderFilterStrategy
auf Consumer an, die nicht vertrauenswürdigen Absendern ausgesetzt sind, und lösen Sie Secrets über einen Vault auf statt über Env-/System-
Properties, die ein Platzhalter benennen kann.
Dieses Repository wird zu Bildungs- und Verteidigungszwecken veröffentlicht: um Apache-Camel-Nutzern zu helfen, die Schwachstelle zu verstehen, zu prüfen, ob sie betroffen sind, und zu bestätigen, dass ein Upgrade sie behebt. Das „Secret" ist ein inertes lokales Fixture. Verwenden Sie dieses Material nicht gegen Systeme, die Ihnen nicht gehören oder die Sie nicht betreiben.