CVE-2026-111073

W Apache Kafka domyślna klasa walidatora JWT (`DefaultJwtValidator`) akceptuje dowolne tokeny JWT bez weryfikacji podpisu, wystawcy ani odbiorcy. Atakujący może wygenerować token z dowolnego wystawcy z dowolną nazwą użytkownika, a broker go zaakceptuje.

Nieprawidłowy operator (CWE-480) w obsłudze RPC FetchSnapshot w Apache Kafka w wersjach od 2.8.0 przed 4.2.2 oraz od 4.3.0 przed 4.3.2 pozwala uwierzytelnionemu atakującemu z uprawnieniem CLUSTER_ACTION na wywołanie odmowy usługi. Wykorzystanie następuje poprzez spreparowane żądanie FetchSnapshotRequest z pustą tablicą tematów lub tematem bez partycji, co powoduje zakończenie procesu kontrolera.

Podatność w Apache Kafka pozwala uwierzytelnionemu producentowi z prawem zapisu do tematu na zadeklarowanie w skompresowanym rekordzie rozmiaru ciała do około 2 GiB, co powoduje próbę alokacji bufora i błąd OutOfMemoryError. Może to doprowadzić do zatrzymania wątków obsługi żądań brokera, konsumentów, a w przypadku wątku log-cleaner do trwałego zatrzymania kompakcji logów na brokerze.

Uwierzytelniony podmiot (principal) Kafki bez żadnych uprawnień autoryzacyjnych może zmusić brokera do odczytania pliku lub zmiennej środowiskowej z hosta brokera i zwrócenia ich zawartości. Żądanie IncrementalAlterConfigs lub AlterConfigs skierowane na zasób BROKER trafia do walidacji konfiguracji przed sprawdzeniem autoryzacji, a rozwiązywanie zmiennych konfiguracyjnych (${file:...}, ${env:...}) omija listę dozwolonych dostawców konfiguracji wprowadzoną jako mitygacja CVE-2024-31141.

W kilku ścieżkach deserializacji Apache Kafka pole rozmiaru lub liczby elementów jest odczytywane z danych wejściowych i używane bezpośrednio do alokacji tablicy, kolekcji lub bufora bajtów, bez sprawdzenia dostępnych danych. Mały spreparowany rekord może zadeklarować bardzo duży rozmiar i wymusić alokację wielu gigabajtów, powodując OutOfMemoryError. Dotyczy to m.in. ProcessorRecordContext, ChangedDeserializer, CombinedKeySchema, ProcessorMetadata i AssignmentInfo w Kafka Streams oraz ListDeserializer w bibliotece klienta.

Podatność w Apache Kafka dotyczy czytników generowanych dla elastycznych wersji protokołu, które odczytują liczbę pól tagowanych zadeklarowaną przez nadawcę i tworzą obiekt RawTaggedField dla każdego nieznanego pola. Liczba ta nie była ograniczona rozmiarem bufora ani stałym limitem, co pozwala na amplifikację — niewielkie żądanie może zadeklarować dziesiątki milionów pól i wymusić tyle samo alokacji obiektów, wyczerpując stertę brokera lub powodując pauzy GC. Nagłówek elastycznego żądania jest parsowany przed autoryzacją, więc atak może nastąpić przed uwierzytelnieniem, bez wymaganych ACL ani limitów.

Podatność w Apache Kafka polega na tym, że generowane czytniki protokołu wstępnie alokują kolekcję na podstawie liczby elementów zadeklarowanej przez nadawcę, sprawdzanej tylko względem pozostałych bajtów bufora (zakładając ok. 1 bajt na element). Dla tablic z kluczem czytnik alokuje kolekcję o pojemności (2 * liczba + 1), więc żądanie o rozmiarze kilkudziesięciu MB może wymusić alokację sterty wielokrotnie większą, zanim odczytany zostanie jakikolwiek element. Problem dotyczy wszystkich typów API Kafki z polem tablicowym.

W brokerze Apache Kafka używającym SASL/OAUTHBEARER z domyślnym walidatorem (DefaultJwtValidator), gdy parametr sasl.oauthbearer.jwks.endpoint.url nie jest ustawiony i nie dostarczono własnego resolvera kluczy, walidator po cichu przełącza się na ClientJwtValidator, który nie weryfikuje podpisu, algorytmu ani wystawcy JWT. Broker uruchamia się bez ostrzeżenia, akceptując każdy poprawny strukturalnie token, w tym tokeny z "alg":"none". Jest to pozostałość po CVE-2026-33557, którego poprawka przywróciła weryfikację podpisu tylko na ścieżce z ustawionym URL JWKS.

Broker Apache Kafka uwierzytelniający klientów przez SASL/OAUTHBEARER z walidatorem JWKS domyślnie weryfikuje podpis JWT, ale nie sprawdza roszczeń iss i aud, jeśli nie ustawiono opcji sasl.oauthbearer.expected.issuer i sasl.oauthbearer.expected.audience. W rezultacie token podpisany prawidłowo, ale wydany przez innego wystawcę lub bez roszczenia aud, może zostać zaakceptowany. Ryzyko dotyczy głównie środowisk z wielodostępnym JWKS lub współdzielonymi kluczami podpisującymi.

W Apache Kafka zidentyfikowano podatność nieprawidłowej autoryzacji w implementacji API CONSUMER_GROUP_DESCRIBE (69). API to waliduje operację DESCRIBE na zasobie GROUP zamiast operacji READ, co jest udokumentowane w oficjalnej dokumentacji i KIP-848. Może to prowadzić do błędnie skonfigurowanych list ACL i niezamierzonych postaw bezpieczeństwa.