Description
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.
Published: 2026-10-28
Score: n/a
EPSS: n/a
KEV: No
Impact: Authentication Bypass via Unverified JWT Claims
Action: Apply Config Fix
AI Analysis

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.

Generated by OpenCVE AI on October 28, 2026 at 17:22 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Configure each broker listener with sasl.oauthbearer.expected.issuer to match the exact issuer value provided by your identity provider
  • Configure each broker listener with sasl.oauthbearer.expected.audience to match the audience(s) your brokers expect
  • If operating a shared JWKS endpoint and you must support multiple issuers or audiences, set sasl.oauthbearer.allow.unverified.issuer=true and/or sasl.oauthbearer.allow.unverified.audience=true, but consider moving to a dedicated JWKS per broker or upgrading to Kafka 4.4.0 where these checks are enforced by default

Generated by OpenCVE AI on October 28, 2026 at 17:22 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

References
History

Wed, 28 Oct 2026 16:45:00 +0000

Type Values Removed Values Added
Description 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.
Title Apache Kafka: Broker does not enforce JWT issuer and audience validation for SASL/OAUTHBEARER by default
Weaknesses CWE-1188
CWE-345
References

Subscriptions

No data.

cve-icon MITRE

Status: PUBLISHED

Assigner: apache

Published:

Updated: 2026-10-28T16:37:34.723Z

Reserved: 2026-10-15T09:13:40.750Z

Link: CVE-2026-110952

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-28T17:17:37.997

Modified: 2026-10-28T17:17:37.997

Link: CVE-2026-110952

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-10-28T17:30:15Z

Weaknesses
  • CWE-1188

    Initialization of a Resource with an Insecure Default

  • CWE-345

    Insufficient Verification of Data Authenticity