Zum Inhalt springen
← Zurück zum Cyberlagebild
Zuletzt aktualisiert 11.09.2026 16:13

CVE-2026-59230

CVSS 6.51 Quelle

Beschreibung

Sicherheitsanfälligkeit für fehlerhafte 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 Kamel-Mail-Komponente liefert ein MimeMultipart-Datenformat, das eine MIME-Multipart-Nachricht unmarshalieren kann. Wenn es mit headersInline auf true konfiguriert ist, kopiert der Unmarshal-Pfad die MIME-Header der eingehenden Nachricht auf die Camel-Nachricht: Er listet jeden Header auf, der nicht zu den drei Standard-Headern gehört, die er selbst generiert - Message-ID, MIME-Version und Content-Type - und ruft setHeader für jeden auf, wobei keine HeaderFilterStrategy angewendet wird. Die Namen dieser MIME-Header stammen von der Nachricht, die nicht marshalled ist, so dass ein Absender, der in der Lage ist, die Nachricht zu beeinflussen, einen Header platzieren kann, dessen Name in den Camel-internen Namespace fällt und ihn auf den Exchange einstellen lässt. Camel-Komponenten lesen Steuer-Header aus diesem Namespace, um ihr konfiguriertes Verhalten außer Kraft zu setzen - der Camel-Sql-Produzent zum Beispiel nimmt die Anweisung, um von einem Camel-Header auszuführen, wenn einer vorhanden ist -, so dass ein injizierter Header umleiten könnte, was ein nachgelagerter Schritt in der Route mit Daten macht, die der Routenautor nie beabsichtigte, aus der Nachricht zu nehmen. Welche Waschbecken erreichbar sind und was die Konsequenzen sind, hängt ganz davon ab, was die Route nach dem unmarschallischen Schritt tut. Der Kamel-Mail-Verbraucher wendete bereits eine Header-Filterstrategie auf seinem eigenen Inbound-Pfad an, so dass dies der parallele Inbound-Pfad in die gleiche Komponente war, die die frühere Verhärtung nicht abdeckte. Die betroffene Kopie wird nur erreicht, wenn headersInline aktiviert ist, was nicht der Standard ist: Mit der Standardeinstellung werden die MIME-Header als Anhänge und nicht als Nachrichten-Header aufgetaucht und sind nicht betroffen. Das Verhalten geht auf die Einführung des Datenformats in 2.17.0 zurück und war bis zu diesem Fix auf jeder Release-Linie vorhanden. Benutzern wird empfohlen, auf Version 4.22.0 zu aktualisieren, wodurch das Problem behoben wird. Wenn sich Benutzer auf dem 4.14.x LTS-Releases-Stream befinden, wird empfohlen, ein Upgrade auf 4.14.9 durchzuführen. Wenn Benutzer auf dem 4.18.x-Releases-Stream sind, wird empfohlen, ein Upgrade auf 4.18.4 durchzuführen. Bei Bereitstellungen, die nicht sofort aktualisiert werden können, lassen Sie headersInline bei seinem Standard von false, wo die Inline-Header nicht benötigt werden, da die Kopie nur erreicht wird, wenn sie aktiviert ist. Wenn es aktiviert bleiben muss, entfernen Sie Camel-interne Header unmittelbar nach dem Unmarshal-Schritt, z. B. mit removeHeaders("Camel*"), das vor einem Prozessor oder Produzenten platziert ist, der Kontroll-Header liest, und entfernen Sie MIME-Inhalte nicht von einem nicht vertrauenswürdigen Absender in eine Route, die auf Header-Werten versendet. Behandeln Sie als Verteidigung in der Tiefe die Header-Namen jeder MIME-Nachricht, die von außerhalb der Vertrauensgrenze ankommt, als nicht vertrauenswürdige Eingabe.

HerstellerApache Software Foundation
Produktcamel
ProduktfamilieKeine Angaben
Betroffene Versionen>=2.17.0 <4.14.9, >=4.15.0 <4.18.4, >=4.19.0 <4.22.0
Behobene VersionenKeine Angaben

Quellen & weiterführende Informationen

Hier werden ausschließlich tatsächlich zu dieser Schwachstelle gespeicherte Quellenbelege angezeigt.

Was ist zur Behebung zu tun?

Herstellerhinweise prüfen und das betroffene Produkt kurzfristig patchen oder kompensierende Schutzmaßnahmen aktivieren.

PrioritätGrün
EinordnungPlanbar behandeln und überwachen.

Empfohlene Schritte

  • Betroffene Systeme identifizieren: Apache Software Foundation camel.
  • Exposition prüfen: Internet-Erreichbarkeit, Admin-Oberflächen, VPN, Mail- oder Webdienste.
  • Hersteller-Advisory öffnen und verfügbare Updates, Workarounds oder Deaktivierungen prüfen.
  • Nacharbeiten dokumentieren: betroffene Assets, Maßnahme, Zeitpunkt, Restrestrisiko.

Übergangsmaßnahmen

  • Zugriff auf betroffene Dienste auf vertrauenswürdige Netze einschränken.
  • WAF/IDS/EDR-Regeln und Hersteller-IOCs aktivieren, sofern verfügbar.
  • Nicht benötigte Funktionen, Plugins oder Dienste temporär deaktivieren.