CVE-2026-111115
Description
A flaw was found in Apache Kafka. An unauthenticated remote attacker can exploit this vulnerability by sending a specially crafted request containing a large declared count of tagged fields in flexible request headers. Because the server does not adequately validate or limit this count against the incoming data buffer, it allocates an excessive number of memory objects before authentication or quota checks occur. This can exhaust system memory, leading to broker unresponsiveness and a Denial of Service (DoS).
Statement
This vulnerability is rated as Important because an unauthenticated remote attacker can trigger severe broker heap exhaustion or prolonged garbage collection stalls without requiring valid credentials or permissions. Because flexible request headers are parsed on network listener threads prior to access control and quota enforcement, any client capable of establishing a TCP connection to an exposed Kafka broker port can trigger the denial of service. While standalone client applications are typically unaffected, deployments hosting Kafka broker services that accept traffic from untrusted networks face immediate service availability risks.
Mitigation
Restrict network exposure of Kafka broker listener ports and reduce the maximum permitted request frame size:
1. Restrict broker network access:
Limit connectivity to broker listeners (default port 9092/tcp) to trusted clients and internal subnets using firewall rules:
firewall-cmd --permanent --zone=trusted --add-source=192.168.1.0/24
firewall-cmd --reload
2. Reduce request size limits:
In the Kafka broker configuration file (such as `server.properties`), reduce the outer request frame limit by lowering `socket.request.max.bytes` to a smaller value appropriate for your workload:
socket.request.max.bytes=10485760
Caveats:
Modifying `socket.request.max.bytes` requires restarting the Kafka broker service (`systemctl restart ...`), which causes a temporary interruption of service. Lowering this value will cause requests exceeding the threshold to be dropped, potentially affecting legitimate producers or consumers if set below maximum valid message sizes. Restricting network access and lowering the threshold reduces the amplification risk but does not entirely eliminate exposure for connections originating from permitted networks.
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
The following CVSS metrics and score provided are preliminary and subject to review.
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 7.5 | N/A | 9.1 |
| Attack Vector | Network | N/A | Network |
| Attack Complexity | Low | N/A | Low |
| Privileges Required | None | N/A | None |
| User Interaction | None | N/A | None |
| Scope | Unchanged | N/A | Unchanged |
| Confidentiality | None | N/A | High |
| Integrity Impact | None | N/A | None |
| Availability Impact | High | N/A | High |
Vector
Red Hat: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
cve.org: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
Understanding the Weakness (CWE)
Availability
Technical Impact: DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other)
When allocating resources without limits, an attacker could prevent other systems, applications, or processes from accessing the same type of resource. It can be easy for an attacker to consume many resources by rapidly making many requests or causing larger resources to be used than is needed.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
