Apache Kafka CVE-2026-33557

Exploitation requires the target Apache Kafka broker to be running version 4.1.0 or 4.1.1 with SASL/OAUTHBEARER authentication mechanism enabled and the broker property sasl.oauthbearer.jwt.validator.class set to its default value of org.apache.kafka.common.security.oauthbearer.DefaultJwtValidator (or not explicitly configured, defaulting to this validator). Network connectivity to the Kafka broker's listener ports (typically 9092 or 9093) is required. Exploitation is LIMITED by authentication mechanism-Kafka deployments using SASL/PLAIN, SASL/SCRAM-SHA-256, SASL/SCRAM-SHA-512, Kerberos (GSSAPI), or mutual TLS authentication are NOT vulnerable. Deployments that have explicitly configured the secure BrokerJwtValidator are also not affected. The attack complexity is low (AC:L) as it requires only the ability to generate JWT tokens with arbitrary claims and network access to the broker, with no user interaction (UI:N) or legitimate credentials (PR:N) needed.

This represents a critical authentication bypass with high real-world risk despite no confirmed exploitation. CVSS 9.1 accurately reflects severity: network-accessible (AV:N), low complexity (AC:L), no privileges required (PR:N), no user interaction (UI:N), with high confidentiality and integrity impact. The SSVC assessment confirms the vulnerability is automatable-an attacker can script token generation without complex preconditions-though marks technical impact as partial rather than total. EPSS data not provided, but the attack simplicity suggests high exploitation probability once awareness spreads. The narrow affected version range (only 4.1.0 and 4.1.1) limits exposure, and the availability of fixed versions (4.1.2+ and 4.2.0+) plus a configuration workaround reduces sustained risk. However, organizations running affected versions with SASL/OAUTHBEARER enabled face immediate risk of unauthorized data access and message manipulation. The authentication bypass grants access to all Kafka operations the impersonated user would have, making this a full access control failure. Priority should be HIGH for organizations using SASL/OAUTHBEARER authentication in affected versions, MEDIUM for those using other authentication mechanisms (not vulnerable), and LOW for organizations already on 4.1.2+ or 4.2.0+.

An attacker identifies a Kafka cluster running version 4.1.0 or 4.1.1 with SASL/OAUTHBEARER authentication exposed on the network. Using publicly available JWT libraries, they generate a malicious token with the 'preferred_username' claim set to 'kafka-admin' or another privileged user identity, signing it with their own key or leaving it unsigned. They configure a Kafka client to present this forged token during SASL authentication. The broker's DefaultJwtValidator accepts the token without verifying the signature or issuer, granting the attacker full access to produce and consume messages, create/delete topics, and modify ACLs as the impersonated user. The attack requires no specialized tools beyond standard JWT manipulation libraries available in Python, Java, or JavaScript, and leaves minimal forensic evidence since the attacker appears as a legitimate authenticated user in Kafka audit logs.