CVE-2022-34917VulnerabilityPublished 20 Sep 2022Updated 29 May 2025

CVE-2022-34917: Apache Kafka · Excessive Memory Allocation

Affects Apache KafkaSource CVE Database V5

Not known to be exploited · CVSS 7.5 High · fixed in 3.2.3 : patch Apache Kafka soon.

Data as of 26 Oct 2026, 06:26 UTC

CVSS 3.1 base score

7.5High

How severe the flaw is on the 0–10 CVSS scale.

EPSS: 1.4% chance of exploitation in 30 days – higher than 74% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch: Available – fixed in 3.2.3, 3.1.2, 3.0.2 +1

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Attack Vector: Network
Attack Complexity: Low
Privileges Required: None
User Interaction: None
Scope: Unchanged
Confidentiality: None
Integrity: None
Availability: High

Bold values are the worst case: easiest to exploit or largest impact.

Attack Vector: Network: The vulnerable component is bound to the network stack and the set of possible attackers extends beyond the other options listed, up to and including the entire Internet. Such a vulnerability is often termed 'remotely exploitable' and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers).
Attack Complexity: Low: Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component.
Privileges Required: None: The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files to carry out an attack.
User Interaction: None: The vulnerable system can be exploited without any interaction from any user.
Scope: Unchanged: An exploited vulnerability can only affect resources managed by the same security authority. In this case, the vulnerable component and the impacted component are either the same, or both are managed by the same security authority.
Confidentiality: None: There is no loss of confidentiality within the impacted component.
Integrity: None: There is no loss of integrity within the impacted component.
Availability: High: There is total loss of availability, resulting in the attacker being able to fully deny access to resources in the impacted component; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed). Alternatively, the attacker has the ability to deny some availability, but the loss of availability presents a direct, serious consequence to the impacted component (e.g., the attacker cannot disrupt existing connections, but can prevent new connections; the attacker can repeatedly exploit a vulnerability that, in each instance of a successful attack, leaks a only small amount of memory, but after repeated exploitation causes a service to become completely unavailable).

Definitions: FIRST CVSS v3.1 specification.

Exploitation evidence

Disclosed: evidence found.
CVE published 20 Sep 2022
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 2026-10-26.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

Upgrade org.apache.kafka/kafka to 3.2.3, 3.1.2, 3.0.2 or 2.8.2.

Affected software

Product	Affected	Fixed in
Mavenorg.apache.kafka/kafka`pkg:maven/org.apache.kafka/kafka`Other threats	Affected >=2.8.0 <2.8.2 <3.0.2 <3.1.2 <3.2.3	Fixed in 2.8.2 3.0.2 3.1.2 3.2.3

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

Beyond upgrading to the fixed Kafka versions (2.8.2, 3.0.2, 3.1.2, or 3.2.3), European organizations should implement several targeted mitigations: 1) Enforce strict network segmentation and firewall rules to limit broker access only to trusted clients and internal systems, reducing exposure to unauthenticated attackers. 2) Enable and enforce strong authentication mechanisms such as TLS mutual authentication or SASL with robust credential management to prevent unauthorized connections. 3) Monitor broker logs and metrics for unusual memory allocation patterns or spikes in resource usage that could indicate exploitation attempts. 4) Implement rate limiting or connection throttling at the network or Kafka broker level to mitigate rapid or excessive memory allocation requests. 5) Conduct regular security audits and penetration testing focused on Kafka deployments to identify and remediate configuration weaknesses. 6) Maintain an up-to-date inventory of Kafka versions in use and automate patch management processes to ensure timely application of security updates. 7) Consider deploying Kafka in high-availability configurations with failover capabilities to minimize service disruption in case of an attack.

Description

A security vulnerability has been identified in Apache Kafka. It affects all releases since 2.8.0. The vulnerability allows malicious unauthenticated clients to allocate large amounts of memory on brokers. This can lead to brokers hitting OutOfMemoryException and causing denial of service. Example scenarios: - Kafka cluster without authentication: Any clients able to establish a network connection to a broker can trigger the issue. - Kafka cluster with SASL authentication: Any clients able to establish a network connection to a broker, without the need for valid SASL credentials, can trigger the issue. - Kafka cluster with TLS authentication: Only clients able to successfully authenticate via TLS can trigger the issue. We advise the users to upgrade the Kafka installations to one of the 3.2.3, 3.1.2, 3.0.2, 2.8.2 versions.

Impact

For European organizations, the impact of CVE-2022-34917 can be significant, especially for enterprises relying on Apache Kafka for critical data streaming, event processing, and real-time analytics. Kafka is widely used in sectors such as finance, telecommunications, manufacturing, and public services across Europe. A successful exploitation could lead to broker outages, disrupting data pipelines and causing downtime in dependent applications and services. This can result in operational delays, financial losses, and reputational damage. Organizations with Kafka clusters lacking strong authentication mechanisms are particularly vulnerable, as attackers can exploit the vulnerability without credentials. Even in environments with SASL or TLS authentication, the risk remains if network access controls are insufficient. The denial of service could also be leveraged as part of a larger attack campaign to degrade service availability or distract security teams. Given the critical role Kafka plays in modern IT infrastructures, the availability impact can cascade to multiple business units and external customers.

CWE-789Memory Allocation with Excessive Size Value (opens in a new tab)
Variant weakness
The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.
Implementation · Architecture and Design
Perform adequate input validation against any value that influences the amount of memory that is allocated. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the amount of memory to be used if necessary.
Operation
Run your program using system-provided resource limits for memory. This might still cause the program to crash or exit, but the impact to the rest of the system will be minimized.
OWASP Cheat Sheets
Abuse Case (opens in a new tab)
OWASP ASVS 4.0.3
V8.1.4 (opens in a new tab)
V13.4.1 (opens in a new tab)
V11.1.4 (opens in a new tab)
From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).

References

kafka.apache.org/cve-list (opens in a new tab)

Community reviews

Loading reviews…

Exploitation evidence

What to do

Affected software

Description

AI analysisMachine-generated, updated 8 Jul 2025, 03:09 UTC

WeaknessesCWE-789

Technical details

References

Community reviews

Related threats