External risk intelligence

Apache Kafka accepts fake security tokens allowing unauthorized access

CVE advisorySeverity: CRITICAL (CVSS 9.1)

CVE-2026-33557

Apache Kafka has a flaw that allows an external attacker to fake their identity and impersonate any user, including administrators. This could grant unauthorized access to sensitive business data and enable the manipulation of critical message streams.

2Halo Surface Signal

Apache Kafka

4.1.0 to before 4.1.2

External exposure likelihood

Halo Surface Signal score for CVE-2026-33557

Apache Kafka is backend infrastructure designed for internal communication within private network segments. It is generally protected by firewalls or VPC boundaries and is not intended for public internet access. While reachable by services within the internal network, direct exposure to the public internet is uncommon and typically results from specific misconfigurations.

Horizon Alert

Summary of the vulnerability and why it matters

A security vulnerability in Apache Kafka allows for the acceptance of any JWT token without proper signature, issuer, or audience validation. This means an attacker could create a fake token, potentially granting them unauthorized access to the system.

Allows unauthorized access.
Affects systems using specific Kafka versions.
Default configuration is vulnerable.

Attack Path

How an attacker could exploit the issue

An attacker can exploit this by crafting a JWT token that bypasses signature, issuer, and audience validation on vulnerable Apache Kafka brokers. This allows them to impersonate any user, granting unauthorized access to Kafka resources and data.

No authentication required.
Target broker's SASL authentication.
Default validator accepts forged tokens.

Live Threat

Current exploitation, exposure, and threat context

This vulnerability in Apache Kafka allows for unauthenticated access to sensitive information or actions by bypassing JWT signature, issuer, and audience validation. Attackers would favor this for its potential to grant broad access within a Kafka environment without needing legitimate credentials, especially if Kafka is exposed externally or in a less secured internal segment.

No public exploit observed.
No KEV listing.
Published vulnerability with limited affected versions.

Priority actions

Operational Fix

Recommended remediation, mitigation, and detection steps

Prioritize patching or configuring Apache Kafka instances running versions 4.1.0 through 4.1.1. This vulnerability allows unauthenticated attackers to forge JWT tokens and gain unauthorized access by bypassing signature, issuer, and audience validation. If immediate patching is not feasible, implement strict network segmentation to limit access to these Kafka brokers.

Explicitly set `sasl.oauthbearer.jwt.validator.class` to `org.apache.kafka.common.security.oauthbearer.BrokerJwtValidator`.
Upgrade Kafka to version 4.1.2 or later.
Monitor network traffic for unusual authentication attempts.

Frequently asked questions

What is Apache Kafka and how is it used?

Apache Kafka is a distributed event streaming platform used for building real-time data pipelines and streaming applications. It enables applications to publish and subscribe to streams of records, storing them durably and reliably, and processing them as they occur.

What kind of weakness does CVE-2026-33557 represent in Kafka?

CVE-2026-33557 is related to improper validation of security tokens. Specifically, it's a weakness where the default configuration of Apache Kafka allows any JSON Web Token (JWT) to be accepted without verifying its signature, issuer, or audience, effectively bypassing security controls.

How can an attacker exploit this Kafka vulnerability?

An attacker can exploit this by creating a custom JWT token with specific claims, such as a `preferred_username`, and sending it to a vulnerable Kafka broker. Because the broker's default validator doesn't check the token's authenticity, it will accept the forged token, granting the attacker access.

Who should be concerned about this Kafka vulnerability?

Organizations using Apache Kafka versions 4.1.0 or 4.1.1 should be concerned. While Kafka is typically internal infrastructure, if these specific versions are exposed or accessible from less secure network segments, the risk of exploitation increases.

What are the first steps to address this Kafka CVE?

The immediate steps are to either upgrade Apache Kafka to version 4.1.2 or later, or, if upgrading is not immediately possible, to explicitly configure the broker property `sasl.oauthbearer.jwt.validator.class` to `org.apache.kafka.common.security.oauthbearer.BrokerJwtValidator` to ensure proper JWT validation.

References

Written by Nicholas Merritt

External-surface CVE analysis and Halo Surface Signal prioritization for Halo Threat Intelligence.