CVE-2026-78165

Deserializacja luki w zabezpieczeniach niezaufanych danych w komponencie Apache Camel Spring Redis.



Ten problem dotyczy Apache Camel: od 2.11.0 przed 4.18.5, od 4.19.0 przed 4.22.1.



RedisConfiguration.getSerializer leniwie budował goły JdkSerializationRedisSerializer za każdym razem, gdy nie skonfigurowano żadnej opcji serializatora, a ta instancja była używana przy każdym odczycie wykonywanym przez komponent. Implementacja Springa deleguje poprzez DeserializingConverter do DefaultDeserializer, który odczytuje bajty za pomocą ConfigurableObjectInputStream i nie instaluje żadnego java.io.ObjectInputFilter w strumieniu, więc zmaterializował się dowolny serializowany wykres klasy i wykonano jego metodę readObject. RedisConsumer.setBody zastosował ten serializator do nieprzetworzonych bajtów każdej wiadomości opublikowanej w subskrybowanych kanałach, zanim zbudowano Exchange, a zatem zanim jakakolwiek logika trasy mogła sprawdzić wiadomość, więc aktor mogący wydać PUBLISH na subskrybowanym kanale dotarł bezpośrednio do ujścia deserializacji. Ten sam domyślny serializator wspierał RedisTemplate zbudowany przez RedisConfiguration.createDefaultTemplate, więc producent poleceń odczytu GET, HGET, HGETALL i HVALS deserializował wszystko, co było przechowywane w przestrzeni kluczy Redis, a SpringRedisIdempotentRepository udostępnił ten szablon. Skonfigurowanie niestandardowego redisTemplate nie zamknęło ścieżki konsumenta, ponieważ RedisConsumer.setBody odczytuje bezpośrednio getSerializer, a nie serializator dołączony do szablonu, więc wdrożenie, które podłączyło serializator String do własnego szablonu, pozostało ujawnione po stronie konsumenta, chyba że ustawiono również opcję serializatora. Komponent nigdy sam nie skonstruował strumienia java.io.ObjectInputStream, dlatego też wcześniejsze przejścia przez bazę kodu Camela w celu niefiltrowanej deserializacji Java do niego nie dotarły. Zachowanie to zaczęło się od wprowadzenia komponentu wydanego po raz pierwszy w wersji 2.11.0 i pozostało niezmienione aż do tej poprawki.



Użytkownikom zaleca się aktualizację do wersji 4.23.0, która rozwiązuje problem. Jeśli użytkownicy korzystają ze strumienia wydań 4.22.x, sugeruje się im aktualizację do wersji 4.22.1. Jeśli użytkownicy korzystają ze strumienia wydań 4.18.x, sugeruje się im aktualizację do wersji 4.18.5. Strumień wersji 4.14.x dobiegł końca, zanim problem został rozwiązany i nie otrzymał poprawki, więc wdrożenia na tych liniach muszą zostać przeniesione do obsługiwanej wersji. W przypadku wdrożeń, których nie można uaktualnić natychmiast, ustaw właściwość systemową jdk.serialFilter obejmującą całą maszynę JVM, która będzie uwzględniana przez ścieżkę kodu, której dotyczy problem, ponieważ odczytuje strumień java.io.ObjectInputStream, na przykład -Djdk.serialFilter=!java.net.**;java.**;javax.**;org.apache.camel.**;!* ; lub ustaw opcję punktu końcowego serializatora na serializator, który nie używa serializacji Java, taki jak StringRedisSerializer, zauważając, że należy to ustawić jako opcję serializatora, a nie tylko w niestandardowym redisTemplate. W ramach dogłębnej obrony wymagaj uwierzytelnienia w instancji Redis i ograniczaj, którzy klienci mogą publikować w subskrybowanych kanałach, i nie udostępniaj instancji Redis wykorzystywanej przez Camel niezaufanym sieciom.