oscerd/cve-2026-85249Lauffähiger Spring Boot- und Quarkus-Reproducer für CVE-2026-85249, der die Injektion von camel-tika-Metadaten-Headern in CamelFileName mit betroffenen und korrigierten Kontrollen demonstriert.
CamelFileName)Lauffähiger Proof-of-Concept-Reproduzierer für die Apache-Camel-Schwachstelle, bei der der Tika-Producer jeden aus dem eingereichten Dokument extrahierten Metadaten-Schlüssel ungefiltert als Header auf die Exchange abbildete. Dokumentmetadaten sind vom Angreifer kontrollierter Inhalt: Die Partei, die die Datei bereitstellt, bestimmt die darin enthaltenen Metadaten-Schlüssel. Ein manipuliertes Dokument konnte daher Exchange-Header setzen, von denen der Rest der Route abhängt, einschließlich Header im Camel-Namespace wie CamelFileName, die nachgelagerte Komponenten verwenden, um zu entscheiden, wohin Inhalte geschrieben werden. Es handelt sich um dieselbe Klasse von Header-Injection wie in den Consumer-Advisories, die hier jedoch über geparsten Dateiinhalt statt über einen Protokoll-Header erreicht wird.
| Laufzeitumgebung | Verzeichnis | Stack |
|---|---|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-tika 4.22.0 (betroffen; behoben in 4.22.1) |
| Camel Quarkus | camel-quarkus/ | Quarkus 3.39.0 + camel-quarkus-tika (Camel 4.22.0, betroffen; behobene Kontrolle CQ 3.40.0 / Camel 4.22.1) |
Beide Module demonstrieren das betroffene und das behobene Verhalten.
Der Angreifer reicht ein HTML-Dokument ein — ein HTML-Attribut <meta name="..."> gelangt unverändert in Tikas Metadaten, sodass das Dokument die Header-Namen bestimmt:
<meta name="CamelFileName" content="ATTACKER-SET-../../pwned.txt"/>
<meta name="author" content="legitimate-metadata"/>
Die Route ist einfach from(...).to("tika:parse"). Nach dem Parsen werden die Exchange-Header inspiziert.
CamelFileName (Exchange.FILE_NAME) wird auf den Wert des Angreifers aus dem Dokument gesetzt. Ein nachgelagerter
Dateiproduzent würde diesen vom Angreifer gewählten Wert verwenden, um zu entscheiden, wohin der Inhalt geschrieben wird.CamelFileName wird herausgefiltert (nicht aus dem Dokument gesetzt), während gewöhnliche Metadaten wie author
weiterhin zugeordnet werden — der Filter blockiert nur den Camel-internen Namespace.# Camel Spring Boot
cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack # affected: document sets CamelFileName; >>> PROVEN
docker compose down
# Patched control
mvn clean package -Dcamel.version=4.22.1
java -jar target/cve-2026-85249-tika-header-injection-0.0.1-SNAPSHOT.jar &
curl -s http://localhost:8080/exploit/attack # fixed: CamelFileName filtered; >>> Not exploited
# Camel Quarkus
cd camel-quarkus
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack # affected (Camel 4.22.0): document sets CamelFileName
docker compose down
# Patched control: CQ 3.40.0 ships Camel 4.22.1
mvn clean package -Dcamel-quarkus.version=3.40.0 -Dquarkus.platform.version=3.40.0
java -jar target/quarkus-app/quarkus-run.jar &
curl -s http://localhost:8080/exploit/attack # fixed: CamelFileName filtered
| Eigenschaft | Wert |
|---|---|
| Komponente | camel-tika (TikaProducer.convertMetadataToHeaders) |
| CWE | CWE-20 (Unzureichende Eingabevalidierung) |
| Schweregrad | MITTEL |
| Angriffsvektor | Ein eingereichtes Dokument, dessen geparste Metadaten Camel-interne Header-Namen deklarieren (z. B. über HTML <meta name="CamelFileName">) |
| Auswirkung | Header-Injection: Ein Dokument setzt Exchange-Header, auf die sich die Route verlässt, wie etwa CamelFileName, der bestimmt, wohin nachgelagerte Komponenten Inhalte schreiben |
| Betroffene Versionen | Ab 4.0.0 vor 4.18.5, ab 4.19.0 vor 4.22.1 |
| Behobene Versionen | 4.18.5, 4.22.1, 4.23.0 |
| JIRA | CAMEL-24423 |
| Danksagung | Claude Security Scan Tool |
Advisory: https://camel.apache.org/security/CVE-2026-85249.html
TikaProducer.convertMetadataToHeaders filtert nun jeden geparsten Metadaten-
Namen durch eine HeaderFilterStrategy (konfiguriert mit inFilterStartsWith("Camel", "camel", "org.apache.camel."),
Groß-/Kleinschreibung wird ignoriert), bevor er auf den Exchange abgebildet wird — auf dieselbe Weise, wie ein Consumer
Namen filtert, die von einem externen Absender geliefert werden — sodass ein Dokument keinen Metadaten-Namen deklarieren
kann, der im Camel-internen Namensraum landet. Metadaten außerhalb dieses Namensraums werden weiterhin abgebildet.
Entfernen Sie den Camel-Namensraum nach dem Tika-Producer mit removeHeaders("Camel*"), bevor eine Komponente
verwendet wird, die auf diese Header reagiert.
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 präparierte Dokument und der injizierte Dateiname sind inerte lokale Testartefakte. Verwenden Sie dieses Material nicht gegen Systeme, die Ihnen nicht gehören oder die Sie nicht betreiben.