CVE-2026-110952
Niskie ryzyko· EPSS 2%Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 2 - wyżej niż 2% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
W środowiskach, gdzie endpoint JWKS udostępnia klucze dla wielu wystawców, atakujący może użyć tokenu wydanego dla innego wystawcy lub bez roszczenia aud, aby uzyskać nieautoryzowany dostęp — potencjalnie jako uprzywilejowany podmiot. W prostych wdrożeniach z jednym wystawcą ekspozycja jest ograniczona, a zaufanie do podpisu jest zawsze egzekwowane.
Rekomendacja
Ustaw dla każdego listenera zarówno sasl.oauthbearer.expected.issuer (dokładna wartość iss od dostawcy), jak i sasl.oauthbearer.expected.audience (oczekiwane grupy odbiorców). Od Apache Kafka 4.4.0 broker z JWKS nie uruchomi się bez tych ustawień, chyba że świadomie wyłączysz weryfikację przez sasl.oauthbearer.allow.unverified.issuer=true lub sasl.oauthbearer.allow.unverified.audience=true.
Inne podatności w Apache Kafka
Zobacz wszystkie- CVE-2026-33557Krytyczne
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.
- CVE-2026-83525Niskie ryzyko· EPSS 8%
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.
- CVE-2026-114349Niskie ryzyko· EPSS 16%
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.
- CVE-2026-112375Niskie ryzyko· EPSS 13%
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.
- CVE-2026-111551Niskie ryzyko· EPSS 13%
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.
- CVE-2026-111115Niskie ryzyko· EPSS 15%
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.
- CVE-2026-111108Niskie ryzyko· EPSS 19%
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.
- CVE-2026-111073Niskie ryzyko· EPSS 10%
Podatność w brokerze Apache Kafka dotyczy API PushTelemetry (KIP-714), które waliduje jedynie rozmiar skompresowanego ładunku metryk względem telemetry.max.bytes, a następnie dekompresuje go bez limitu rozmiaru wyjściowego. Mały, silnie kompresowalny ładunek może rozrosnąć się do setek megabajtów sterty brokera, powodując OutOfMemoryError.
- CVE-2026-110985Niskie ryzyko· EPSS 2%
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.
- CVE-2026-41115Średnie
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.
Oryginalny opis (angielski, źródło NVD)
A Kafka broker that authenticates clients with SASL/OAUTHBEARER using the bundled JWKS-backed validator always verifies the JWT signature, but two further checks are only performed when explicitly configured: - The issuer (iss) claim is verified only when sasl.oauthbearer.expected.issuer is set. When it is unset, a validly-signed token carrying the expected audience is accepted regardless of which issuer minted it. - An audience (aud) claim is required only when sasl.oauthbearer.expected.audience is set. When it is unset, a validly-signed token that omits the aud claim is accepted. (A token that carries an aud claim is still rejected when no expected audience is configured.) Both options default to unset and have been documented as optional (Importance LOW) since KIP-768 (3.1.0). Impact: The exposure is realizable mainly in deployments whose JWKS endpoint serves signing keys for more than one issuer (a multi-tenant identity provider, an aggregated/shared JWKS, or shared signing keys): a token minted for a different issuer, or a token lacking an audience, may be accepted to authenticate — potentially as a higher-privileged principal. In a single-issuer deployment where the provider controls the iss claim and issues audience-scoped tokens, exposure is limited. The signature trust anchor remains enforced in all cases. This is distinct from CVE-2026-33557 (acceptance of unsigned/unvalidated tokens); here the signature is validated and only the issuer/audience checks are not enforced by default. Mitigation (all affected versions, no upgrade required): Set both sasl.oauthbearer.expected.issuer (to your provider's exact iss value) and sasl.oauthbearer.expected.audience (to the audience(s) your brokers expect), per listener. Brokers that set these perform exact-match issuer/audience checks and are not affected. Both have been available since 3.1.0. Resolution: - From Apache Kafka 4.4.0: a broker configured with a JWKS endpoint fails to start unless both sasl.oauthbearer.expected.issuer and sasl.oauthbearer.expected.audience are set (secure by default). Deployments that intentionally do not restrict the issuer and/or audience may opt out per axis with sasl.oauthbearer.allow.unverified.issuer=true and/or sasl.oauthbearer.allow.unverified.audience=true.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS