CVE-2024-56128
Apache Kafka: SCRAM authentication vulnerable to replay attacks when used without encryption
Incorrect Implementation of Authentication Algorithm in Apache Kafka's SCRAM implementation.
Issue Summary: Apache Kafka's implementation of the Salted Challenge Response Authentication Mechanism (SCRAM) did not fully adhere to the requirements of RFC 5802 [1]. Specifically, as per RFC 5802, the server must verify that the nonce sent by the client in the second message matches the nonce sent by the server in its first message. However, Kafka's SCRAM implementation did not perform this validation.
Impact: This vulnerability is exploitable only when an attacker has plaintext access to the SCRAM authentication exchange. However, the usage of SCRAM over plaintext is strongly discouraged as it is considered an insecure practice [2]. Apache Kafka recommends deploying SCRAM exclusively with TLS encryption to protect SCRAM exchanges from interception [3]. Deployments using SCRAM with TLS are not affected by this issue.
How to Detect If You Are Impacted: If your deployment uses SCRAM authentication over plaintext communication channels (without TLS encryption), you are likely impacted. To check if TLS is enabled, review your server.properties configuration file for listeners property. If you have SASL_PLAINTEXT in the listeners, then you are likely impacted.
Fix Details: The issue has been addressed by introducing nonce verification in the final message of the SCRAM authentication exchange to ensure compliance with RFC 5802.
Affected Versions: Apache Kafka versions 0.10.2.0 through 3.9.0, excluding the fixed versions below.
Fixed Versions: 3.9.0 3.8.1 3.7.2
Users are advised to upgrade to 3.7.2 or later to mitigate this issue.
Recommendations for Mitigation: Users unable to upgrade to the fixed versions can mitigate the issue by:
- Using TLS with SCRAM Authentication: Always deploy SCRAM over TLS to encrypt authentication exchanges and protect against interception.
- Considering Alternative Authentication Mechanisms: Evaluate alternative authentication mechanisms, such as PLAIN, Kerberos or OAuth with TLS, which provide additional layers of security.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- None
What an attacker can affect
- Confidentiality
- Low
- Integrity
- None
- Availability
- None
Exploit likelihood
What each source reports
CVE List Score used
Apache Kafka: SCRAM authentication vulnerable to replay attacks when used without encryption
Incorrect Implementation of Authentication Algorithm in Apache Kafka's SCRAM implementation.
Issue Summary: Apache Kafka's implementation of the Salted Challenge Response Authentication Mechanism (SCRAM) did not fully adhere to the requirements of RFC 5802 [1]. Specifically, as per RFC 5802, the server must verify that the nonce sent by the client in the second message matches the nonce sent by the server in its first message. However, Kafka's SCRAM implementation did not perform this validation.
Impact: This vulnerability is exploitable only when an attacker has plaintext access to the SCRAM authentication exchange. However, the usage of SCRAM over plaintext is strongly discouraged as it is considered an insecure practice [2]. Apache Kafka recommends deploying SCRAM exclusively with TLS encryption to protect SCRAM exchanges from interception [3]. Deployments using SCRAM with TLS are not affected by this issue.
How to Detect If You Are Impacted: If your deployment uses SCRAM authentication over plaintext communication channels (without TLS encryption), you are likely impacted. To check if TLS is enabled, review your server.properties configuration file for listeners property. If you have SASL_PLAINTEXT in the listeners, then you are likely impacted.
Fix Details: The issue has been addressed by introducing nonce verification in the final message of the SCRAM authentication exchange to ensure compliance with RFC 5802.
Affected Versions: Apache Kafka versions 0.10.2.0 through 3.9.0, excluding the fixed versions below.
Fixed Versions: 3.9.0 3.8.1 3.7.2
Users are advised to upgrade to 3.7.2 or later to mitigate this issue.
Recommendations for Mitigation: Users unable to upgrade to the fixed versions can mitigate the issue by:
- Using TLS with SCRAM Authentication: Always deploy SCRAM over TLS to encrypt authentication exchanges and protect against interception.
- Considering Alternative Authentication Mechanisms: Evaluate alternative authentication mechanisms, such as PLAIN, Kerberos or OAuth with TLS, which provide additional layers of security.
- Record
CVE-2024-56128- CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N - Weakness
- CWE-303
- Updated
- 2026-11-02
EUVDEUVD-2024-3603
Incorrect Implementation of Authentication Algorithm in Apache Kafka's SCRAM implementation.
Issue Summary: Apache Kafka's implementation of the Salted Challenge Response Authentication Mechanism (SCRAM) did not fully adhere to the requirements of RFC 5802 [1]. Specifically, as per RFC 5802, the server must verify that the nonce sent by the client in the second message matches the nonce sent by the server in its first message. However, Kafka's SCRAM implementation did not perform this validation.
Impact: This vulnerability is exploitable only when an attacker has plaintext access to the SCRAM authentication exchange. However, the usage of SCRAM over plaintext is strongly discouraged as it is considered an insecure practice [2]. Apache Kafka recommends deploying SCRAM exclusively with TLS encryption to protect SCRAM exchanges from interception [3]. Deployments using SCRAM with TLS are not affected by this issue.
How to Detect If You Are Impacted: If your deployment uses SCRAM authentication over plaintext communication channels (without TLS encryption), you are likely impacted. To check if TLS is enabled, review your server.properties configuration file for listeners property. If you have SASL_PLAINTEXT in the listeners, then you are likely impacted.
Fix Details: The issue has been addressed by introducing nonce verification in the final message of the SCRAM authentication exchange to ensure compliance with RFC 5802.
Affected Versions: Apache Kafka versions 0.10.2.0 through 3.9.0, excluding the fixed versions below.
Fixed Versions: 3.9.0 3.8.1 3.7.2
Users are advised to upgrade to 3.7.2 or later to mitigate this issue.
Recommendations for Mitigation: Users unable to upgrade to the fixed versions can mitigate the issue by:
- Using TLS with SCRAM Authentication: Always deploy SCRAM over TLS to encrypt authentication exchanges and protect against interception.
- Considering Alternative Authentication Mechanisms: Evaluate alternative authentication mechanisms, such as PLAIN, Kerberos or OAuth with TLS, which provide additional layers of security.
- Record
EUVD-2024-3603- CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N - Updated
- 2026-11-03
GitHub AdvisoriesGHSA-p7c9-8xx8-h74f
Apache Kafka's SCRAM implementation Incorrectly Implements Authentication Algorithm
Incorrect Implementation of Authentication Algorithm in Apache Kafka's SCRAM implementation.
Issue Summary: Apache Kafka's implementation of the Salted Challenge Response Authentication Mechanism (SCRAM) did not fully adhere to the requirements of RFC 5802 [1]. Specifically, as per RFC 5802, the server must verify that the nonce sent by the client in the second message matches the nonce sent by the server in its first message. However, Kafka's SCRAM implementation did not perform this validation.
Impact: This vulnerability is exploitable only when an attacker has plaintext access to the SCRAM authentication exchange. However, the usage of SCRAM over plaintext is strongly discouraged as it is considered an insecure practice [2]. Apache Kafka recommends deploying SCRAM exclusively with TLS encryption to protect SCRAM exchanges from interception [3]. Deployments using SCRAM with TLS are not affected by this issue.
How to Detect If You Are Impacted: If your deployment uses SCRAM authentication over plaintext communication channels (without TLS encryption), you are likely impacted. To check if TLS is enabled, review your server.properties configuration file for listeners property. If you have SASL_PLAINTEXT in the listeners, then you are likely impacted.
Fix Details: The issue has been addressed by introducing nonce verification in the final message of the SCRAM authentication exchange to ensure compliance with RFC 5802.
Affected Versions: Apache Kafka versions 0.10.2.0 through 3.9.0, excluding the fixed versions below.
Fixed Versions: 3.9.0 3.8.1 3.7.2
Users are advised to upgrade to 3.7.2 or later to mitigate this issue.
Recommendations for Mitigation: Users unable to upgrade to the fixed versions can mitigate the issue by:
- Using TLS with SCRAM Authentication: Always deploy SCRAM over TLS to encrypt authentication exchanges and protect against interception.
- Considering Alternative Authentication Mechanisms: Evaluate alternative authentication mechanisms, such as PLAIN, Kerberos or OAuth with TLS, which provide additional layers of security.
- Record
GHSA-p7c9-8xx8-h74f- CVSS 4.0
- 1.7 Low
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U - CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N - Weakness
- CWE-303
- Updated
- 2026-11-02
NVD
Incorrect Implementation of Authentication Algorithm in Apache Kafka's SCRAM implementation.
Issue Summary: Apache Kafka's implementation of the Salted Challenge Response Authentication Mechanism (SCRAM) did not fully adhere to the requirements of RFC 5802 [1]. Specifically, as per RFC 5802, the server must verify that the nonce sent by the client in the second message matches the nonce sent by the server in its first message. However, Kafka's SCRAM implementation did not perform this validation.
Impact: This vulnerability is exploitable only when an attacker has plaintext access to the SCRAM authentication exchange. However, the usage of SCRAM over plaintext is strongly discouraged as it is considered an insecure practice [2]. Apache Kafka recommends deploying SCRAM exclusively with TLS encryption to protect SCRAM exchanges from interception [3]. Deployments using SCRAM with TLS are not affected by this issue.
How to Detect If You Are Impacted: If your deployment uses SCRAM authentication over plaintext communication channels (without TLS encryption), you are likely impacted. To check if TLS is enabled, review your server.properties configuration file for listeners property. If you have SASL_PLAINTEXT in the listeners, then you are likely impacted.
Fix Details: The issue has been addressed by introducing nonce verification in the final message of the SCRAM authentication exchange to ensure compliance with RFC 5802.
Affected Versions: Apache Kafka versions 0.10.2.0 through 3.9.0, excluding the fixed versions below.
Fixed Versions: 3.9.0 3.8.1 3.7.2
Users are advised to upgrade to 3.7.2 or later to mitigate this issue.
Recommendations for Mitigation: Users unable to upgrade to the fixed versions can mitigate the issue by:
- Using TLS with SCRAM Authentication: Always deploy SCRAM over TLS to encrypt authentication exchanges and protect against interception.
- Considering Alternative Authentication Mechanisms: Evaluate alternative authentication mechanisms, such as PLAIN, Kerberos or OAuth with TLS, which provide additional layers of security.
- Record
CVE-2024-56128- CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N - Weakness
- CWE-303
- Updated
- 2026-11-02
OSV
Apache Kafka: SCRAM authentication vulnerable to replay attacks when used without encryption
Incorrect Implementation of Authentication Algorithm in Apache Kafka's SCRAM implementation.
Issue Summary: Apache Kafka's implementation of the Salted Challenge Response Authentication Mechanism (SCRAM) did not fully adhere to the requirements of RFC 5802 [1]. Specifically, as per RFC 5802, the server must verify that the nonce sent by the client in the second message matches the nonce sent by the server in its first message. However, Kafka's SCRAM implementation did not perform this validation.
Impact: This vulnerability is exploitable only when an attacker has plaintext access to the SCRAM authentication exchange. However, the usage of SCRAM over plaintext is strongly discouraged as it is considered an insecure practice [2]. Apache Kafka recommends deploying SCRAM exclusively with TLS encryption to protect SCRAM exchanges from interception [3]. Deployments using SCRAM with TLS are not affected by this issue.
How to Detect If You Are Impacted: If your deployment uses SCRAM authentication over plaintext communication channels (without TLS encryption), you are likely impacted. To check if TLS is enabled, review your server.properties configuration file for listeners property. If you have SASL_PLAINTEXT in the listeners, then you are likely impacted.
Fix Details: The issue has been addressed by introducing nonce verification in the final message of the SCRAM authentication exchange to ensure compliance with RFC 5802.
Affected Versions: Apache Kafka versions 0.10.2.0 through 3.9.0, excluding the fixed versions below.
Fixed Versions: 3.9.0 3.8.1 3.7.2
Users are advised to upgrade to 3.7.2 or later to mitigate this issue.
Recommendations for Mitigation: Users unable to upgrade to the fixed versions can mitigate the issue by:
- Using TLS with SCRAM Authentication: Always deploy SCRAM over TLS to encrypt authentication exchanges and protect against interception.
- Considering Alternative Authentication Mechanisms: Evaluate alternative authentication mechanisms, such as PLAIN, Kerberos or OAuth with TLS, which provide additional layers of security.
- Record
CVE-2024-56128- CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N - Weakness
- CWE-303
- Updated
- 2026-11-02
OSVGHSA-p7c9-8xx8-h74f
Apache Kafka's SCRAM implementation Incorrectly Implements Authentication Algorithm
Incorrect Implementation of Authentication Algorithm in Apache Kafka's SCRAM implementation.
Issue Summary: Apache Kafka's implementation of the Salted Challenge Response Authentication Mechanism (SCRAM) did not fully adhere to the requirements of RFC 5802 [1]. Specifically, as per RFC 5802, the server must verify that the nonce sent by the client in the second message matches the nonce sent by the server in its first message. However, Kafka's SCRAM implementation did not perform this validation.
Impact: This vulnerability is exploitable only when an attacker has plaintext access to the SCRAM authentication exchange. However, the usage of SCRAM over plaintext is strongly discouraged as it is considered an insecure practice [2]. Apache Kafka recommends deploying SCRAM exclusively with TLS encryption to protect SCRAM exchanges from interception [3]. Deployments using SCRAM with TLS are not affected by this issue.
How to Detect If You Are Impacted: If your deployment uses SCRAM authentication over plaintext communication channels (without TLS encryption), you are likely impacted. To check if TLS is enabled, review your server.properties configuration file for listeners property. If you have SASL_PLAINTEXT in the listeners, then you are likely impacted.
Fix Details: The issue has been addressed by introducing nonce verification in the final message of the SCRAM authentication exchange to ensure compliance with RFC 5802.
Affected Versions: Apache Kafka versions 0.10.2.0 through 3.9.0, excluding the fixed versions below.
Fixed Versions: 3.9.0 3.8.1 3.7.2
Users are advised to upgrade to 3.7.2 or later to mitigate this issue.
Recommendations for Mitigation: Users unable to upgrade to the fixed versions can mitigate the issue by:
- Using TLS with SCRAM Authentication: Always deploy SCRAM over TLS to encrypt authentication exchanges and protect against interception.
- Considering Alternative Authentication Mechanisms: Evaluate alternative authentication mechanisms, such as PLAIN, Kerberos or OAuth with TLS, which provide additional layers of security.
- Record
GHSA-p7c9-8xx8-h74f- CVSS 4.0
- 1.7 Low
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U - CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N - Weakness
- CWE-303
- Updated
- 2026-11-02
Show 8 moreShow less
OSVOESA-2026-4420
kafka security update
Apache Kafka is an open-source distributed event streaming platform used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications.
Security Fix(es):
JMSSink in all versions of Log4j 1.x is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration or if the configuration references an LDAP service the attacker has access to. The attacker can provide a TopicConnectionFactoryBindingName configuration causing JMSSink to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-4104. Note this issue only affects Log4j 1.x when specifically configured to use JMSSink, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.(CVE-2022-23302)
By design, the JDBCAppender in Log4j 1.2.x accepts an SQL statement as a configuration parameter where the values to be inserted are converters from PatternLayout. The message converter, %m, is likely to always be included. This allows attackers to manipulate the SQL by entering crafted strings into input fields or headers of an application that are logged allowing unintended SQL queries to be executed. Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default. Beginning in version 2.0-beta8, the JDBCAppender was re-introduced with proper support for parameterized SQL queries and further customization over the columns written to in logs. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.(CVE-2022-23305)
CVE-2020-9493 identified a deserialization issue that was present in Apache Chainsaw. Prior to Chainsaw V2.0 Chainsaw was a component of Apache Log4j 1.2.x where the same issue exists.(CVE-2022-23307)
A possible security vulnerability has been identified in Apache Kafka Connect API.
This requires access to a Kafka Connect worker, and the ability to create/modify connectors on it with an arbitrary Kafka client SASL JAAS config
and a SASL-based security protocol, which has been possible on Kafka Connect clusters since Apache Kafka Connect 2.3.0.
When configuring the connector via the Kafka Connect REST API, an authenticated operator can set the sasl.jaas.config
property for any of the connector's Kafka clients to "com.sun.security.auth.module.JndiLoginModule", which can be done via the
producer.override.sasl.jaas.config, consumer.override.sasl.jaas.config, or admin.override.sasl.jaas.config properties.
This will allow the server to connect to the attacker's LDAP server
and deserialize the LDAP response, which the attacker can use to execute java deserialization gadget chains on the Kafka connect server.
Attacker can cause unrestricted deserialization of untrusted data (or) RCE vulnerability when there are gadgets in the classpath.
Since Apache Kafka 3.0.0, users are allowed to specify these properties in connector configurations for Kafka Connect clusters running with out-of-the-box configurations. Before Apache Kafka 3.0.0, users may not specify these properties unless the Kafka Connect cluster has been reconfigured with a connector client override policy that permits them.
Since Apache Kafka 3.4.0, we have added a system property ("-Dorg.apache.kafka.disallowed.login.modules") to disable the problematic login modules usage in SASL JAAS configuration. Also by default "com.sun.security.auth.module.JndiLoginModule" is disabled in Apache Kafka Connect 3.4.0.
We advise the Kafka Connect users to validate connector configurations and only allow trusted JNDI configurations. Also examine connector dependencies for vulnerable versions and either upgrade their connectors, upgrading that specific dependency,…
- Record
OESA-2026-4420- CVSS 3.1
- 9.8 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - Updated
- 2026-11-02
OSVOESA-2026-4421
kafka security update
Apache Kafka is an open-source distributed event streaming platform used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications.
Security Fix(es):
JMSSink in all versions of Log4j 1.x is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration or if the configuration references an LDAP service the attacker has access to. The attacker can provide a TopicConnectionFactoryBindingName configuration causing JMSSink to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-4104. Note this issue only affects Log4j 1.x when specifically configured to use JMSSink, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.(CVE-2022-23302)
By design, the JDBCAppender in Log4j 1.2.x accepts an SQL statement as a configuration parameter where the values to be inserted are converters from PatternLayout. The message converter, %m, is likely to always be included. This allows attackers to manipulate the SQL by entering crafted strings into input fields or headers of an application that are logged allowing unintended SQL queries to be executed. Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default. Beginning in version 2.0-beta8, the JDBCAppender was re-introduced with proper support for parameterized SQL queries and further customization over the columns written to in logs. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.(CVE-2022-23305)
CVE-2020-9493 identified a deserialization issue that was present in Apache Chainsaw. Prior to Chainsaw V2.0 Chainsaw was a component of Apache Log4j 1.2.x where the same issue exists.(CVE-2022-23307)
A possible security vulnerability has been identified in Apache Kafka Connect API.
This requires access to a Kafka Connect worker, and the ability to create/modify connectors on it with an arbitrary Kafka client SASL JAAS config
and a SASL-based security protocol, which has been possible on Kafka Connect clusters since Apache Kafka Connect 2.3.0.
When configuring the connector via the Kafka Connect REST API, an authenticated operator can set the sasl.jaas.config
property for any of the connector's Kafka clients to "com.sun.security.auth.module.JndiLoginModule", which can be done via the
producer.override.sasl.jaas.config, consumer.override.sasl.jaas.config, or admin.override.sasl.jaas.config properties.
This will allow the server to connect to the attacker's LDAP server
and deserialize the LDAP response, which the attacker can use to execute java deserialization gadget chains on the Kafka connect server.
Attacker can cause unrestricted deserialization of untrusted data (or) RCE vulnerability when there are gadgets in the classpath.
Since Apache Kafka 3.0.0, users are allowed to specify these properties in connector configurations for Kafka Connect clusters running with out-of-the-box configurations. Before Apache Kafka 3.0.0, users may not specify these properties unless the Kafka Connect cluster has been reconfigured with a connector client override policy that permits them.
Since Apache Kafka 3.4.0, we have added a system property ("-Dorg.apache.kafka.disallowed.login.modules") to disable the problematic login modules usage in SASL JAAS configuration. Also by default "com.sun.security.auth.module.JndiLoginModule" is disabled in Apache Kafka Connect 3.4.0.
We advise the Kafka Connect users to validate connector configurations and only allow trusted JNDI configurations. Also examine connector dependencies for vulnerable versions and either upgrade their connectors, upgrading that specific dependency,…
- Record
OESA-2026-4421- CVSS 3.1
- 9.8 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - Updated
- 2026-11-02
OSVOESA-2026-4422
kafka security update
Apache Kafka is an open-source distributed event streaming platform used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications.
Security Fix(es):
JMSSink in all versions of Log4j 1.x is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration or if the configuration references an LDAP service the attacker has access to. The attacker can provide a TopicConnectionFactoryBindingName configuration causing JMSSink to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-4104. Note this issue only affects Log4j 1.x when specifically configured to use JMSSink, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.(CVE-2022-23302)
By design, the JDBCAppender in Log4j 1.2.x accepts an SQL statement as a configuration parameter where the values to be inserted are converters from PatternLayout. The message converter, %m, is likely to always be included. This allows attackers to manipulate the SQL by entering crafted strings into input fields or headers of an application that are logged allowing unintended SQL queries to be executed. Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default. Beginning in version 2.0-beta8, the JDBCAppender was re-introduced with proper support for parameterized SQL queries and further customization over the columns written to in logs. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.(CVE-2022-23305)
CVE-2020-9493 identified a deserialization issue that was present in Apache Chainsaw. Prior to Chainsaw V2.0 Chainsaw was a component of Apache Log4j 1.2.x where the same issue exists.(CVE-2022-23307)
A possible security vulnerability has been identified in Apache Kafka Connect API.
This requires access to a Kafka Connect worker, and the ability to create/modify connectors on it with an arbitrary Kafka client SASL JAAS config
and a SASL-based security protocol, which has been possible on Kafka Connect clusters since Apache Kafka Connect 2.3.0.
When configuring the connector via the Kafka Connect REST API, an authenticated operator can set the sasl.jaas.config
property for any of the connector's Kafka clients to "com.sun.security.auth.module.JndiLoginModule", which can be done via the
producer.override.sasl.jaas.config, consumer.override.sasl.jaas.config, or admin.override.sasl.jaas.config properties.
This will allow the server to connect to the attacker's LDAP server
and deserialize the LDAP response, which the attacker can use to execute java deserialization gadget chains on the Kafka connect server.
Attacker can cause unrestricted deserialization of untrusted data (or) RCE vulnerability when there are gadgets in the classpath.
Since Apache Kafka 3.0.0, users are allowed to specify these properties in connector configurations for Kafka Connect clusters running with out-of-the-box configurations. Before Apache Kafka 3.0.0, users may not specify these properties unless the Kafka Connect cluster has been reconfigured with a connector client override policy that permits them.
Since Apache Kafka 3.4.0, we have added a system property ("-Dorg.apache.kafka.disallowed.login.modules") to disable the problematic login modules usage in SASL JAAS configuration. Also by default "com.sun.security.auth.module.JndiLoginModule" is disabled in Apache Kafka Connect 3.4.0.
We advise the Kafka Connect users to validate connector configurations and only allow trusted JNDI configurations. Also examine connector dependencies for vulnerable versions and either upgrade their connectors, upgrading that specific dependency,…
- Record
OESA-2026-4422- CVSS 3.1
- 9.8 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - Updated
- 2026-11-02
OSVOESA-2026-4423
kafka security update
Apache Kafka is an open-source distributed event streaming platform used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications.
Security Fix(es):
JMSSink in all versions of Log4j 1.x is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration or if the configuration references an LDAP service the attacker has access to. The attacker can provide a TopicConnectionFactoryBindingName configuration causing JMSSink to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-4104. Note this issue only affects Log4j 1.x when specifically configured to use JMSSink, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.(CVE-2022-23302)
By design, the JDBCAppender in Log4j 1.2.x accepts an SQL statement as a configuration parameter where the values to be inserted are converters from PatternLayout. The message converter, %m, is likely to always be included. This allows attackers to manipulate the SQL by entering crafted strings into input fields or headers of an application that are logged allowing unintended SQL queries to be executed. Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default. Beginning in version 2.0-beta8, the JDBCAppender was re-introduced with proper support for parameterized SQL queries and further customization over the columns written to in logs. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.(CVE-2022-23305)
CVE-2020-9493 identified a deserialization issue that was present in Apache Chainsaw. Prior to Chainsaw V2.0 Chainsaw was a component of Apache Log4j 1.2.x where the same issue exists.(CVE-2022-23307)
A possible security vulnerability has been identified in Apache Kafka Connect API.
This requires access to a Kafka Connect worker, and the ability to create/modify connectors on it with an arbitrary Kafka client SASL JAAS config
and a SASL-based security protocol, which has been possible on Kafka Connect clusters since Apache Kafka Connect 2.3.0.
When configuring the connector via the Kafka Connect REST API, an authenticated operator can set the sasl.jaas.config
property for any of the connector's Kafka clients to "com.sun.security.auth.module.JndiLoginModule", which can be done via the
producer.override.sasl.jaas.config, consumer.override.sasl.jaas.config, or admin.override.sasl.jaas.config properties.
This will allow the server to connect to the attacker's LDAP server
and deserialize the LDAP response, which the attacker can use to execute java deserialization gadget chains on the Kafka connect server.
Attacker can cause unrestricted deserialization of untrusted data (or) RCE vulnerability when there are gadgets in the classpath.
Since Apache Kafka 3.0.0, users are allowed to specify these properties in connector configurations for Kafka Connect clusters running with out-of-the-box configurations. Before Apache Kafka 3.0.0, users may not specify these properties unless the Kafka Connect cluster has been reconfigured with a connector client override policy that permits them.
Since Apache Kafka 3.4.0, we have added a system property ("-Dorg.apache.kafka.disallowed.login.modules") to disable the problematic login modules usage in SASL JAAS configuration. Also by default "com.sun.security.auth.module.JndiLoginModule" is disabled in Apache Kafka Connect 3.4.0.
We advise the Kafka Connect users to validate connector configurations and only allow trusted JNDI configurations. Also examine connector dependencies for vulnerable versions and either upgrade their connectors, upgrading that specific dependency,…
- Record
OESA-2026-4423- CVSS 3.1
- 9.8 Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - Updated
- 2026-11-02
OSVBIT-kafka-2024-56128 No score
Apache Kafka: SCRAM authentication vulnerable to replay attacks when used without encryption
Incorrect Implementation of Authentication Algorithm in Apache Kafka's SCRAM implementation.
Issue Summary: Apache Kafka's implementation of the Salted Challenge Response Authentication Mechanism (SCRAM) did not fully adhere to the requirements of RFC 5802 [1]. Specifically, as per RFC 5802, the server must verify that the nonce sent by the client in the second message matches the nonce sent by the server in its first message. However, Kafka's SCRAM implementation did not perform this validation.
Impact: This vulnerability is exploitable only when an attacker has plaintext access to the SCRAM authentication exchange. However, the usage of SCRAM over plaintext is strongly discouraged as it is considered an insecure practice [2]. Apache Kafka recommends deploying SCRAM exclusively with TLS encryption to protect SCRAM exchanges from interception [3]. Deployments using SCRAM with TLS are not affected by this issue.
How to Detect If You Are Impacted: If your deployment uses SCRAM authentication over plaintext communication channels (without TLS encryption), you are likely impacted. To check if TLS is enabled, review your server.properties configuration file for listeners property. If you have SASL_PLAINTEXT in the listeners, then you are likely impacted.
Fix Details: The issue has been addressed by introducing nonce verification in the final message of the SCRAM authentication exchange to ensure compliance with RFC 5802.
Affected Versions: Apache Kafka versions 0.10.2.0 through 3.9.0, excluding the fixed versions below.
Fixed Versions: 3.9.0 3.8.1 3.7.2
Users are advised to upgrade to 3.7.2 or later to mitigate this issue.
Recommendations for Mitigation: Users unable to upgrade to the fixed versions can mitigate the issue by:
- Using TLS with SCRAM Authentication: Always deploy SCRAM over TLS to encrypt authentication exchanges and protect against interception.
- Considering Alternative Authentication Mechanisms: Evaluate alternative authentication mechanisms, such as PLAIN, Kerberos or OAuth with TLS, which provide additional layers of security.
- Record
BIT-kafka-2024-56128- Updated
- 2026-11-02
OSVCLSA-2025-1752019395 No score
TuxCare security update for org.apache.kafka (5 CVEs)
TuxCare rebuilt 3 org.apache.kafka packages to address 5 CVEs. Fixed in 3.2.3.tuxcare.1.
- Record
CLSA-2025-1752019395- Updated
- 2026-11-02
OSVCLSA-2026-1777855421 No score
TuxCare security update for org.apache.kafka (2 CVEs)
TuxCare rebuilt 3 org.apache.kafka packages to address 2 CVEs. Fixed in 2.8.2-tuxcare.1.
- Record
CLSA-2026-1777855421- Updated
- 2026-11-02
OSVROOT-APP-MAVEN-CVE-2024-56128 No score
CVE-2024-56128 in io.root.org.apache.kafka:kafka_2.12 - Patched by Root
Root has patched CVE-2024-56128 in the io.root.org.apache.kafka:kafka_2.12 package for Root:Maven. Multiple fixed versions available.
- Record
ROOT-APP-MAVEN-CVE-2024-56128- Updated
- 2026-11-02
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
org.apache.kafka:kafka_2.13Maven |
0.10.2.0 up to 3.7.2 | 3.7.2 |
org.apache.kafka:kafka_2.13Maven |
3.8.0 to 3.8.0 | 3.8.1 |
org.apache.kafka:kafka_2.12Maven |
0.10.2.0 up to 3.7.2 | 3.7.2 |
org.apache.kafka:kafka_2.12Maven |
3.8.0 to 3.8.0 | 3.8.1 |
org.apache.kafka:kafka_2.11Maven |
0.10.2.0 to 2.4.1 | None known |
org.apache.kafka:kafka_2.10Maven |
0.10.2.0 to 0.10.2.2 | None known |
kafkaBitnami |
3.8.0 up to 3.8.1, 0.10.2 up to 3.7.2 | 3.8.13.7.2 |
org.apache.kafka:kafka-clientsTuxCare:Maven From an advisory covering 5 CVEs |
3.2.3 up to 3.2.3.tuxcare.1, plus listed versions 3.2.3.tuxcare |
3.2.3.tuxcare.1 |
org.apache.kafka:kafka_2.12TuxCare:Maven From an advisory covering 5 CVEs |
3.2.3 up to 3.2.3.tuxcare.1, plus listed versions 3.2.3.tuxcare |
3.2.3.tuxcare.1 |
org.apache.kafka:kafka_2.13TuxCare:Maven From an advisory covering 5 CVEs |
3.2.3 up to 3.2.3.tuxcare.1, plus listed versions 3.2.3.tuxcare |
3.2.3.tuxcare.1 |
Show 17 moreShow less
| Package | Affected | Fixed |
|---|---|---|
org.apache.kafka:connectTuxCare:Maven From an advisory covering 2 CVEs |
2.8.2 up to 2.8.2-tuxcare.1 | 2.8.2-tuxcare.1 |
org.apache.kafka:kafka_2.12TuxCare:Maven From an advisory covering 2 CVEs |
2.8.2 up to 2.8.2-tuxcare.1 | 2.8.2-tuxcare.1 |
org.apache.kafka:kafka_2.13TuxCare:Maven From an advisory covering 2 CVEs |
2.8.2 up to 2.8.2-tuxcare.1 | 2.8.2-tuxcare.1 |
org.apache.kafka:kafka_2.13Maven |
0.10.2.0 up to 3.7.2, plus listed versions 2.4.02.4.12.5.02.5.12.6.0 Show 32 moreShow less2.6.12.6.22.6.32.7.02.7.12.7.22.8.02.8.12.8.23.0.03.0.13.0.23.1.03.1.13.1.23.2.03.2.13.2.23.2.33.3.03.3.13.3.23.4.03.4.13.5.03.5.13.5.23.6.03.6.13.6.23.7.03.7.1 |
3.7.2 |
org.apache.kafka:kafka_2.13Maven |
3.8.0 up to 3.8.1 | 3.8.1 |
org.apache.kafka:kafka_2.12Maven |
0.10.2.0 up to 3.7.2, plus listed versions 0.10.2.10.10.2.20.11.0.00.11.0.10.11.0.2 Show 45 moreShow less0.11.0.31.0.01.0.11.0.21.1.01.1.12.0.02.0.12.1.02.1.12.2.02.2.12.2.22.3.02.3.12.4.02.4.12.5.02.5.12.6.02.6.12.6.22.6.32.7.02.7.12.7.22.8.02.8.12.8.23.0.03.0.13.0.23.1.03.1.13.1.23.2.03.2.13.2.23.2.33.3.03.3.13.3.23.4.03.4.13.5.0 |
3.7.2 |
org.apache.kafka:kafka_2.12Maven |
3.8.0 up to 3.8.1 | 3.8.1 |
org.apache.kafka:kafka_2.11Maven |
0.10.2.0 to 2.4.1, plus listed versions 0.10.2.10.10.2.20.11.0.00.11.0.10.11.0.2 Show 16 moreShow less0.11.0.31.0.01.0.11.0.21.1.01.1.12.0.02.0.12.1.02.1.12.2.02.2.12.2.22.3.02.3.12.4.0 |
None known |
org.apache.kafka:kafka_2.10Maven |
0.10.2.0 to 0.10.2.2, plus listed versions 0.10.2.1 |
None known |
kafkaopenEuler:22.03-LTS-SP4 From an advisory covering 11 CVEs |
before 2.8.2-3.oe2203sp4 | 2.8.2-3.oe2203sp4 |
kafkaopenEuler:24.03-LTS-SP1 From an advisory covering 9 CVEs |
before 2.8.2-21.oe2403sp1 | 2.8.2-21.oe2403sp1 |
kafkaopenEuler:24.03-LTS-SP3 From an advisory covering 9 CVEs |
before 2.8.2-21.oe2403sp3 | 2.8.2-21.oe2403sp3 |
kafkaopenEuler:24.03-LTS-SP4 From an advisory covering 9 CVEs |
before 2.8.2-21.oe2403sp4 | 2.8.2-21.oe2403sp4 |
io.root.org.apache.kafka:kafka_2.12Root:Maven |
before 3.6.0-root.io.1 | 3.6.0-root.io.13.7.1-root.io.13.6.0-root.io.23.6.0-root.io.33.7.1-root.io.23.7.1-root.io.33.8.1-root.io.4 |
io.root.org.apache.kafka:kafka_2.13Root:Maven |
before 3.6.0-root.io.1 | 3.6.0-root.io.13.7.1-root.io.13.6.0-root.io.23.6.0-root.io.33.7.1-root.io.23.7.1-root.io.33.8.1-root.io.23.8.1-root.io.33.8.1-root.io.4 |
org.apache.kafka:kafka_2.12Root:Maven |
before 3.6.0-aikido.3 | 3.6.0-aikido.33.7.1-aikido.23.7.1-aikido.33.8.1-aikido.4 |
org.apache.kafka:kafka_2.13Root:Maven |
before 3.6.0-aikido.3 | 3.6.0-aikido.33.7.1-aikido.23.7.1-aikido.33.8.1-aikido.33.8.1-aikido.4 |
History
| Recorded | Changed | Sources |
|---|---|---|
| affected, facts | ||
| aliases, published | EUVD | |
| first indexed | CVE List, GitHub Advisories, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2024-56128 is a medium vulnerability (CVSS 5.3) in Apache Kafka, published December 18, 2024. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.82%, the 57th percentile. Fixed in org.apache.kafka:kafka_2.13 3.7.2.
References
datatracker.ietf.org/doc/html/rfc5802
kafka.apache.org/documentation
lists.apache.org/thread/84dh4so32lwn7wr6c5s9mwh381vx9wkw
openwall.com/lists/oss-security/2024/12/18/3
nvd.nist.gov/vuln/detail/CVE-2024-56128
github.com/apache/kafka/commit/2cbc5bd3ca22185d9cd357c9db23a2cfb43a0fff
Show 17 moreShow less
openeuler.org/zh/security/security-bulletins/detail?id=openEuler-SA-2026-4420
Left out here: 7 versions and the rest of 4 source descriptions. The JSON record has them.