CVE-2026-33558

What it actually does

Apache Kafka's NetworkClient can write full request and response objects to logs when DEBUG logging is enabled. The exposed payloads can include sensitive authentication, authorization, configuration, and delegation-token material from APIs such as SaslAuthenticateRequest, AlterUserScramCredentialsRequest, RenewDelegationTokenRequest, ExpireDelegationTokenRequest, and delegation-token responses. Default INFO logging is not affected, but any broker, client, connector, stream-processing application, or operational environment that enables DEBUG logging for the affected component may persist secrets in local files, centralized logging platforms, backups, or observability tools. The issue affects supported Apache Kafka versions through 3.9.1 and 4.0.0 and is fixed in 3.9.2, 4.0.1, and later.

Why it matters to the business

If DEBUG logging is enabled, credentials, delegation tokens, or sensitive Kafka configuration values may be exposed to anyone with access to Kafka logs or log aggregation systems. This can lead to unauthorized access to Kafka clusters, data streams, administrative functions, or downstream systems that trust Kafka credentials. The EPSS score is low and stable, the issue is not listed in CISA KEV, and no public exploit maturity is indicated, but the operational risk is meaningful because log exposure often persists long after the original request and may be broadly replicated through SIEM, observability, support bundles, and backups.

How an attack unfolds

An attacker does not need to exploit memory corruption or execute code against Kafka. The practical attack path is to find an Apache Kafka deployment or application using an affected version where DEBUG logging is enabled for NetworkClient or a broad Kafka/root logger. The attacker then either waits for sensitive Kafka operations to occur or causes authentication, delegation-token, SCRAM-credential, or configuration-change requests to be sent. The vulnerable component logs entire request and response payloads. If the attacker has access to local log files, container logs, support archives, centralized logging, or monitoring exports, they can extract exposed credentials, tokens, or configuration data and reuse them to authenticate to Kafka or expand access. No known KEV or ransomware exploitation is reported, but defenders should assume any sensitive values present in DEBUG logs are compromised.

How to fix it

Upgrade Apache Kafka to version 3.9.2, 4.0.1, or later. Apply the fix to Kafka brokers and to any applications, connectors, stream-processing services, administration tools, or packaged products that bundle affected Kafka client libraries. Immediately disable DEBUG logging for Kafka NetworkClient and avoid broad DEBUG logging for org.apache.kafka or root loggers in production. Review and harden logging pipelines so sensitive fields are redacted before storage or forwarding. Treat any credentials, SCRAM secrets, SASL material, delegation tokens, or sensitive configuration values found in DEBUG logs as compromised: revoke or expire delegation tokens, rotate affected user credentials and service-account secrets, and invalidate any exposed authentication material. Restrict access to historical logs, support bundles, backups, and observability exports that may contain affected entries.

How to confirm the fix worked

Confirm all Kafka runtime components and bundled Kafka client libraries are upgraded to Apache Kafka 3.9.2, 4.0.1, or later. Review broker, client, connector, and application logging configuration for DEBUG settings on org.apache.kafka, org.apache.kafka.clients.NetworkClient, or root loggers. Search historical and current logs for the affected request and response type names to determine whether sensitive payloads were logged. After upgrading, perform a controlled non-production test using SASL authentication, delegation-token operations, and configuration changes while DEBUG logging is temporarily enabled, then verify that full sensitive request and response payloads are no longer written. Confirm that credential rotation or token revocation has been completed for any exposed values found in logs.

Typical attack path

1. Identify Kafka brokers, clients, connectors, or applications running affected Apache Kafka versions through 3.9.1 or 4.0.0.
2. Determine whether DEBUG logging is enabled globally or for Kafka client/network components.
3. Trigger or wait for sensitive Kafka operations such as SASL authentication, SCRAM credential changes, delegation-token creation, renewal, expiration, or configuration alteration.
4. Access local logs, container stdout/stderr, log aggregation platforms, SIEM data, observability archives, or support bundles.
5. Search logs for full Kafka request and response objects containing credentials, tokens, or sensitive configuration values.
6. Reuse exposed secrets to authenticate to Kafka, access topics, alter configuration, or move laterally into systems that rely on the leaked credentials.

How to detect it

Investigate whether this issue was already exploited or exposed by reviewing all places Kafka logs may have been stored: broker log directories, client and application logs, Kafka Connect and Streams logs, container stdout/stderr, Kubernetes logging backends, centralized SIEM/logging platforms, observability tools, support bundles, and log backups. Focus on time periods where DEBUG logging was enabled for org.apache.kafka, org.apache.kafka.clients.NetworkClient, or a root logger. Search for the affected request and response names and inspect surrounding log lines for SASL payloads, SCRAM credential material, delegation tokens, token renewals/expirations, and configuration changes. Correlate any discovered secrets with Kafka authentication logs, ACL changes, topic access, configuration changes, and administrative API usage after the log entry time. Treat direct appearances of sensitive Kafka request/response objects in DEBUG logs as evidence of exposure even if there is no clear malicious access, because any account or tool with log access may have retrieved them.

• DEBUG org.apache.kafka.clients.NetworkClient
• org.apache.kafka.clients.NetworkClient
• AlterConfigsRequest
• AlterUserScramCredentialsRequest
• ExpireDelegationTokenRequest
• IncrementalAlterConfigsRequest
• RenewDelegationTokenRequest
• SaslAuthenticateRequest
• CreateDelegationTokenResponse
• createDelegationTokenResponse
• DescribeDelegationTokenResponse
• describeDelegationTokenResponse
• SaslAuthenticateResponse
• AlterConfigsRequest(
• AlterUserScramCredentialsRequest(
• ExpireDelegationTokenRequest(
• IncrementalAlterConfigsRequest(
• RenewDelegationTokenRequest(
• SaslAuthenticateRequest(
• CreateDelegationTokenResponse(
• DescribeDelegationTokenResponse(
• SaslAuthenticateResponse(

What your security team should do

• Prioritize upgrade to Apache Kafka 3.9.2, 4.0.1, or later across brokers, clients, connectors, and dependent applications.
• Immediately disable DEBUG logging for Kafka components in production unless there is a time-bounded, approved troubleshooting need.
• Search centralized logs, local Kafka logs, container logs, observability stores, and support bundles for affected request and response names.
• If sensitive payloads are found, rotate SCRAM/SASL credentials, revoke or expire delegation tokens, and review Kafka ACLs for misuse.
• Restrict access to historical logs and log archives that may contain leaked secrets, and apply retention reduction where operationally acceptable.
• Add SIEM detections for DEBUG NetworkClient logging and for the affected Kafka request/response class names appearing in logs.
• Update logging standards to prohibit full request/response logging of authentication, credential-management, token, and configuration APIs.
• Monitor Kafka authentication events and administrative operations for suspicious use of credentials or tokens that may have appeared in logs.