Apache Kafka's SCRAM implementation Incorrectly Implements Authentication AlgorithmGHSA-p7c9-8xx8-h74f
MEDIUMFix: apache/kafka@2cbc5bdGHSA-p7c9-8xx8-h74f is a medium-severity (CVSS 5.3) CWE-303 vulnerability in org.apache.kafka:kafka_2.13. A fix is available for org.apache.kafka:kafka_2.13 — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-p7c9-8xx8-h74f.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
org.apache.kafka:kafka_2.13☕org.apache.kafka:kafka_2.13☕org.apache.kafka:kafka_2.12☕org.apache.kafka:kafka_2.12☕org.apache.kafka:kafka_2.11☕org.apache.kafka:kafka_2.10Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.apache.kafka:kafka_2.13 | ≥ 0.10.2.0&&< 3.7.2 | 3.7.2org.apache.kafka:kafka_2.13:3.7.2 |
| ☕Maven | org.apache.kafka:kafka_2.13 | ≥ 3.8.0&&< 3.8.1 | 3.8.1org.apache.kafka:kafka_2.13:3.8.1 |
| ☕Maven | org.apache.kafka:kafka_2.12 | ≥ 0.10.2.0&&< 3.7.2 | 3.7.2org.apache.kafka:kafka_2.12:3.7.2 |
| ☕Maven | org.apache.kafka:kafka_2.12 | ≥ 3.8.0&&< 3.8.1 | 3.8.1org.apache.kafka:kafka_2.12:3.8.1 |
| ☕Maven | org.apache.kafka:kafka_2.11 | ≥ 0.10.2.0 | No fix |
| ☕Maven | org.apache.kafka:kafka_2.10 | ≥ 0.10.2.0 | No fix |
Affected Products
kafkaapacheDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.apache.kafka:kafka_2.13, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update org.apache.kafka:kafka_2.13 to 3.7.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-p7c9-8xx8-h74f is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
This vulnerability is marked with an Important severity because it compromises a fundamental security requirement of the SCRAM protocol as specified in RFC 5802 —the validation of nonces for ensuring message integrity and preventing replay attacks. Without proper nonce validation, an attacker with plaintext access to…
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.Source: Red Hat security advisory for GHSA-p7c9-8xx8-h74f (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| Streams for Apache Kafka 2.9.1 | see advisory | RHSA-2025:9922 |
| Streams for Apache Kafka 3.0.0 | see advisory | RHSA-2025:12511 |
| Streams for Apache Kafka 3.1.0 | kafka_2.13 | RHSA-2025:23417 |
Frequently Asked Questions
Is GHSA-p7c9-8xx8-h74f in your dependencies?
Find it across Maven, including transitive dependencies.