CVE-2024-56128
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
Overview
Apache Kafka is a distributed streaming platform designed for building real-time data pipelines and event-driven applications at enterprise scale. It offers a high-throughput, fault-tolerant messaging system that enables applications to publish, store, and process continuous streams of records with low latency.
A security vulnerability (CVE-2024-56128) has been identified in Apache Kafka, affecting kafka-clients and posing elevated risk in deployments that use SCRAM authentication without TLS protection. Because Kafka’s SCRAM implementation failed to verify that the client-supplied nonce in the final handshake message matched the server-issued nonce as required by RFC 5802, an attacker with plaintext visibility into the authentication exchange could manipulate the SCRAM flow and compromise its integrity. Deployments using SCRAM over TLS are not impacted, but systems relying on SCRAM over insecure channels may be exposed and should upgrade to a version that includes proper nonce validation.
Per OWASP: Improper Validation of Certificate with Host Mismatch occurs when an application accepts a certificate without confirming that its subject matches the expected host, weakening the guarantees provided by TLS. When hostname verification is missing or incorrectly implemented, attackers can present a valid certificate for a different domain, enabling man-in-the-middle interception, traffic manipulation, or impersonation of trusted services. Without strict hostname checking, applications may unknowingly communicate with untrusted endpoints, exposing sensitive data and undermining the security of encrypted connections.
This issue affects multiple versions of Apache Kafka kafka-clients.
Details
Module Info
- Product: Apache Kafka
- Affected packages: kafka-clients
- Affected versions: >=0.10.2.0 <3.7.2 ; =3.8.0
- GitHub repository: https://github.com/apache/kafka/
- Published packages: https://central.sonatype.com/artifact/org.apache.kafka/kafka-clients
- Package manager: Maven
- Fixed In: NES for Spring Boot 2.7
Vulnerability Info
This medium-severity vulnerability is found in the kafka-client package in all published versions of Apache Kafka.
Kafka’s SCRAM mechanism is designed to mutually confirm both client and server values during the authentication handshake, including verification that the final client nonce matches the server-provided nonce. However, the implementation did not perform this required check, allowing an attacker with plaintext access to the SCRAM exchange to tamper with authentication message contents. When SCRAM is used over non-TLS channels, this gap weakens the integrity of the authentication flow and could permit manipulation of the handshake. Deployments using SCRAM exclusively over TLS are protected, while those using SASL_PLAINTEXT are at risk and should upgrade to a version that includes proper nonce validation.
Steps To Reproduce
Use a Kafka deployment configured with SASL_PLAINTEXT and SCRAM authentication, then initiate a SCRAM handshake in which the final client message does not maintain the correct server-issued nonce. In affected versions, the server accepts the message despite the mismatch.
Proof Of Concept
In vulnerable configurations, if an attacker can observe or interfere with the SCRAM messages sent over an unencrypted channel, the server will accept a final client message containing a modified nonce because the expected RFC-mandated verification was missing. This demonstrates how the authentication flow can be influenced when SCRAM is used without TLS.
Mitigation
Only recent versions of Apache Kafka are community-supported. Only the recent community supported version will receive updates to address this issue. For more information, see here.
Users of the affected components should apply one of the following mitigations:
- Upgrade affected applications to supported versions of Apache Kafka
- Leverage a commercial support partner like HeroDevs for post-EOL security support.
Credit
- Tim Fox (timvolpe@gmail.com)