CVE-2026-33557: Apache Kafka Auth Bypass Vulnerability

CVE-2026-33557 Overview

A critical authentication bypass vulnerability has been identified in Apache Kafka affecting versions 4.1.0 and 4.1.1. The vulnerability exists in the default OAuth Bearer JWT token validation mechanism, where the broker accepts any JWT token without validating its signature, issuer, or audience. This allows attackers to forge JWT tokens with arbitrary user identities and gain unauthorized access to Kafka clusters.

Critical Impact

Attackers can generate malicious JWT tokens with any preferred_username value and gain unauthorized access to Apache Kafka brokers, potentially compromising message integrity and confidentiality across the entire cluster.

Affected Products

• Apache Kafka 4.1.0
• Apache Kafka 4.1.1

Discovery Timeline

• April 20, 2026 - CVE-2026-33557 published to NVD
• April 22, 2026 - Last updated in NVD database

Technical Details for CVE-2026-33557

Vulnerability Analysis

This vulnerability represents an authentication bypass flaw in Apache Kafka's SASL OAuth Bearer authentication mechanism. The root issue lies in the default JWT validator class configuration, which fundamentally undermines the security guarantees expected from token-based authentication.

When Kafka brokers are configured to use OAuth Bearer authentication, they rely on JWT tokens to identify and authorize clients. However, the default validator class org.apache.kafka.common.security.oauthbearer.DefaultJwtValidator performs no cryptographic verification of incoming tokens. This means an attacker can craft a JWT token with any claims—including arbitrary usernames and permissions—and the broker will accept it as legitimate.

The vulnerability is particularly dangerous in production environments where OAuth Bearer authentication is expected to provide secure access control. Without proper signature validation, the entire trust model of JWT-based authentication collapses, allowing complete impersonation of any user.

Root Cause

The root cause is an insecure default configuration where the broker property sasl.oauthbearer.jwt.validator.class is set to org.apache.kafka.common.security.oauthbearer.DefaultJwtValidator. This default validator implementation accepts any JWT token without performing essential security checks:

• No signature validation - Tokens are not verified against any cryptographic key
• No issuer validation - Any issuer claim is accepted
• No audience validation - The intended recipient is not verified

This design flaw means that security-critical validation is effectively disabled out of the box, leaving systems vulnerable unless administrators explicitly configure a secure validator.

Attack Vector

The attack vector for this vulnerability is network-based and requires no authentication or user interaction. An attacker with network access to a vulnerable Kafka broker can exploit this flaw through the following approach:

1. Token Generation - The attacker crafts a JWT token using any JWT library, setting the preferred_username claim to the identity of a legitimate user or administrative account
2. Direct Connection - The attacker establishes a connection to the Kafka broker using the SASL OAuth Bearer mechanism
3. Authentication Bypass - The broker's default validator accepts the forged token without verification
4. Unauthorized Access - The attacker gains access with the privileges associated with the impersonated user

This attack requires no special tools or exploit code—standard JWT libraries and Kafka client libraries are sufficient to exploit the vulnerability. The attacker does not need any prior credentials or access to legitimate tokens.

Detection Methods for CVE-2026-33557

Indicators of Compromise

• Unusual authentication patterns from unexpected IP addresses or clients connecting with high-privilege usernames
• JWT tokens with malformed or suspicious issuer (iss) claims that don't match your identity provider
• Authentication logs showing successful logins for users who did not initiate connections
• Kafka consumer groups or topics accessed by unexpected principals

Detection Strategies

• Review Kafka broker configurations to identify instances using the vulnerable DefaultJwtValidator class
• Implement monitoring for authentication events and correlate with your identity provider's token issuance logs
• Audit Kafka ACLs for any unauthorized access patterns or permission changes
• Enable detailed authentication logging on brokers to capture JWT token metadata

Monitoring Recommendations

• Configure centralized logging for all Kafka broker authentication events
• Set up alerts for authentication attempts using JWT tokens with issuers not on your approved list
• Monitor for anomalous client behavior patterns such as new consumers on sensitive topics
• Implement network-level monitoring for connections to Kafka broker ports from untrusted sources

How to Mitigate CVE-2026-33557

Immediate Actions Required

• Audit all Kafka broker configurations to identify instances running versions 4.1.0 or 4.1.1
• Immediately reconfigure the sasl.oauthbearer.jwt.validator.class property to use org.apache.kafka.common.security.oauthbearer.BrokerJwtValidator
• Review authentication logs for signs of unauthorized access prior to remediation
• Consider temporarily restricting network access to Kafka brokers while applying configuration changes

Patch Information

Apache has addressed this vulnerability in Kafka versions 4.1.2 and 4.2.0. Upgrading to these versions or later will ensure proper JWT token validation is enabled by default. For organizations unable to upgrade immediately, explicitly setting the secure validator class provides an effective workaround.

For detailed information, refer to the Apache Kafka CVE List and the Apache Mailing List Thread.

Workarounds

• Explicitly configure the broker to use the secure JWT validator class as shown in the configuration example below
• Implement network segmentation to restrict Kafka broker access to trusted clients only
• Enable Kafka ACLs with deny-by-default policies to limit the impact of potential authentication bypass
• Consider implementing additional authentication layers such as mutual TLS alongside OAuth Bearer

# Kafka broker configuration to mitigate CVE-2026-33557
# Add or modify the following property in server.properties

# Set the secure JWT validator class explicitly
sasl.oauthbearer.jwt.validator.class=org.apache.kafka.common.security.oauthbearer.BrokerJwtValidator

# Restart Kafka brokers after applying the configuration change
# kafka-server-stop.sh && kafka-server-start.sh config/server.properties