External risk intelligence

Kafka Broker JWT Signature Verification Bypass Affects SASL/OAUTHBEARER

CVE advisorySeverity: CRITICAL (CVSS 9.1)

CVE-2026-110985

The vulnerable component is a Kafka broker, which is typically deployed within internal network segments for data streaming between services rather than being directly exposed to the public internet. While it is network-reachable within a cluster or enterprise environment, public internet exposure is uncommon and generally considered a non-standard deployment configuration.

Halo Surface Signal: 2 out of 5 — less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A vulnerability exists in how certain Kafka brokers validate security tokens. If misconfigured, these brokers may fail to verify token signatures, allowing unauthenticated attackers to impersonate legitimate users and gain unauthorized access to the data cluster. The main concern is confirming relevance and exposure within your Kafka deployments.

Brokers may accept fake security tokens.
Unauthenticated access to sensitive data is possible.
Assess Kafka configuration for potential unauthorized access.

Attack Path

How an attacker could exploit the issue

An attacker can reach a Kafka broker that is configured for SASL/OAUTHBEARER authentication without proper JWT signature verification. By sending a forged JWT, an unauthenticated attacker can impersonate any user, including superusers, to gain complete control over the Kafka cluster.

Requires network access to broker.
Triggers by sending a forged JWT.
Risk of unauthenticated cluster takeover.

Live Threat

Current exploitation, exposure, and threat context

A Kafka broker configured for SASL/OAUTHBEARER authentication could be tricked into accepting forged authentication tokens. This occurs when a specific validator setting is absent, causing the broker to bypass signature, algorithm, and issuer checks on JSON Web Tokens (JWTs). When supported by the advisory, an unauthenticated remote attacker could exploit this to impersonate any user, including administrators, and gain complete control of the Kafka cluster.

Kafka cluster access.
Forged JWTs accepted by broker.
Full cluster access granted.

Operational Fix

Recommended remediation, mitigation, and detection steps

The platform and infrastructure teams are most likely responsible for addressing this vulnerability in Kafka brokers that utilize SASL/OAUTHBEARER with the default validator. The immediate first step is to identify all Kafka brokers, confirm their reachability and criticality, and then determine the accountable owner for remediation.

Platform/Infra teams own the issue.
Verify SASL/OAUTHBEARER configuration.
Plan remediation based on exposure.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is an Apache Kafka broker?

Apache Kafka is a distributed data streaming platform used to build real-time data pipelines and streaming applications. A broker acts as the core server in a Kafka cluster, responsible for storing data streams (topics) and managing client connections. It is the component that receives data from producers and serves it to consumers, making it critical for maintaining data flow and access control.

What does CVE-2026-110985 mean for JWT validation?

This vulnerability involves a failure to verify the authenticity of JSON Web Tokens. Because the broker fails to validate the signature, algorithm, or issuer, it cannot distinguish between a legitimate token and a forged one. This falls under improper verification of cryptographic signatures and insufficient validation of data, meaning the system blindly trusts any token format provided to it.

How is this Kafka vulnerability triggered?

The issue triggers when a broker uses SASL/OAUTHBEARER authentication without defining a JWKS endpoint URL or a custom verification key resolver. If these settings are missing, the broker silently falls back to a non-verifying mode. Simply sending a structurally valid, forged JWT to the broker's listener is enough to bypass security checks. Brokers that correctly configure a JWKS endpoint are not affected by this logic error.

Is my Kafka cluster at risk if it is internal?

According to Halo Surface Signal, this vulnerability is classified as external due to the network-based attack vector. However, because Kafka brokers are typically deployed in internal segments for service-to-service communication, direct public exposure is uncommon. You should evaluate reachability: if an attacker can reach the listener over your internal network, they could potentially exploit this to gain unauthorized cluster access.

What are the first steps to secure my Kafka deployment?

You do not necessarily need a software upgrade to mitigate this. Start by auditing your broker configurations to see if sasl.oauthbearer.jwks.endpoint.url is unset while using the default validator. If so, configure that URL or a custom signature-verifying validator immediately. This ensures the broker enforces cryptographic checks, preventing the acceptance of forged tokens.

References

kafka.apache.org/cve-list

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.