CVE-2026-78165

Zusammenfassung

Deserialisierung nicht vertrauenswürdiger Daten – Schwachstelle in der Apache-Camel-Spring-Redis-Komponente. Dieses Problem betrifft Apache Camel: von 2.11.0 bis vor 4.18.5, von 4.19.0 bis vor 4.22.1. RedisConfiguration.getSerializer erstellte bei fehlender Konfiguration einer Serializer-Option verzögert einen reinen JdkSerializationRedisSerializer, und diese Instanz wurde für jeden Lesevorgang der Komponente verwendet. Springs Implementierung delegiert über DeserializingConverter an DefaultDeserializer, der die Bytes mit einem ConfigurableObjectInputStream liest und keinen java.io.ObjectInputFilter auf dem Stream installiert, sodass ein beliebiger serialisierter Klassen-Graph materialisiert und dessen readObject-Methode ausgeführt wurde. RedisConsumer.setBody wandte diesen Serializer auf die Rohbytes jeder Nachricht an, die auf den abonnierten Kanälen veröffentlicht wurde, und zwar bevor der Exchange konstruiert wurde und somit bevor jegliche Routenlogik die Nachricht prüfen konnte; ein Akteur, der PUBLISH auf einem abonnierten Kanal ausführen konnte, erreichte daher direkt die Deserialisierungs-Senke. Derselbe Standard-Serializer lag dem von RedisConfiguration.createDefaultTemplate erstellten RedisTemplate zugrunde, sodass die Producer-Lesebefehle GET, HGET, HGETALL und HVALS alles deserialisierten, was im Redis-Keyspace gespeichert war, und SpringRedisIdempotentRepository dieses Template gemeinsam nutzte. Das Konfigurieren eines benutzerdefinierten redisTemplate schloss den Consumer-Pfad nicht, da RedisConsumer.setBody getSerializer direkt liest und nicht den an das Template gebundenen Serializer; eine Bereitstellung, die einen String-Serializer in ihr eigenes Template eingebunden hatte, blieb daher auf der Consumer-Seite exponiert, sofern nicht zusätzlich die serializer-Option gesetzt wurde. Die Komponente konstruierte selbst nie einen java.io.ObjectInputStream, weshalb frühere Durchläufe durch die Camel-Codebasis zur Suche nach ungefilterter Java-Deserialisierung sie nicht erreichten. Das Verhalten reicht bis zur Einführung der Komponente zurück, die erstmals in 2.11.0 veröffentlicht wurde, und blieb bis zu diesem Fix unverändert. Benutzern wird empfohlen, auf Version 4.23.0 zu aktualisieren, die das Problem behebt. Befinden sich Benutzer im Release-Zweig 4.22.x, wird ihnen ein Upgrade auf 4.22.1 empfohlen. Befinden sich Benutzer im Release-Zweig 4.18.x, wird ihnen ein Upgrade auf 4.18.5 empfohlen. Der Release-Zweig 4.14.x und früher erreichten ihr End-of-Life, bevor dieses Problem behoben wurde, und erhalten keinen Fix; Bereitstellungen auf diesen Linien müssen auf eine unterstützte Version wechseln. Für Bereitstellungen, die nicht sofort aktualisieren können, setzen Sie die JVM-weite Systemeigenschaft jdk.serialFilter, die der betroffene Codepfad berücksichtigt, da er über einen java.io.ObjectInputStream liest, zum Beispiel -Djdk.serialFilter=!java.net.**;java.**;javax.**;org.apache.camel.**;!* ; oder setzen Sie die Endpoint-Option serializer auf einen Serializer, der keine Java-Serialisierung verwendet, wie etwa StringRedisSerializer, wobei zu beachten ist, dass dies als serializer-Option gesetzt werden muss und nicht nur auf einem benutzerdefinierten redisTemplate. Als Defense in Depth verlangen Sie eine Authentifizierung auf der Redis-Instanz und beschränken Sie, welche Clients auf den abonnierten Kanälen veröffentlichen dürfen, und setzen Sie eine von Camel genutzte Redis-Instanz keinen nicht vertrauenswürdigen Netzwerken aus.

Quellen

• CVE-2026-78165PoC

  Lauffähiger Proof-of-Concept-Reproduzierer für CVE-2026-78165, der die ungefilterte JDK-Deserialisierung von Redis-PUBLISH-Payloads in Apache Camel camel-spring-redis demonstriert.