{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-10-28T20:06:52.812Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/10/28/10"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.kafka:kafka",
          "packageURL": "pkg:maven/org.apache.kafka/kafka",
          "product": "Apache Kafka",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "4.1.2",
              "status": "affected",
              "version": "3.3.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.2.1",
              "status": "affected",
              "version": "4.2.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.3.1",
              "status": "affected",
              "version": "4.3.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Mike Read (GitHub: Michael-JRead)"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Izzy Harker \u003ciharker@confluent.io\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Alyssa Huang \u003cahuang@confluent.io\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Truc Nguyen  \u003ctrnguyen@confluent.io\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003eApache Kafka\u0027s code-generated protocol readers pre-size an array\u0027s collection from the element\u0026nbsp;\u003cspan\u003ecount declared by the sender. That count is checked only against the bytes remaining in the\u0026nbsp;\u003c/span\u003e\u003cspan\u003erequest buffer, which assumes about one byte per element; because most elements need several\u0026nbsp;\u003c/span\u003e\u003cspan\u003ebytes, a request can declare far more elements than the buffer holds and still pass. For a\u0026nbsp;\u003c/span\u003e\u003cspan\u003ekeyed array the reader then allocates an ImplicitLinkedHashCollection of capacity (2 * count +\u003c/span\u003e\u003cspan\u003e1), so a request of a few tens of megabytes can force a heap allocation several times larger\u0026nbsp;\u003c/span\u003e\u003cspan\u003ebefore any element is read. The pattern is emitted into every generated reader, so it affects\u0026nbsp;\u003c/span\u003e\u003cspan\u003eall Kafka API types with an array field.\u0026nbsp;\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eImpact:\u003c/div\u003e\u003cdiv\u003eRequest parsing happens before any authorization check. On a listener that does not require\u0026nbsp;\u003cspan\u003eauthentication (for example PLAINTEXT), an unauthenticated attacker can send a few concurrent\u0026nbsp;\u003c/span\u003e\u003cspan\u003erequests that each declare a very large=\u003c/span\u003e\u003c/div\u003e\u003cdiv\u003e\u003cspan\u003earray length and allocate many times their wire size\u0026nbsp;\u003c/span\u003e\u003cspan\u003ein broker heap, crashing the broker with an OutOfMemoryError. The reporter demonstrated three\u0026nbsp;\u003c/span\u003e\u003cspan\u003econcurrent ~90 MB ProduceRequest (v3) connections exhausting a 1 GB heap (~8x amplification).\u0026nbsp;\u003c/span\u003e\u003cspan\u003eOn listeners that require authentication, the attacker needs valid credentials but no specific ACL,\u0026nbsp;\u003c/span\u003e\u003cspan\u003esince parsing precedes authorization.\u003c/span\u003e\u003cspan\u003e.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eMitigation:\u003c/div\u003e\u003cdiv\u003eUpgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Until then, lowering socket.request.max.bytes\u0026nbsp;\u003cspan\u003eand restricting network access to broker listeners reduces, but does not remove, exposure.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eResolution:\u003c/div\u003e\u003cdiv\u003eFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers cap the initial array\u0026nbsp;\u003cspan\u003epre-allocation at MessageUtil.MAX_PREALLOCATED_ARRAY_CAPACITY (1000) and grow it on demand,\u0026nbsp;\u003c/span\u003e\u003cspan\u003eand reject a declared array length above MessageUtil.MAX_ARRAY_LENGTH (1,000,000).\u003c/span\u003e\u003c/div\u003e"
            }
          ],
          "value": "Apache Kafka\u0027s code-generated protocol readers pre-size an array\u0027s collection from the element\u00a0count declared by the sender. That count is checked only against the bytes remaining in the\u00a0request buffer, which assumes about one byte per element; because most elements need several\u00a0bytes, a request can declare far more elements than the buffer holds and still pass. For a\u00a0keyed 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\u00a0before any element is read. The pattern is emitted into every generated reader, so it affects\u00a0all Kafka API types with an array field.\u00a0\n\n\nImpact:\n\nRequest parsing happens before any authorization check. On a listener that does not require\u00a0authentication (for example PLAINTEXT), an unauthenticated attacker can send a few concurrent\u00a0requests that each declare a very large=\n\narray length and allocate many times their wire size\u00a0in broker heap, crashing the broker with an OutOfMemoryError. The reporter demonstrated three\u00a0concurrent ~90 MB ProduceRequest (v3) connections exhausting a 1 GB heap (~8x amplification).\u00a0On listeners that require authentication, the attacker needs valid credentials but no specific ACL,\u00a0since parsing precedes authorization..\n\n\nMitigation:\n\nUpgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Until then, lowering socket.request.max.bytes\u00a0and restricting network access to broker listeners reduces, but does not remove, exposure.\n\n\nResolution:\n\nFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers cap the initial array\u00a0pre-allocation at MessageUtil.MAX_PREALLOCATED_ARRAY_CAPACITY (1000) and grow it on demand,\u00a0and reject a declared array length above MessageUtil.MAX_ARRAY_LENGTH (1,000,000)."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "important"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770 Allocation of resources without limits or throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-789",
              "description": "CWE-789 Memory allocation with excessive size value",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-400",
              "description": "CWE-400 Uncontrolled Resource Consumption",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T16:38:08.524Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://kafka.apache.org/cve-list"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Apache Kafka: Broker OutOfMemoryError via array allocation amplification in code-generated protocol readers",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-111108",
    "datePublished": "2026-10-28T16:38:08.524Z",
    "dateReserved": "2026-10-15T15:57:59.889Z",
    "dateUpdated": "2026-10-28T20:06:52.812Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}