Skip to content
VulniPulse
High 2 vendors · 2 advisories

CVE-2026-111108: Apache Kafka: Broker OutOfMemoryError via array allocation amplification in code-generated protocol readers

CVE-2026-111108 key facts

CISA KEV
Not listed (catalogue checked )
Highest advisory rating
High
CVSS base score
7.5 (Red Hat)
CVSS vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H · base score 9.1, scored by CISA-ADPAttack vector: network. Attack complexity: low. Privileges required: none. User interaction: none. Scope: unchanged. Confidentiality impact: high. Integrity impact: none. Availability impact: high.
Weakness
  • CWE-770 Allocation of resources without limits or throttling
  • CWE-789 Memory allocation with excessive size value
  • CWE-400 Uncontrolled Resource Consumption
EPSS
0.59% chance of exploitation in the next 30 days (48th percentile). FIRST EPSS, .
CISA SSVC
Exploitation: none observed. Automatable: yes. Technical impact: partial. CISA, .
Fixed releases
  • Apache: 4.2.2, 4.3.2, 4.4.0
  • Red Hat: 4.2.2, 4.3.2, 4.4.0
Vendor advisories
2 from Apache, Red Hat
Assigned by
apache (CNA)
CVE record published
Listed by VulniPulse
Record changed

Ratings, versions and fixes are quoted from the vendor advisories that cover only CVE-2026-111108; each belongs to its advisory, not to every product listed. How records are collected and checked.

Description

Apache Kafka's code-generated protocol readers pre-size an array's collection from the element count declared by the sender. That count is checked only against the bytes remaining in the request buffer, which assumes about one byte per element; because most elements need several bytes, a request can declare far more elements than the buffer holds and still pass. For a keyed array the reader then allocates an ImplicitLinkedHashCollection of capacity (2 * count +1), so a request of a few tens of megabytes can force a heap allocation several times larger before any element is read. The pattern is emitted into every generated reader, so it affects all Kafka API types with an array field. Impact: Request parsing happens before any authorization check. On a listener that does not require authentication (for example PLAINTEXT), an unauthenticated attacker can send a few concurrent requests that each declare a very large= array length and allocate many times their wire size in broker heap, crashing the broker with an OutOfMemoryError. The reporter demonstrated three concurrent ~90 MB ProduceRequest (v3) connections exhausting a 1 GB heap (~8x amplification). On listeners that require authentication, the attacker needs valid credentials but no specific ACL, since parsing precedes authorization.. Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Until then, lowering socket.request.max.bytes and restricting network access to broker listeners reduces, but does not remove, exposure. Resolution: From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers cap the initial array pre-allocation at MessageUtil.MAX_PREALLOCATED_ARRAY_CAPACITY (1000) and grow it on demand, and reject a declared array length above MessageUtil.MAX_ARRAY_LENGTH (1,000,000).

Text from the CVE.org record (apache).

How do I fix CVE-2026-111108?

Upgrade to a fixed release named by the vendor:

  • Apache: 4.2.2, 4.3.2, 4.4.0
  • Red Hat: 4.2.2, 4.3.2, 4.4.0
  • Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. (Apache)
  • Until then, lowering socket.request.max.bytes and restricting network access to broker listeners reduces, but does not remove, exposure. (Apache)
  • Red Hat is not aware of any available mitigation for this issue. Customers are advised to apply the relevant security updates as they become available. (Red Hat)

Vendor advisories for CVE-2026-111108

Apache

1 advisory
  • Advisory severityUnrated

    Advisory [CVE-2026-111108] Apache Kafka: Broker OutOfMemoryError via array allocation amplification in code-generated protocol readers

    CVE-2026-111108Source published Source updated

    Apache Kafka's code-generated protocol readers pre-size an array's collection from the element count declared by the sender. That count is checked only against the bytes remaining in the request buffer, which assumes about one byte per element; because most elements need several bytes, a request can declare far more elements than the buffer holds and still pass. For a keyed array the reader then allocates an ImplicitLinkedHashCollection of capacity (2 * count +1), so a request of a few tens of megabytes can force a heap allocation several times larger before any element is read. The pattern is emitted into every generated reader, so it affects all Kafka API types with an array field. Impact: Request parsing happens before any authorization check. On a listener that does not require…

    Affected products in this advisory
    • Apache Kafka
    Source-reported affected versions
    • Apache Kafka 3.3.0 through 4.1.2
    • Apache Kafka 4.2.0 through 4.2.1
    • Apache Kafka 4.3.0 through 4.3.1
    Source-reported fixed versions
    • 4.2.2
    • 4.3.2
    • 4.4.0
    Mitigation guidance
    • Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0.
    • Until then, lowering socket.request.max.bytes and restricting network access to broker listeners reduces, but does not remove, exposure.

Red Hat

1 advisory
  • Advisory severityHigh7.5

    High [CVE-2026-111108] Apache kafka: Denial of Service via excessive memory allocation during request parsing

    CVE-2026-111108Source published Source updated

    Apache kafka: Denial of Service via excessive memory allocation during request parsing. Red Hat rates this important (CVSS 7.5). Weakness: CWE-770. Affected product named by the advisory: streams for Apache Kafka 3.

    Related products — impact not confirmed
    • streams for Apache Kafka 3
    Source-reported affected versions
    Affected-version details not available in this record.
    Source-reported fixed versions
    • 4.2.2
    • 4.3.2
    • 4.4.0
    Mitigation guidance
    • Red Hat is not aware of any available mitigation for this issue. Customers are advised to apply the relevant security updates as they become available.

References

Timeline

  1. CVE record published
  2. First vendor advisory listed by VulniPulse
  3. CVE record last updated

All Apache advisories

Get an email when Apache publishes the next one.

See Apache's last 90 days of advisories first. Then choose one product with live alerts free for life, or a free month of real-time alerts on everything with the severity, the fixed version and the vendor's link (card needed, then US$15/month; we email you before the first charge).

Alert me about Apache

iPhone and Android apps · New on the App Store

Get alerts for new CVEs on your phone.

Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 34 official vendor sources and 160+ reviewed platform categories.

Matching phone alertsOptional email delivery