CVE-2026-59230
Apache Camel: Camel-Mail: Das MimeMultipart-Datenformat kopierte MIME-Header ohne eine Header-Filterstrategie auf die Camel-Nachricht, wenn das Unmarshalling mit aktiviertem headersInline durchgeführt wurde.
- Veröffentlicht
- 24.08.2026
- Aktualisiert
- 25.08.2026
- CNA zuweisen
- apache
- Beweise beobachtet
- 24.08.2026
Primäres CVSS
nvd · CVSS 3.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:NNiedrig · nächste 30 Tage
- Perzentil
- 35,8 %
- Modelldatum
- 21.09.2026
EPSS ist eine statistische Schätzung, keine Gewissheit oder ein Maß für die Auswirkung. Kombinieren Sie es mit CVSS, KEV-Status, Belichtung und Ihrer Umgebung.
Zusammenfassung
Schwachstelle durch unsachgemäße Eingabevalidierung in Apache Camel. Dieses Problem betrifft Apache Camel: von 2.17.0 vor 4.14.9, von 4.15.0 vor 4.18.4, von 4.19.0 vor 4.22.0. Die camel-mail-Komponente enthält ein MimeMultipart-Datenformat, das eine MIME-Multipart-Nachricht unmarshalen kann. Wenn es mit headersInline auf true konfiguriert ist, kopiert der Unmarshal-Pfad die MIME-Header der eingehenden Nachricht auf die Camel-Nachricht: Es zählt jeden Header auf, der nicht einer der drei Standard-Header ist, die es selbst erzeugt – Message-ID, MIME-Version und Content-Type –, und ruft für jeden setHeader auf, ohne eine HeaderFilterStrategy anzuwenden. Die Namen dieser MIME-Header stammen aus der Nachricht, die unmarshalt wird, sodass ein Absender, der die Nachricht beeinflussen kann, einen Header platzieren könnte, dessen Name in den Camel-internen Namensraum fällt, und ihn am Exchange setzen lassen könnte. Camel-Komponenten lesen Steuer-Header aus diesem Namensraum, um ihr konfiguriertes Verhalten zu überschreiben – der camel-sql-Produzent beispielsweise übernimmt die auszuführende Anweisung aus einem Camel-Header, wenn einer vorhanden ist –, sodass ein injizierter Header umleiten könnte, was ein nachgelagerter Schritt in der Route mit Daten tut, die der Routenautor nie dafür vorgesehen hatte, sie aus der Nachricht zu übernehmen. Welche Senken erreichbar sind und welche Konsequenzen sich ergeben, hängt vollständig davon ab, was die Route nach dem Unmarshal-Schritt tut. Der camel-mail-Consumer hat bereits eine Header-Filterstrategie auf seinem eigenen eingehenden Pfad angewendet, sodass dies der parallele eingehende Pfad in dieselbe Komponente war, den die frühere Härtung nicht abdeckte. Die betroffene Kopie wird nur erreicht, wenn headersInline aktiviert ist, was nicht die Standardeinstellung ist: Bei der Standardeinstellung werden die MIME-Header als Anhänge statt als Nachrichten-Header dargestellt und sind nicht betroffen. Das Verhalten geht auf die Einführung des Datenformats in 2.17.0 zurück und war in jeder Release-Linie bis zu diesem Fix vorhanden. Benutzern wird empfohlen, auf Version 4.22.0 zu aktualisieren, die das Problem behebt. Wenn Benutzer auf dem 4.14.x-LTS-Release-Stream sind, wird empfohlen, auf 4.14.9 zu aktualisieren. Wenn Benutzer auf dem 4.18.x-Release-Stream sind, wird empfohlen, auf 4.18.4 zu aktualisieren. Für Bereitstellungen, die nicht sofort aktualisieren können, lassen Sie headersInline auf seinem Standardwert false, wenn die Inline-Header nicht benötigt werden, da die Kopie nur erreicht wird, wenn es aktiviert ist. Wo es aktiviert bleiben muss, entfernen Sie Camel-interne Header sofort nach dem Unmarshal-Schritt, beispielsweise mit removeHeaders("Camel*"), das vor jeden Prozessor oder Produzenten gesetzt wird, der Steuer-Header liest, und unmarshallen Sie keine MIME-Inhalte von einem nicht vertrauenswürdigen Absender in eine Route, die nach Header-Werten dispatcht. Als Verteidigung in der Tiefe behandeln Sie die Header-Namen jeder MIME-Nachricht, die von außerhalb der Vertrauensgrenze eintrifft, als nicht vertrauenswürdige Eingabe.
Verantwortungsvoller Umgang
Verwenden Sie Schwachstelleninformationen nur auf Systemen, die Sie besitzen oder zu deren Testen Sie berechtigt sind. Kitploit verlinkt auf öffentliche Forschungsmetadaten und speichert keinen Exploit-Code oder bösartige Payloads.