CVE-2026-111115
Niskie ryzyko· EPSS 15%Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 15 - wyżej niż 15% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Atakujący może zdalnie wywołać odmowę usługi brokera Kafka poprzez wysłanie żądania z ogromną liczbą pól tagowanych w nagłówku, co prowadzi do wyczerpania pamięci lub długich pauz GC i niedostępności klastra. Ryzyko jest wysokie, ponieważ nie wymaga uwierzytelnienia ani uprawnień.
Rekomendacja
Należy zaktualizować Apache Kafka do wersji 4.2.2, 4.3.2 lub 4.4.0. Do czasu aktualizacji zaleca się obniżenie socket.request.max.bytes oraz ograniczenie dostępu sieciowego do listenerów brokera, choć środki te jedynie zmniejszają, a nie eliminują ekspozycję.
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-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-110952Niskie ryzyko· EPSS 2%
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.
- 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)
Apache Kafka's code-generated readers for flexible protocol versions read a tagged-field count declared by the sender and retain a RawTaggedField object for each unknown field. That count was bounded only by the outer request frame size (socket.request.max.bytes); it was not checked against the remaining buffer bytes or capped. Because each entry can be encoded in as little as two bytes (unknown tag 0, size 0), a modest request can declare tens of millions of tagged fields and force one object allocation per declared field. Flexible request headers (header version 2, used by flexible APIs such as ApiVersions v3) are parsed this way, so the amplification applies to the request header itself. Impact: The flexible request header is parsed on the network thread before authorization, request dispatch, and request-time quota accounting. A client can send a request of a few tens of megabytes whose header declares about 20 million tagged fields, forcing roughly that many RawTaggedField allocations and exhausting broker heap or inducing process-wide GC stalls, denying broker service. Because the header is parsed for pre-authentication APIs such as ApiVersions (v3), the allocation can occur before authentication; no Kafka resource ACL or quota is required. Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Until then, lowering socket.request.max.bytes and restricting network access to broker listeners reduces, but does not remove, exposure. Resolution: From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers bounds-check the tagged-field count for flexible-versioned messages, rejecting a negative count, a count exceeding the remaining buffer bytes, or a count exceeding a fixed maximum (10,000), before any per-field allocation.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS