CVE-2024-56128 Overview
CVE-2024-56128 is an authentication weakness in Apache Kafka's Salted Challenge Response Authentication Mechanism (SCRAM) implementation. The Kafka broker fails to verify that the nonce sent by the client in the second SCRAM message matches the nonce the server issued in its first message. This deviates from the requirements of IETF RFC 5802 and weakens replay protection on the authentication exchange. The flaw is only exploitable when SCRAM is used over plaintext channels (SASL_PLAINTEXT) where an attacker can intercept traffic. Deployments that use SCRAM over TLS are not affected.
Critical Impact
Attackers with plaintext access to a Kafka SCRAM exchange can replay captured authentication messages to impersonate a client, because the broker does not validate the server nonce echoed back in the client's final message.
Affected Products
- Apache Kafka 0.10.2.0 through 3.6.x
- Apache Kafka 3.7.0 and 3.7.1
- Apache Kafka 3.8.0
Discovery Timeline
- 2024-12-18 - CVE-2024-56128 published to the National Vulnerability Database
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2024-56128
Vulnerability Analysis
SCRAM is a challenge-response authentication family defined in RFC 5802. During the exchange, the client sends an initial message containing a client nonce, the server responds with a combined nonce that appends its own random value, and the client must include that combined nonce in its subsequent client-final-message. The server is required to reject the exchange if the returned nonce does not match what it issued.
Apache Kafka's broker-side SCRAM implementation skipped this nonce comparison. As a result, the freshness guarantee that RFC 5802 attaches to the server nonce was not enforced during authentication. The Kafka project categorizes the defect under [CWE-303: Incorrect Implementation of Authentication Algorithm].
Root Cause
The root cause is a missing verification step in the SCRAM state machine on the server. The broker parses the client-final-message but does not confirm that the nonce attribute equals the concatenation of the client nonce and the server-generated nonce delivered in the server-first-message. Without this check, the server accepts final messages containing arbitrary or replayed nonces as long as the proof calculation remains internally consistent with the captured exchange.
Attack Vector
Exploitation requires an attacker to observe or intercept a SCRAM exchange transmitted in cleartext, which is possible when Kafka listeners are configured with SASL_PLAINTEXT rather than SASL_SSL. An attacker positioned on the network path can capture the authentication messages and replay or manipulate them against the broker. Because the server does not validate the nonce round-trip, replayed final messages are not rejected on that basis. Deployments running SCRAM over TLS are not exposed, because the encrypted channel prevents interception of the exchange.
No verified public proof-of-concept code is available for CVE-2024-56128. See the Apache Kafka mailing list advisory and the OpenWall oss-security discussion for the vendor's technical description.
Detection Methods for CVE-2024-56128
Indicators of Compromise
- Kafka broker server.properties containing SASL_PLAINTEXT in the listeners or advertised.listeners values, which indicates an exposed SCRAM exchange.
- Successful SCRAM authentications originating from unexpected client IP addresses or user agents against brokers exposed on plaintext listeners.
- Repeated or duplicate SCRAM client-final-message payloads observed on the wire against the same broker within short time windows.
Detection Strategies
- Inventory all Kafka brokers and enumerate their listener protocols. Any listener using SASL_PLAINTEXT with SCRAM-SHA-256 or SCRAM-SHA-512 is in scope.
- Compare deployed Kafka versions against the fixed releases 3.7.2, 3.8.1, and 3.9.0. Versions in the range 0.10.2.0 through 3.9.0 excluding these fixes are vulnerable.
- Inspect network captures on Kafka broker segments for cleartext SASL exchanges and correlate with authentication audit logs.
Monitoring Recommendations
- Forward Kafka broker authentication logs to a centralized log platform and alert on SCRAM authentication anomalies such as reused client nonces or truncated exchanges.
- Enable TLS session monitoring on Kafka listeners and alert when a broker accepts a non-TLS SASL connection.
- Track configuration drift on server.properties so that reintroduction of SASL_PLAINTEXT listeners triggers a change-management alert.
How to Mitigate CVE-2024-56128
Immediate Actions Required
- Upgrade Apache Kafka brokers to version 3.7.2, 3.8.1, or 3.9.0 or later, which introduce nonce verification in the SCRAM final message.
- If upgrading is not immediately possible, reconfigure all listeners that use SCRAM to require TLS by switching from SASL_PLAINTEXT to SASL_SSL.
- Rotate SCRAM credentials for any user whose authentication may have traversed a plaintext listener.
Patch Information
The Apache Kafka project fixed CVE-2024-56128 by adding nonce verification to the server-side SCRAM handler so that the broker rejects a client-final-message whose nonce does not match the concatenation of the client and server nonces from the earlier messages. Fixed versions are 3.7.2, 3.8.1, and 3.9.0. Details are published in the Apache Kafka security advisory thread and the Kafka SASL security documentation.
Workarounds
- Deploy SCRAM exclusively over TLS by configuring SASL_SSL listeners, which prevents attackers from observing the exchange required to exploit the flaw.
- Evaluate alternative SASL mechanisms such as PLAIN, GSSAPI (Kerberos), or OAUTHBEARER used together with TLS, per the Apache Kafka security guidance.
- Restrict network access to Kafka brokers using firewall rules or private networking so that only trusted client subnets can initiate authentication.
# Example server.properties snippet enforcing SASL over TLS
listeners=SASL_SSL://:9093
advertised.listeners=SASL_SSL://broker.example.com:9093
security.inter.broker.protocol=SASL_SSL
sasl.enabled.mechanisms=SCRAM-SHA-512
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-512
ssl.keystore.location=/etc/kafka/ssl/broker.keystore.jks
ssl.truststore.location=/etc/kafka/ssl/broker.truststore.jks
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

