CVE-2026-95663

Niewystarczająca luka w zabezpieczeniach związana z wygaśnięciem sesji w komponencie Apache Camel Keycloak.



Ten problem dotyczy Apache Camel: od 4.16.0 przed 4.18.5, od 4.19.0 przed 4.22.2.



Gdy introspekcja tokenu jest włączona w Camel-Keycloak KeycloakSecurityPolicy (useTokenIntrospection=true), procesor bezpieczeństwa sprawdza token dostępu żądania, wysyłając go do punktu końcowego introspekcji tokenu OAuth 2.0 Keycloak i akceptuje token, podczas gdy odpowiedź zgłasza go jako aktywny. Punkt końcowy introspekcji zgłasza token jako nieaktywny po upływie czasu jego ważności (wygaśnięcia), więc na tej ścieżce aktywna flaga wymusza wygaśnięcie tokenu. Wyniki introspekcji są domyślnie buforowane (introspectionCacheEnabled=true, introspectionCacheTtl=60 sekund), a obie implementacje pamięci podręcznej dostarczone z komponentem, ConcurrentMapTokenCache i CaffeineTokenCache, utraciły ważność wpisu po ustalonym czasie po jego wstawieniu, bez ograniczania tego okresu istnienia przez stwierdzenie exp, które odpowiedź w pamięci podręcznej już zawierała. KeycloakSecurityProcessor z kolei sprawdzał tylko aktywną flagę wyniku, na każdej ścieżce korzystającej z introspekcji i nigdy nie porównywał expa z bieżącym czasem. Odpowiedź przechowywana w pamięci podręcznej na krótko przed wygaśnięciem tokena była zatem dostarczana do późniejszych żądań zawierających ten sam token aż do skonfigurowanego czasu życia po wygaśnięciu tokena, a żądania te zostały przyjęte z rolami i uprawnieniami, jakie posiadał wygasły token, chociaż RFC 7662, który definiuje introspekcję tokenu, stwierdza, że ​​odpowiedzi zawierającej exp nie można buforować po upływie tego czasu. Token dostępu jest dostarczany przez osobę wywołującą przy każdym żądaniu, zazwyczaj jako token nośnika w nagłówku Authorization, więc osoba wywołująca posiadająca token, który był ważny chwilę wcześniej, mogła go nadal używać po jego wygaśnięciu, tak długo jak istniał wpis w pamięci podręcznej. Okno jest ograniczone przez introspectionCacheTtl, który domyślnie wynosi 60 sekund i 300 do 600 sekund, jeśli zastosowano się do zaleceń dokumentacji dla usług wewnętrznych, i otwiera się tylko dla tokena, który ten sam proces Camela przeprowadził introspekcję i buforował, gdy token był nadal aktywny. Problem nie zapewnia niczego poza tym, co już zawiera token: nie pozwala na fałszowanie tokenów ani eskalację uprawnień, a introspekcja tokenów nie jest domyślnie włączona, dlatego ważność jest oceniana jako średnia. Ten problem nie dotyczy lokalnej ścieżki weryfikacji JWT, używanej, gdy introspekcja jest wyłączona.



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.2. Jeśli użytkownicy korzystają ze strumienia wydań 4.18.x, sugeruje się im aktualizację do wersji 4.18.5. Linie wydań 4.16.x, 4.17.xi 4.19.x do 4.21.x dobiegły końca przed rozwiązaniem tego problemu i nie otrzymają poprawki, więc wdrożenia w nich muszą zostać przeniesione do obsługiwanej wersji. W przypadku wdrożeń, których nie można uaktualnić natychmiast, ustaw introspectionCacheEnabled=false w KeycloakSecurityPolicy, aby każde żądanie było sprawdzane względem punktu końcowego introspekcji, który zgłasza wygasły token jako nieaktywny, kosztem jednego wywołania introspekcji na żądanie. Obniżenie introspekcjiCacheTtl jedynie zawęża okno, a nie je zamyka.