CVE-2026-112375
Niskie ryzyko· EPSS 13%Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 13 - wyżej niż 13% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Atakujący z ważnym kontem, ale bez uprawnień, może ujawnić poświadczenia, keystore'y i inne sekrety dostępne dla procesu brokera, co może prowadzić do dalszej eskalacji i przejęcia klastra. Klaster pozostaje dostępny — problem dotyczy wycieku danych.
Rekomendacja
Zaktualizuj Apache Kafka do wersji 4.2.2, 4.3.2 lub 4.4.0. Dodatkowo uruchamiaj brokery na koncie systemowym o minimalnych uprawnieniach, aby wrażliwe pliki nie były czytelne dla procesu brokera.
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-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-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)
An authenticated Kafka principal with no authorization grants (not even ALTER_CONFIGS) can make a broker read a file or an environment variable from the broker host and return its contents. An IncrementalAlterConfigs (or AlterConfigs) request targeting a BROKER resource reaches the broker's configuration validation before any authorization check is applied to that path. Validation resolves configuration variables such as ${file:/path:key} or ${env:VAR} using a ConfigProvider named in the request, and this resolution bypasses the org.apache.kafka.automatic.config.providers allowlist that was added as the mitigation for CVE-2024-31141. An arbitrary ConfigProvider (for example FileConfigProvider or EnvVarConfigProvider) is therefore instantiated and the referenced file or environment variable is read, and a type-validation error returns the resolved content to the caller. Impact: On a cluster with an authorizer enabled, an authenticated principal with no authorization grants can read the contents of files accessible to the broker process, and the broker's environment variables, exposing credentials, keystores, or other secrets, defeating the CVE-2024-31141 allowlist. The read is bounded by the broker process's file permissions. The brokers and the cluster remain available; the issue is disclosure of file and environment- variable contents. Clusters with no authorizer configured are not affected in practice, because every principal already holds ALTER_CONFIGS there. Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. As defense in depth, run brokers under a least-privileged operating-system account so that sensitive files are not readable by the broker process. Resolution: From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: broker configuration changes are authorized (ALTER_CONFIGS on the cluster) before the configuration is validated, and configuration- variable resolution enforces the config-providers allowlist.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS