Impact
Kafka brokers validate JWT signatures but, by default, do not check the issuer (iss) or audience (aud) claims unless explicitly configured. A token that is correctly signed but originates from a different issuer, or that omits the aud claim, will be accepted as authenticated. This allows a malicious actor to authenticate as an unauthorized principal, potentially with higher privileges, and gain access to protected Kafka resources. The flaw is a classic authentication bypass issue that could lead to data exfiltration, unauthorized data manipulation, or denial of service if sensitive partitions are compromised.
Affected Systems
The vulnerability affects all Apache Kafka releases up to and including 4.3.x that use SASL/OAUTHBEARER authentication. Releases prior to 4.4.0 default to no enforcement of issuer or audience validation even though the verification of the JWT signature remains intact. The flaw is relevant for deployments where a single JWKS endpoint serves keys for multiple issuers, such as multi‑tenant identity providers or shared signing keys.
Risk and Exploitability
While no CVSS score is provided, the ability to authenticate with any validly signed token from an untrusted issuer presents a high risk to confidentiality and integrity of the Kafka cluster. The EPSS score is not available, and the vulnerability is not listed in CISA’s KEV catalog, indicating no publicly known exploit at the time of this report. However, with an attacker able to obtain or forge a signed JWT, the attack vector is straightforward: simply present the token in a SASL/OAUTHBEARER connection. The attack requires no special privileges beyond possession of a validly signed JWT, making the exploit easily achievable in environments that rely on multi‑issuer JWKS endpoints.
OpenCVE Enrichment