CVE-2026-95664

Zusammenfassung

Schwachstelle „Improper Neutralization of Special Elements used in an Expression Language Statement“ („Expression Language Injection“) in der Apache-Camel-Komponente AWS2-s3. Dieses Problem betrifft Apache Camel: von 4.8.0 vor 4.18.5, von 4.19.0 vor 4.22.2. Für das Objekt, das er hochlädt, liest oder löscht, entnimmt der camel-aws2-s3-Producer den Schlüssel dem Nachrichten-Header CamelAwsS3Key und greift nur dann auf die am Endpoint konfigurierte Option keyName zurück, wenn dieser Header fehlt. Seit 4.8.0 übergab AWS2S3Utils.determineKey() den resultierenden Wert außerdem an die Simple-Sprache, wann immer er ${ oder $simple{ enthielt, sodass eine Route einen dynamischen Schlüssel verwenden konnte, und die Auswertung wurde sowohl auf einen aus dem Header entnommenen Wert als auch auf die konfigurierte Option angewendet. Der Header ist jedoch keine Routenkonfiguration: Der aws2-s3-Consumer setzt CamelAwsS3Key auf den Exchanges, die er erzeugt, auf den Schlüssel des Objekts, das er gelesen hat, also auf den Namen des Objekts im Bucket. In einer Route, die nichts weiter tut, als von einem aws2-s3-Endpoint zu konsumieren und an einen anderen zu produzieren, gelangte der Name jedes konsumierten Objekts daher zum Producer, und ein Name, der eines der beiden Marker enthielt, wurde als Ausdruck ausgewertet, obwohl der Autor der Route nie eine Auswertung verlangt hatte, und das Konfigurieren von keyName am Producer verhinderte dies nicht, da der Header Vorrang hatte. Ein Schlüssel, den eine Route aus anderen Nachrichteninhalten in den Header kopierte, wurde auf dieselbe Weise ausgewertet. Jeder, der den Namen eines Objekts in einem Bucket wählen konnte, von dem eine solche Route konsumiert – typischerweise ein Principal, der in diesen Bucket hochladen darf –, konnte daher Simple-Ausdrücke seiner Wahl im Camel-Prozess auswerten lassen. Die Simple-Sprache kann JVM-Systemeigenschaften, Umgebungsvariablen und Konfigurationseigenschaften lesen, die häufig Anmeldedaten enthalten, und, sofern camel-bean im Classpath liegt, Methoden auf Beans in der Registry aufrufen. Das ausgewertete Ergebnis wurde zum Schlüssel, den der Producer verwendete, sodass das Zurücklesen eines Werts zusätzlich die Fähigkeit erforderte, Objektnamen im Ziel-Bucket zu sehen, während ein Methodenaufruf ohne diese Möglichkeit wirksam wurde; zusammen mit der Notwendigkeit, ein Objekt in einem konsumierten Bucket zu benennen, ist dies der Grund, warum die Schwere als mittel eingestuft wird. Der Bucket-Name durchlief dieselbe Auswertung, aber der Consumer setzt in einen Bucket-Header stets nur den an seinem eigenen Endpoint konfigurierten Bucket, niemals einen von einem entfernten Objekt abgeleiteten Wert, sodass der Bucket-Name auf diesem Weg nicht erreichbar war. Releases vor 4.8.0 verwendeten den Schlüssel aus dem Header unverändert und sind nicht betroffen. Benutzern wird empfohlen, auf Version 4.23.0 zu aktualisieren, die das Problem behebt. Befinden sich Benutzer im Release-Stream 4.22.x, wird ihnen empfohlen, auf 4.22.2 zu aktualisieren. Befinden sich Benutzer im Release-Stream 4.18.x, wird ihnen empfohlen, auf 4.18.5 zu aktualisieren. Die Release-Linien 4.8.x bis 4.17.x und 4.19.x bis 4.21.x haben vor der Behebung dieses Problems ihr End-of-Life erreicht und erhalten keinen Fix, sodass Bereitstellungen auf ihnen auf ein unterstütztes Release wechseln müssen. Nach dem Upgrade wird ein über einen Nachrichten-Header übergebener Schlüssel- oder Bucket-Name wörtlich verwendet, sodass eine Route, die einen nicht ausgewerteten Simple-Ausdruck in den Header CamelAwsS3Key oder CamelAwsS3OverrideBucketName gesetzt hat, diesen stattdessen in der Route auswerten muss, zum Beispiel mit setHeader und simple(), oder ihn als Option keyName bzw. bucketName des Endpoints konfigurieren muss. Für Bereitstellungen, die nicht sofort aktualisieren können, darf ein Schlüssel, der von einem Objektnamen oder von anderen nicht vertrauenswürdigen Nachrichteninhalten abgeleitet ist, keinen aws2-s3-Producer ungeprüft erreichen: In Routen, die Exchanges von einem aws2-s3-Consumer an einen aws2-s3-Producer weitergeben, entweder den Header CamelAwsS3Key vor dem Producer mit removeHeader(“CamelAwsS3Key”) entfernen, sodass der am Endpoint konfigurierte keyName verwendet wird, oder Exchanges ablehnen, deren Header CamelAwsS3Key ${ oder $simple{ enthält. Das alleinige Konfigurieren von keyName ist kein Workaround, da der Header Vorrang vor ihm hat. Als Defense in Depth sollten nur vertrauenswürdige Principals in Buckets schreiben dürfen, von denen Camel-Routen konsumieren.