{
  "containers": {
    "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": [
            {
              "lessThan": "4.4.0",
              "status": "affected",
              "version": "3.1.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Kai Aizen \u003ckai.aizen.dev@gmail.com\u003e, SnailSploit"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Evan Zhou \u003cezhou@confluent.io\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003e\u003c/div\u003e\u003cdiv\u003e\u003cp\u003eA Kafka broker that authenticates clients with SASL/OAUTHBEARER using the bundled JWKS-backed validator always verifies the JWT signature, but two further checks are only performed when explicitly configured:\u003cbr\u003e\u003cbr\u003e- The issuer (iss) claim is verified only when sasl.oauthbearer.expected.issuer is set. When it is unset, a validly-signed token carrying the expected audience is accepted regardless of which issuer minted it.\u003cbr\u003e- An audience (aud) claim is required only when sasl.oauthbearer.expected.audience is set. When it is unset, a validly-signed token that omits the aud claim is accepted. (A token that carries an aud claim is\u003cbr\u003e  still rejected when no expected audience is configured.)\u003cbr\u003e\u003cbr\u003eBoth options default to unset and have been documented as optional (Importance LOW) since KIP-768 (3.1.0).\u003cbr\u003e\u003cbr\u003eImpact:\u003cbr\u003e  The exposure is realizable mainly in deployments whose JWKS endpoint serves signing keys for more than one issuer (a multi-tenant identity provider, an aggregated/shared JWKS, or shared signing keys): a token\u003cbr\u003e  minted for a different issuer, or a token lacking an audience, may be accepted to authenticate \u2014 potentially as a higher-privileged principal. In a single-issuer deployment where the provider controls the iss\u003cbr\u003e  claim and issues audience-scoped tokens, exposure is limited. The signature trust anchor remains enforced in all cases. This is distinct from CVE-2026-33557 (acceptance of unsigned/unvalidated tokens); here the\u003cbr\u003e  signature is validated and only the issuer/audience checks are not enforced by default.\u003cbr\u003e\u003cbr\u003eMitigation (all affected versions, no upgrade required):\u003cbr\u003e  Set both sasl.oauthbearer.expected.issuer (to your provider\u0027s exact iss value) and sasl.oauthbearer.expected.audience (to the audience(s) your brokers expect), per listener. Brokers that set these perform\u003cbr\u003e  exact-match issuer/audience checks and are not affected. Both have been available since 3.1.0.\u003cbr\u003e\u003cbr\u003eResolution:\u003cbr\u003e  - From Apache Kafka 4.4.0: a broker configured with a JWKS endpoint fails to start unless both sasl.oauthbearer.expected.issuer and sasl.oauthbearer.expected.audience are set (secure by default). Deployments that\u003cbr\u003e  intentionally do not restrict the issuer and/or audience may opt out per axis with sasl.oauthbearer.allow.unverified.issuer=true and/or sasl.oauthbearer.allow.unverified.audience=true.\u003c/p\u003e\u003c/div\u003e"
            }
          ],
          "value": "A Kafka broker that authenticates clients with SASL/OAUTHBEARER using the bundled JWKS-backed validator always verifies the JWT signature, but two further checks are only performed when explicitly configured:\n\n- The issuer (iss) claim is verified only when sasl.oauthbearer.expected.issuer is set. When it is unset, a validly-signed token carrying the expected audience is accepted regardless of which issuer minted it.\n- An audience (aud) claim is required only when sasl.oauthbearer.expected.audience is set. When it is unset, a validly-signed token that omits the aud claim is accepted. (A token that carries an aud claim is\n  still rejected when no expected audience is configured.)\n\nBoth options default to unset and have been documented as optional (Importance LOW) since KIP-768 (3.1.0).\n\nImpact:\n  The exposure is realizable mainly in deployments whose JWKS endpoint serves signing keys for more than one issuer (a multi-tenant identity provider, an aggregated/shared JWKS, or shared signing keys): a token\n  minted for a different issuer, or a token lacking an audience, may be accepted to authenticate \u2014 potentially as a higher-privileged principal. In a single-issuer deployment where the provider controls the iss\n  claim and issues audience-scoped tokens, exposure is limited. The signature trust anchor remains enforced in all cases. This is distinct from CVE-2026-33557 (acceptance of unsigned/unvalidated tokens); here the\n  signature is validated and only the issuer/audience checks are not enforced by default.\n\nMitigation (all affected versions, no upgrade required):\n  Set both sasl.oauthbearer.expected.issuer (to your provider\u0027s exact iss value) and sasl.oauthbearer.expected.audience (to the audience(s) your brokers expect), per listener. Brokers that set these perform\n  exact-match issuer/audience checks and are not affected. Both have been available since 3.1.0.\n\nResolution:\n  - From Apache Kafka 4.4.0: a broker configured with a JWKS endpoint fails to start unless both sasl.oauthbearer.expected.issuer and sasl.oauthbearer.expected.audience are set (secure by default). Deployments that\n  intentionally do not restrict the issuer and/or audience may opt out per axis with sasl.oauthbearer.allow.unverified.issuer=true and/or sasl.oauthbearer.allow.unverified.audience=true."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "moderate"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-345",
              "description": "CWE-345 Insufficient Verification of Data Authenticity)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-1188",
              "description": "CWE-1188 Initialization of a resource with an insecure default",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T16:37:34.723Z",
        "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 does not enforce JWT issuer and audience validation for SASL/OAUTHBEARER by default",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-110952",
    "datePublished": "2026-10-28T16:37:34.723Z",
    "dateReserved": "2026-10-15T09:13:40.750Z",
    "dateUpdated": "2026-10-28T16:37:34.723Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "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": "4.1.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.2.1",
              "status": "affected",
              "version": "4.2.0",
              "versionType": "semver"
            },
            {
              "status": "affected",
              "version": "4.3.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "San Zhang \u003cfalaxe1642@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "Kaixuan Li \u003ckaixuanli0131@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Evan Zhou \u003cezhou@confluent.io\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003eA Kafka broker using SASL/OAUTHBEARER with the default validator\u0026nbsp;\u003cspan\u003e(sasl.oauthbearer.jwt.validator.class=DefaultJwtValidator) selects its implementation from\u0026nbsp;\u003c/span\u003e\u003cspan\u003econfiguration. When sasl.oauthbearer.jwks.endpoint.url is set, the validator verifies the\u0026nbsp;\u003c/span\u003e\u003cspan\u003eJWT signature. When that URL is unset (the default) and no verification key resolver is\u0026nbsp;\u003c/span\u003e\u003cspan\u003esupplied, DefaultJwtValidator silently falls back to ClientJwtValidator, which does not\u0026nbsp;\u003c/span\u003e\u003cspan\u003everify the JWT signature, algorithm, or issuer - and the broker starts with no warning or\u0026nbsp;\u003c/span\u003e\u003cspan\u003eerror. This is the residual of CVE-2026-33557, whose fix restored signature verification\u0026nbsp;\u003c/span\u003e\u003cspan\u003eonly on the path where the JWKS endpoint URL is set.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eImpact:\u003c/div\u003e\u003cdiv\u003eA broker in this state accepts any structurally valid JWT, including \"alg\":\"none\" tokens. An\u0026nbsp;\u003cspan\u003eunauthenticated remote attacker who can reach the listener can forge a token asserting any\u0026nbsp;\u003c/span\u003e\u003cspan\u003eprincipal - including configured superusers - and gain full access to the cluster. Only\u0026nbsp;\u003c/span\u003e\u003cspan\u003ebrokers that enable SASL/OAUTHBEARER validation without a JWKS endpoint URL (and without a\u0026nbsp;\u003c/span\u003e\u003cspan\u003ecustom verification key resolver) are affected; brokers that set the URL verify signatures\u0026nbsp;\u003c/span\u003e\u003cspan\u003eand are not affected. Unlike CVE-2026-110952 (issuer/audience not enforced by default), here\u0026nbsp;\u003c/span\u003e\u003cspan\u003eno signature is verified at all.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eMitigation (all affected versions, no upgrade required):\u003c/div\u003e\u003cdiv\u003e\u003cdiv\u003eSet sasl.oauthbearer.jwks.endpoint.url for every listener/mechanism that uses\u0026nbsp;\u003cspan\u003eOAuthBearerValidatorCallbackHandler, or configure a signature-verifying\u0026nbsp;\u003c/span\u003e\u003cspan\u003esasl.oauthbearer.jwt.validator.class.\u003cbr\u003e\u003c/span\u003e\u003cspan\u003e\u003cbr\u003eResolution:\u003c/span\u003e\u003c/div\u003e\u003cdiv\u003e\u003cspan\u003eFrom Apache Kafka 4.2.2, 4.3.1, and 4.4.0: a broker that would fall back to the\u0026nbsp;\u003c/span\u003e\u003cspan\u003enon-verifying ClientJwtValidator fails to start with a ConfigException instead of running\u0026nbsp;\u003c/span\u003e\u003cspan\u003ewithout signature verification (secure by default).\u0026nbsp;\u003c/span\u003e\u003c/div\u003e\u003c/div\u003e"
            }
          ],
          "value": "A Kafka broker using SASL/OAUTHBEARER with the default validator\u00a0(sasl.oauthbearer.jwt.validator.class=DefaultJwtValidator) selects its implementation from\u00a0configuration. When sasl.oauthbearer.jwks.endpoint.url is set, the validator verifies the\u00a0JWT signature. When that URL is unset (the default) and no verification key resolver is\u00a0supplied, DefaultJwtValidator silently falls back to ClientJwtValidator, which does not\u00a0verify the JWT signature, algorithm, or issuer - and the broker starts with no warning or\u00a0error. This is the residual of CVE-2026-33557, whose fix restored signature verification\u00a0only on the path where the JWKS endpoint URL is set.\n\n\nImpact:\n\nA broker in this state accepts any structurally valid JWT, including \"alg\":\"none\" tokens. An\u00a0unauthenticated remote attacker who can reach the listener can forge a token asserting any\u00a0principal - including configured superusers - and gain full access to the cluster. Only\u00a0brokers that enable SASL/OAUTHBEARER validation without a JWKS endpoint URL (and without a\u00a0custom verification key resolver) are affected; brokers that set the URL verify signatures\u00a0and are not affected. Unlike CVE-2026-110952 (issuer/audience not enforced by default), here\u00a0no signature is verified at all.\n\n\nMitigation (all affected versions, no upgrade required):\n\nSet sasl.oauthbearer.jwks.endpoint.url for every listener/mechanism that uses\u00a0OAuthBearerValidatorCallbackHandler, or configure a signature-verifying\u00a0sasl.oauthbearer.jwt.validator.class.\n\nResolution:\n\nFrom Apache Kafka 4.2.2, 4.3.1, and 4.4.0: a broker that would fall back to the\u00a0non-verifying ClientJwtValidator fails to start with a ConfigException instead of running\u00a0without signature verification (secure by default)."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "important"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-345",
              "description": "CWE-345 Insufficient Verification of Data Authenticity and its child",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-347",
              "description": "CWE-347 Improper verification of cryptographic signature",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-1287",
              "description": "CWE-1287 Improper validation of specified type of input",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-636",
              "description": "CWE-636 Failing Open",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T16:37:45.688Z",
        "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 silently skips JWT signature verification for SASL/OAUTHBEARER when the JWKS endpoint URL is not configured",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-110985",
    "datePublished": "2026-10-28T16:37:45.688Z",
    "dateReserved": "2026-10-15T11:31:31.708Z",
    "dateUpdated": "2026-10-28T16:37:45.688Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-10-28T20:06:51.327Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/10/28/11"
          }
        ],
        "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.7.0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.2.1",
              "status": "affected",
              "version": "4.2.0",
              "versionType": "semver"
            },
            {
              "status": "affected",
              "version": "4.3.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Dawit Jeong \u003cdev.d4v1d@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Apoorv Mittal \u003capoorvmittal10@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Andrew Schofield \u003caschofield@confluent.io\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003eThe broker-side PushTelemetry API (KIP-714) validates only the compressed size of\u0026nbsp;\u003cspan\u003ea client\u0027s metrics payload against telemetry.max.bytes (default 1 MB) before decompressing\u0026nbsp;\u003c/span\u003e\u003cspan\u003eit. ClientTelemetryUtils.decompress() then decompresses the payload with no limit on the\u0026nbsp;\u003c/span\u003e\u003cspan\u003edecompressed output size, growing a heap buffer until the compressed input is exhausted. A\u0026nbsp;\u003c/span\u003e\u003cspan\u003esmall, highly compressible payload (for example gzip-compressed zeros) can therefore expand\u0026nbsp;\u003c/span\u003e\u003cspan\u003eto hundreds of megabytes of broker heap.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eImpact:\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eAn authenticated client can send a PushTelemetry request with a small compressed payload that\u0026nbsp;\u003cspan\u003edecompresses to a very large size, consuming broker heap out of proportion to the request\u0026nbsp;\u003c/span\u003e\u003cspan\u003esize. Repeated or concurrent requests can exhaust the broker heap and cause an\u0026nbsp;\u003c/span\u003e\u003cspan\u003eOutOfMemoryError, degrading or crashing the broker; a client that targets multiple brokers\u0026nbsp;\u003c/span\u003e\u003cspan\u003ecan affect cluster availability. PushTelemetry is available to any authenticated client and is\u0026nbsp;\u003c/span\u003e\u003cspan\u003enot gated by an ACL.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eMitigation:\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eUpgrade to Apache Kafka 4.2.2, 4.3.1, or 4.4.0. On affected versions there is no configuration that fully\u0026nbsp;\u003cspan\u003eprevents the amplification, because telemetry.max.bytes bounds only the compressed size;\u0026nbsp;\u003c/span\u003e\u003cspan\u003elowering telemetry.max.bytes reduces the worst-case decompressed size proportionally and is a\u0026nbsp;\u003c/span\u003e\u003cspan\u003epartial mitigation.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eResolution:\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003e- From Apache Kafka 4.2.2, 4.3.1, and 4.4.0: ClientTelemetryUtils.decompress() enforces a maximum decompressed\u0026nbsp;\u003cspan\u003esize equal to telemetry.max.bytes (default 1 MB). Decompression reads in bounded chunks and\u0026nbsp;\u003c/span\u003e\u003cspan\u003eaborts with a TelemetryTooLargeException once the decompressed total exceeds the limit, so an\u0026nbsp;\u003c/span\u003e\u003cspan\u003eover-large or highly compressible payload is rejected instead of being fully expanded in\u0026nbsp;\u003c/span\u003e\u003cspan\u003eheap. The decompressed size is therefore bounded by default.\u0026nbsp;\u003c/span\u003e\u003c/div\u003e"
            }
          ],
          "value": "The broker-side PushTelemetry API (KIP-714) validates only the compressed size of\u00a0a client\u0027s metrics payload against telemetry.max.bytes (default 1 MB) before decompressing\u00a0it. ClientTelemetryUtils.decompress() then decompresses the payload with no limit on the\u00a0decompressed output size, growing a heap buffer until the compressed input is exhausted. A\u00a0small, highly compressible payload (for example gzip-compressed zeros) can therefore expand\u00a0to hundreds of megabytes of broker heap.\n\n\nImpact:\n\n\nAn authenticated client can send a PushTelemetry request with a small compressed payload that\u00a0decompresses to a very large size, consuming broker heap out of proportion to the request\u00a0size. Repeated or concurrent requests can exhaust the broker heap and cause an\u00a0OutOfMemoryError, degrading or crashing the broker; a client that targets multiple brokers\u00a0can affect cluster availability. PushTelemetry is available to any authenticated client and is\u00a0not gated by an ACL.\n\n\nMitigation:\n\n\nUpgrade to Apache Kafka 4.2.2, 4.3.1, or 4.4.0. On affected versions there is no configuration that fully\u00a0prevents the amplification, because telemetry.max.bytes bounds only the compressed size;\u00a0lowering telemetry.max.bytes reduces the worst-case decompressed size proportionally and is a\u00a0partial mitigation.\n\n\nResolution:\n\n\n- From Apache Kafka 4.2.2, 4.3.1, and 4.4.0: ClientTelemetryUtils.decompress() enforces a maximum decompressed\u00a0size equal to telemetry.max.bytes (default 1 MB). Decompression reads in bounded chunks and\u00a0aborts with a TelemetryTooLargeException once the decompressed total exceeds the limit, so an\u00a0over-large or highly compressible payload is rejected instead of being fully expanded in\u00a0heap. The decompressed size is therefore bounded by default."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "moderate"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-409",
              "description": "CWE-409 Improper handling of highly compressed data (data amplification)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770 Allocation of resources without limits or throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-400",
              "description": "CWE-400 Uncontrolled Resource   Consumption",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T16:37:58.482Z",
        "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: PushTelemetry (KIP-714) metrics payloads are decompressed without a size limit, allowing a broker out-of-memory denial of service",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-111073",
    "datePublished": "2026-10-28T16:37:58.482Z",
    "dateReserved": "2026-10-15T13:40:49.926Z",
    "dateUpdated": "2026-10-28T20:06:51.327Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "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"
}

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-10-28T20:06:54.294Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/10/28/12"
          }
        ],
        "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": "2.4.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": "finder",
          "value": "Mufeed VH  \u003cmufeed@winfunc.com\u003e"
        },
        {
          "lang": "en",
          "type": "finder",
          "value": "Vivek R \u003cvivek@winfunc.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Shay Elkin \u003cselkin@confluent.io\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003e\u003cdiv\u003e\u003cspan\u003eApache Kafka\u0027s code-generated readers for flexible protocol versions read a tagged-field count\u0026nbsp;\u003c/span\u003e\u003cspan\u003edeclared by the sender and retain a RawTaggedField object for each unknown field. That count\u0026nbsp;\u003c/span\u003e\u003cspan\u003ewas bounded only by the outer request frame size (socket.request.max.bytes); it was not checked\u0026nbsp;\u003c/span\u003e\u003cspan\u003eagainst the remaining buffer bytes or capped. Because each entry can be encoded in as little as\u0026nbsp;\u003c/span\u003e\u003cspan\u003etwo bytes (unknown tag 0, size 0), a modest request can declare tens of millions of tagged\u0026nbsp;\u003c/span\u003e\u003cspan\u003efields and force one object allocation per declared field. Flexible request headers (header\u0026nbsp;\u003c/span\u003e\u003cspan\u003eversion 2, used by flexible APIs such as ApiVersions v3) are parsed this way, so the\u0026nbsp;\u003c/span\u003e\u003cspan\u003eamplification applies to the request header itself.\u003c/span\u003e\u003c/div\u003e\u003cdiv\u003e\u003cbr\u003eImpact:\u003cbr\u003eThe flexible request header is parsed on the network thread before authorization, request dispatch, and request-time quota accounting. A client can send a request of a few tens of megabytes whose header declares about 20 million tagged fields, forcing roughly that many RawTaggedField allocations and exhausting broker heap or inducing process-wide GC stalls, denying broker service. Because the header is parsed for pre-authentication APIs such as ApiVersions (v3), the allocation can occur before authentication; no Kafka resource ACL or quota is required.\u003cbr\u003e\u003cbr\u003eMitigation:\u003cbr\u003eUpgrade 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.\u003cbr\u003e\u003cbr\u003eResolution:\u003cbr\u003eFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers bounds-check the tagged-field count for flexible-versioned messages, rejecting a negative count, a count exceeding the remaining buffer bytes, or a count exceeding a fixed maximum (10,000), before any per-field allocation.\u003c/div\u003e\u003c/div\u003e"
            }
          ],
          "value": "Apache Kafka\u0027s code-generated readers for flexible protocol versions read a tagged-field count\u00a0declared by the sender and retain a RawTaggedField object for each unknown field. That count\u00a0was bounded only by the outer request frame size (socket.request.max.bytes); it was not checked\u00a0against the remaining buffer bytes or capped. Because each entry can be encoded in as little as\u00a0two bytes (unknown tag 0, size 0), a modest request can declare tens of millions of tagged\u00a0fields and force one object allocation per declared field. Flexible request headers (header\u00a0version 2, used by flexible APIs such as ApiVersions v3) are parsed this way, so the\u00a0amplification applies to the request header itself.\n\n\nImpact:\nThe flexible request header is parsed on the network thread before authorization, request dispatch, and request-time quota accounting. A client can send a request of a few tens of megabytes whose header declares about 20 million tagged fields, forcing roughly that many RawTaggedField allocations and exhausting broker heap or inducing process-wide GC stalls, denying broker service. Because the header is parsed for pre-authentication APIs such as ApiVersions (v3), the allocation can occur before authentication; no Kafka resource ACL or quota is required.\n\nMitigation:\nUpgrade 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.\n\nResolution:\nFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers bounds-check the tagged-field count for flexible-versioned messages, rejecting a negative count, a count exceeding the remaining buffer bytes, or a count exceeding a fixed maximum (10,000), before any per-field allocation."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "important"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T16:44:53.268Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://kafka.apache.org/cve-list"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Apache Kafka: Broker OutOfMemoryError via tagged-field allocation amplification in flexible protocol request parsing",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-111115",
    "datePublished": "2026-10-28T16:44:53.268Z",
    "dateReserved": "2026-10-15T16:27:16.838Z",
    "dateUpdated": "2026-10-28T20:06:54.294Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-10-28T20:06:55.726Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/10/28/14"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.kafka:kafka-streams",
          "packageURL": "pkg:maven/org.apache.kafka/kafka-streams",
          "product": "Apache Kafka",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "4.1.2",
              "status": "affected",
              "version": "1.1.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": "Matthias J. Sax \u003cmatthias@confluent.io\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003eKafka Streams derives its stream-time clock from record timestamps. PunctuationSchedule.next()\u0026nbsp;\u003cspan\u003ecomputed the next punctuation time as timestamp + (intervalsMissed + 1) * interval with no\u0026nbsp;\u003c/span\u003e\u003cspan\u003eoverflow check. A record with a timestamp at or near Long.MAX_VALUE advances stream time to that\u0026nbsp;\u003c/span\u003e\u003cspan\u003evalue, so the next stream-time punctuation overflows to a negative time. PunctuationQueue then\u0026nbsp;\u003c/span\u003e\u003cspan\u003ere-queues that time and loops on it indefinitely while holding a lock, stalling the StreamThread.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eImpact:\u003c/div\u003e\u003cdiv\u003eA single record is enough. The affected StreamThread stops processing, and because the record\u0026nbsp;\u003cspan\u003estays in the topic the hang returns on restart; an application whose partitions are all affected\u0026nbsp;\u003c/span\u003e\u003cspan\u003ebecomes unresponsive. Only the Streams application is affected, not the brokers or the cluster.\u0026nbsp;\u003c/span\u003e\u003cspan\u003eTriggering it needs write access to a source topic whose topology uses stream-time punctuation,\u0026nbsp;\u003c/span\u003e\u003cspan\u003eand a broker that stores the record: brokers from Apache Kafka 4.0.0 reject such a timestamp by\u0026nbsp;\u003c/span\u003e\u003cspan\u003edefault (log.message.timestamp.after.max.ms, one hour), so it is reachable only on older brokers\u0026nbsp;\u003c/span\u003e\u003cspan\u003eor where that bound has been relaxed.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eMitigation:\u003c/div\u003e\u003cdiv\u003eUpgrade Kafka Streams to 4.2.2, 4.3.2, or 4.4.0. As defense in depth, keep\u0026nbsp;\u003cspan\u003elog.message.timestamp.after.max.ms bounded on source topics and restrict write access to them.\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: the next punctuation time is computed with\u0026nbsp;\u003cspan\u003eoverflow-checked arithmetic (clamped to Long.MAX_VALUE), and a rescheduled punctuation is\u0026nbsp;\u003c/span\u003e\u003cspan\u003ere-queued only when its time moves forward.\u003c/span\u003e\u003c/div\u003e"
            }
          ],
          "value": "Kafka Streams derives its stream-time clock from record timestamps. PunctuationSchedule.next()\u00a0computed the next punctuation time as timestamp + (intervalsMissed + 1) * interval with no\u00a0overflow check. A record with a timestamp at or near Long.MAX_VALUE advances stream time to that\u00a0value, so the next stream-time punctuation overflows to a negative time. PunctuationQueue then\u00a0re-queues that time and loops on it indefinitely while holding a lock, stalling the StreamThread.\n\n\nImpact:\n\nA single record is enough. The affected StreamThread stops processing, and because the record\u00a0stays in the topic the hang returns on restart; an application whose partitions are all affected\u00a0becomes unresponsive. Only the Streams application is affected, not the brokers or the cluster.\u00a0Triggering it needs write access to a source topic whose topology uses stream-time punctuation,\u00a0and a broker that stores the record: brokers from Apache Kafka 4.0.0 reject such a timestamp by\u00a0default (log.message.timestamp.after.max.ms, one hour), so it is reachable only on older brokers\u00a0or where that bound has been relaxed.\n\n\nMitigation:\n\nUpgrade Kafka Streams to 4.2.2, 4.3.2, or 4.4.0. As defense in depth, keep\u00a0log.message.timestamp.after.max.ms bounded on source topics and restrict write access to them.\n\n\nResolution:\n\nFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0: the next punctuation time is computed with\u00a0overflow-checked arithmetic (clamped to Long.MAX_VALUE), and a rescheduled punctuation is\u00a0re-queued only when its time moves forward."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "low"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-190",
              "description": "CWE-190 Integer overflow or wraparound",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-835",
              "description": "CWE-835 Loop with unreachable exit condition (\u0027infinite loop\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T16:45:08.114Z",
        "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: Kafka Streams StreamThread hang from integer overflow in stream-time punctuation",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-111496",
    "datePublished": "2026-10-28T16:45:08.114Z",
    "dateReserved": "2026-10-16T09:55:02.432Z",
    "dateUpdated": "2026-10-28T20:06:55.726Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-10-28T20:06:57.172Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/10/28/13"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.kafka:kafka-streams",
          "packageURL": "pkg:maven/org.apache.kafka/kafka-streams",
          "product": "Apache Kafka",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "4.1.2",
              "status": "affected",
              "version": "0.10.0.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"
            }
          ]
        },
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.kafka:kafka-clients",
          "packageURL": "pkg:maven/org.apache.kafka/kafka-clients",
          "product": "Apache Kafka",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "4.1.2",
              "status": "affected",
              "version": "0.10.0.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": "Peyton Kennedy \u003cpkennedy@endor.ai\u003e"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "Bartlomiej Dmitruk \u003cbartek@striga.ai\u003e"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "Mike Read (GitHub: Michael-JRead)"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Matthias J. Sax \u003cmatthias@confluent.io\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Lucy Liu \u003clucliu@confluent.io\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003eSeveral Kafka deserialization paths read a size or count field from input data and use it directly\u0026nbsp;\u003cspan\u003eto allocate an array, collection, or byte buffer, with no check against the bytes actually\u0026nbsp;\u003c/span\u003e\u003cspan\u003eavailable. A small crafted input can therefore declare a very large size and force a\u0026nbsp;\u003c/span\u003e\u003cspan\u003emulti-gigabyte allocation. The affected paths are, in Kafka Streams, ProcessorRecordContext\u0026nbsp;\u003c/span\u003e\u003cspan\u003e(header count), ChangedDeserializer (varint value length), CombinedKeySchema (foreign-key length,\u0026nbsp;\u003c/span\u003e\u003cspan\u003ewhich could also produce a negative size), ProcessorMetadata (key length), and AssignmentInfo\u0026nbsp;\u003c/span\u003e\u003cspan\u003egroup-assignment decoding; and, in the clients library, ListDeserializer (used by ListSerde).\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eImpact:\u003c/div\u003e\u003cdiv\u003eAn attacker can trigger the oversized allocation and raise an OutOfMemoryError that crashes the\u0026nbsp;\u003cspan\u003eaffected consumer or Kafka Streams thread; the broker and the rest of the cluster are unaffected.\u0026nbsp;\u003c/span\u003e\u003cspan\u003eThe reachable surface depends on the path: writing a crafted record to a Streams application\u0027s\u0026nbsp;\u003c/span\u003e\u003cspan\u003einternal changelog or repartition topics, or committing crafted offset metadata to its consumer\u0026nbsp;\u003c/span\u003e\u003cspan\u003egroup (Streams internal paths); writing a crafted record to any topic that a consumer reads with\u0026nbsp;\u003c/span\u003e\u003cspan\u003eListSerde (ListDeserializer); or, as a member of a Streams consumer group, returning crafted\u0026nbsp;\u003c/span\u003e\u003cspan\u003eassignment data when elected leader (AssignmentInfo). Because a crafted record remains in its\u0026nbsp;\u003c/span\u003e\u003cspan\u003etopic, the error can recur on restart. The record size limit (max.message.bytes) does not help,\u0026nbsp;\u003c/span\u003e\u003cspan\u003ebecause the allocation is driven by a size field rather than by the input\u0027s length.\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. Where authorization is enabled, restrict write\u0026nbsp;\u003cspan\u003eaccess to each application\u0027s internal topics and consumer group to its own principal, and restrict\u0026nbsp;\u003c/span\u003e\u003cspan\u003ewho can produce to topics that are consumed with ListSerde.\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: these deserialization paths validate the declared size\u0026nbsp;\u003cspan\u003eagainst the remaining input before allocating and reject input that fails the check.\u003c/span\u003e\u003c/div\u003e"
            }
          ],
          "value": "Several Kafka deserialization paths read a size or count field from input data and use it directly\u00a0to allocate an array, collection, or byte buffer, with no check against the bytes actually\u00a0available. A small crafted input can therefore declare a very large size and force a\u00a0multi-gigabyte allocation. The affected paths are, in Kafka Streams, ProcessorRecordContext\u00a0(header count), ChangedDeserializer (varint value length), CombinedKeySchema (foreign-key length,\u00a0which could also produce a negative size), ProcessorMetadata (key length), and AssignmentInfo\u00a0group-assignment decoding; and, in the clients library, ListDeserializer (used by ListSerde).\n\n\nImpact:\n\nAn attacker can trigger the oversized allocation and raise an OutOfMemoryError that crashes the\u00a0affected consumer or Kafka Streams thread; the broker and the rest of the cluster are unaffected.\u00a0The reachable surface depends on the path: writing a crafted record to a Streams application\u0027s\u00a0internal changelog or repartition topics, or committing crafted offset metadata to its consumer\u00a0group (Streams internal paths); writing a crafted record to any topic that a consumer reads with\u00a0ListSerde (ListDeserializer); or, as a member of a Streams consumer group, returning crafted\u00a0assignment data when elected leader (AssignmentInfo). Because a crafted record remains in its\u00a0topic, the error can recur on restart. The record size limit (max.message.bytes) does not help,\u00a0because the allocation is driven by a size field rather than by the input\u0027s length.\n\n\nMitigation:\n\nUpgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Where authorization is enabled, restrict write\u00a0access to each application\u0027s internal topics and consumer group to its own principal, and restrict\u00a0who can produce to topics that are consumed with ListSerde.\n\n\nResolution:\n\nFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0: these deserialization paths validate the declared size\u00a0against the remaining input before allocating and reject input that fails the check."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "important"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "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"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-20",
              "description": "CWE-20 Improper input validation",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T16:45:25.163Z",
        "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: Denial of service in Kafka Streams and client deserializers via unbounded memory allocation",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-111551",
    "datePublished": "2026-10-28T16:45:25.163Z",
    "dateReserved": "2026-10-16T11:01:49.270Z",
    "dateUpdated": "2026-10-28T20:06:57.172Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "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.2.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": "Arthur Chan \u003carthur.chan@adalogics.com\u003e, Ada Logics and Anthropic Research"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "OpenAI Codex Security - Amy Burnett and Khai Tran"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Mickael Maison \u003cmickael.maison@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Manikumar Reddy \u003cmanikumar.reddy@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Chia-Ping Tsai \u003cchia7712@gmail.com\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003eAn authenticated Kafka principal with no authorization grants (not even ALTER_CONFIGS) can\u0026nbsp;\u003cspan\u003emake a broker read a file or an environment variable from the broker host and return its\u0026nbsp;\u003c/span\u003e\u003cspan\u003econtents. An IncrementalAlterConfigs (or AlterConfigs) request targeting a BROKER resource\u0026nbsp;\u003c/span\u003e\u003cspan\u003ereaches the broker\u0027s configuration validation before any authorization check is applied to\u0026nbsp;\u003c/span\u003e\u003cspan\u003ethat path. Validation resolves configuration variables such as ${file:/path:key} or ${env:VAR}\u0026nbsp;\u003c/span\u003e\u003cspan\u003eusing a ConfigProvider named in the request, and this resolution bypasses the\u0026nbsp;\u003c/span\u003e\u003cspan\u003eorg.apache.kafka.automatic.config.providers allowlist that was added as the mitigation for\u0026nbsp;\u003c/span\u003e\u003cspan\u003eCVE-2024-31141. An arbitrary ConfigProvider (for example FileConfigProvider or\u0026nbsp;\u003c/span\u003e\u003cspan\u003eEnvVarConfigProvider) is therefore instantiated and the referenced file or environment\u0026nbsp;\u003c/span\u003e\u003cspan\u003evariable is read, and a type-validation error returns the resolved content to the caller.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eImpact:\u003c/div\u003e\u003cdiv\u003eOn a cluster with an authorizer enabled, an authenticated principal with no authorization\u0026nbsp;\u003cspan\u003egrants can read the contents of files accessible to the broker process, and the broker\u0027s\u0026nbsp;\u003c/span\u003e\u003cspan\u003eenvironment variables, exposing credentials, keystores, or other secrets, defeating the\u0026nbsp;\u003c/span\u003e\u003cspan\u003eCVE-2024-31141 allowlist. The read is bounded by the broker process\u0027s file permissions. The\u0026nbsp;\u003c/span\u003e\u003cspan\u003ebrokers and the cluster remain available; the issue is disclosure of file and environment-\u0026nbsp;\u003c/span\u003e\u003cspan\u003evariable contents. Clusters with no authorizer configured are not affected in practice,\u0026nbsp;\u003c/span\u003e\u003cspan\u003ebecause every principal already holds ALTER_CONFIGS there.\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. As defense in depth, run brokers under a\u0026nbsp;\u003cspan\u003eleast-privileged operating-system account so that sensitive files are not readable by the\u0026nbsp;\u003c/span\u003e\u003cspan\u003ebroker process.\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: broker configuration changes are authorized\u0026nbsp;\u003cspan\u003e(ALTER_CONFIGS on the cluster) before the configuration is validated, and configuration-\u0026nbsp;\u003c/span\u003e\u003cspan\u003evariable resolution enforces the config-providers allowlist.\u003c/span\u003e\u003c/div\u003e"
            }
          ],
          "value": "An authenticated Kafka principal with no authorization grants (not even ALTER_CONFIGS) can\u00a0make a broker read a file or an environment variable from the broker host and return its\u00a0contents. An IncrementalAlterConfigs (or AlterConfigs) request targeting a BROKER resource\u00a0reaches the broker\u0027s configuration validation before any authorization check is applied to\u00a0that path. Validation resolves configuration variables such as ${file:/path:key} or ${env:VAR}\u00a0using a ConfigProvider named in the request, and this resolution bypasses the\u00a0org.apache.kafka.automatic.config.providers allowlist that was added as the mitigation for\u00a0CVE-2024-31141. An arbitrary ConfigProvider (for example FileConfigProvider or\u00a0EnvVarConfigProvider) is therefore instantiated and the referenced file or environment\u00a0variable is read, and a type-validation error returns the resolved content to the caller.\n\n\nImpact:\n\nOn a cluster with an authorizer enabled, an authenticated principal with no authorization\u00a0grants can read the contents of files accessible to the broker process, and the broker\u0027s\u00a0environment variables, exposing credentials, keystores, or other secrets, defeating the\u00a0CVE-2024-31141 allowlist. The read is bounded by the broker process\u0027s file permissions. The\u00a0brokers and the cluster remain available; the issue is disclosure of file and environment-\u00a0variable contents. Clusters with no authorizer configured are not affected in practice,\u00a0because every principal already holds ALTER_CONFIGS there.\n\n\nMitigation:\n\nUpgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. As defense in depth, run brokers under a\u00a0least-privileged operating-system account so that sensitive files are not readable by the\u00a0broker process.\n\n\nResolution:\n\nFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0: broker configuration changes are authorized\u00a0(ALTER_CONFIGS on the cluster) before the configuration is validated, and configuration-\u00a0variable resolution enforces the config-providers allowlist."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "important"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-862",
              "description": "CWE-862 Missing Authorization",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T16:46:38.006Z",
        "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: Unauthorized principal can read arbitrary broker files via IncrementalAlterConfigs",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-112375",
    "datePublished": "2026-10-28T16:46:38.006Z",
    "dateReserved": "2026-10-19T16:21:36.477Z",
    "dateUpdated": "2026-10-28T16:46:38.006Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-10-28T20:06:58.727Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/10/28/18"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.kafka:kafka_2.11",
          "packageURL": "pkg:maven/org.apache.kafka/kafka_2.11",
          "product": "Apache Kafka",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "2.5.0",
              "status": "affected",
              "version": "0.11.0.0",
              "versionType": "maven"
            }
          ]
        },
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.kafka:kafka_2.12",
          "packageURL": "pkg:maven/org.apache.kafka/kafka_2.12",
          "product": "Apache Kafka",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "4.0.0",
              "status": "affected",
              "version": "0.11.0.0",
              "versionType": "maven"
            }
          ]
        },
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.kafka:kafka_2.13",
          "packageURL": "pkg:maven/org.apache.kafka/kafka_2.13",
          "product": "Apache Kafka",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "4.1.2",
              "status": "affected",
              "version": "2.4.0",
              "versionType": "maven"
            },
            {
              "lessThanOrEqual": "4.2.1",
              "status": "affected",
              "version": "4.2.0",
              "versionType": "maven"
            },
            {
              "lessThanOrEqual": "4.3.1",
              "status": "affected",
              "version": "4.3.0",
              "versionType": "maven"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Peyton Kennedy \u003cpkennedy@endor.ai\u003e"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "Trung Nguyen \u003ctrungnh@cystack.net\u003e, CyStack"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "Bart\u0142omiej Dmitruk \u003cbartek@striga.ai\u003e, Striga"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "\uc784\uc131\ubbfc \u003cat_haemil@naver.com\u003e"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "Mike Read (GitHub: Michael-JRead)"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "Salman Aljardan \u003csalman1aljardan@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "Yuchao Zhang \u003cndaugoing@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "Yu Bao \u003cyubao@paypal.com\u003e, PayPal Cyber Security Team"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "Vamsi K \u003cxh081ix@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Srinivas Akhil Mallela \u003csrinivasakhil@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "Ashish Modi, OpenLogic by Perforce"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cbr\u003e\u003cdiv\u003eWhen a broker decodes a compressed record batch, the per-record decoder reads a declared body\u0026nbsp;\u003cspan\u003esize from the decompressed stream and allocates a buffer of that size before validating it\u0026nbsp;\u003c/span\u003e\u003cspan\u003eagainst the bytes available or any configured limit. The size is attacker-controlled, and the\u0026nbsp;\u003c/span\u003e\u003cspan\u003ebatch CRC does not constrain it, so a small (around 90-byte), CRC-valid compressed produce\u0026nbsp;\u003c/span\u003e\u003cspan\u003erequest can declare a body size of up to about 2 GiB and force the broker to attempt that\u0026nbsp;\u003c/span\u003e\u003cspan\u003eallocation, raising OutOfMemoryError. The record size limit (max.message.bytes), the request\u0026nbsp;\u003c/span\u003e\u003cspan\u003esize limit, and client/broker quotas bound only the compressed wire size, not the declared\u0026nbsp;\u003c/span\u003e\u003cspan\u003edecompressed size.\u003c/span\u003e\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eImpact:\u003c/div\u003e\u003cdiv\u003eAn authenticated principal with Write on a topic can crash broker request-handler threads\u0026nbsp;\u003cspan\u003e(reached when a batch\u0027s codec differs from the topic\u0027s compression.type and records are\u0026nbsp;\u003c/span\u003e\u003cspan\u003ere-encoded) and any consumer that fetches the record, denying service. On brokers started\u0026nbsp;\u003c/span\u003e\u003cspan\u003ewith -XX:+ExitOnOutOfMemoryError, a common hardening, a single crafted request terminates the\u0026nbsp;\u003c/span\u003e\u003cspan\u003ebroker JVM. More seriously, a\u0026nbsp;crafted record\u0026nbsp;\u0026nbsp;\u003c/span\u003e\u003cspan\u003eis accepted at ingest and written to disk; when the log-cleaner later reads it\u0026nbsp;\u003c/span\u003e\u003cspan\u003eon a compacted topic, the OutOfMemoryError (an Error, not an Exception) terminates the cleaner\u0026nbsp;\u003c/span\u003e\u003cspan\u003ethread, which is not restarted. With the default of a single cleaner thread, log compaction\u0026nbsp;\u003c/span\u003e\u003cspan\u003ethen stops for the entire broker, including the internal __consumer_offsets and\u0026nbsp;\u003c/span\u003e\u003cspan\u003e__transaction_state topics, and the condition persists across restarts until the offending\u0026nbsp;\u003c/span\u003e\u003cspan\u003erecord is removed. The impact is availability only; no data is disclosed or altered.\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, and set max.decompressed.message.bytes (at the\u0026nbsp;\u003cspan\u003ebroker and/or topic level) to a bounded value appropriate for your workload. Upgrading alone is\u0026nbsp;\u003c/span\u003e\u003cspan\u003enot sufficient: for backward compatibility this configuration defaults to an effectively\u0026nbsp;\u003c/span\u003e\u003cspan\u003eunlimited value (about 2 GiB), so a broker remains exposed until the limit is set. Choose a\u0026nbsp;\u003c/span\u003e\u003cspan\u003evalue at or slightly above the largest legitimate decompressed record your applications\u0026nbsp;\u003c/span\u003e\u003cspan\u003eproduce, and comfortably below the broker heap divided by the number of request-handler and\u0026nbsp;\u003c/span\u003e\u003cspan\u003ecleaner threads. Until you can upgrade and configure the limit, restrict Write access to\u0026nbsp;\u003c/span\u003e\u003cspan\u003etrusted producers; quotas and max.message.bytes do not mitigate this issue.\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: the broker validates a record\u0027s declared decompressed\u0026nbsp;\u003cspan\u003ebody size against max.decompressed.message.bytes before allocating, on the produce-validation,\u0026nbsp;\u003c/span\u003e\u003cspan\u003elog-compaction, and timestamp-lookup paths, and rejects oversized or negative sizes with\u0026nbsp;\u003c/span\u003e\u003cspan\u003eInvalidRecordException. Operators must set this configuration to a bounded value to be protected,\u0026nbsp;\u003c/span\u003e\u003cspan\u003eas its default is effectively unlimited.\u003c/span\u003e\u003c/div\u003e"
            }
          ],
          "value": "When a broker decodes a compressed record batch, the per-record decoder reads a declared body\u00a0size from the decompressed stream and allocates a buffer of that size before validating it\u00a0against the bytes available or any configured limit. The size is attacker-controlled, and the\u00a0batch CRC does not constrain it, so a small (around 90-byte), CRC-valid compressed produce\u00a0request can declare a body size of up to about 2 GiB and force the broker to attempt that\u00a0allocation, raising OutOfMemoryError. The record size limit (max.message.bytes), the request\u00a0size limit, and client/broker quotas bound only the compressed wire size, not the declared\u00a0decompressed size.\n\n\nImpact:\n\nAn authenticated principal with Write on a topic can crash broker request-handler threads\u00a0(reached when a batch\u0027s codec differs from the topic\u0027s compression.type and records are\u00a0re-encoded) and any consumer that fetches the record, denying service. On brokers started\u00a0with -XX:+ExitOnOutOfMemoryError, a common hardening, a single crafted request terminates the\u00a0broker JVM. More seriously, a\u00a0crafted record\u00a0\u00a0is accepted at ingest and written to disk; when the log-cleaner later reads it\u00a0on a compacted topic, the OutOfMemoryError (an Error, not an Exception) terminates the cleaner\u00a0thread, which is not restarted. With the default of a single cleaner thread, log compaction\u00a0then stops for the entire broker, including the internal __consumer_offsets and\u00a0__transaction_state topics, and the condition persists across restarts until the offending\u00a0record is removed. The impact is availability only; no data is disclosed or altered.\n\n\nMitigation:\n\nUpgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0, and set max.decompressed.message.bytes (at the\u00a0broker and/or topic level) to a bounded value appropriate for your workload. Upgrading alone is\u00a0not sufficient: for backward compatibility this configuration defaults to an effectively\u00a0unlimited value (about 2 GiB), so a broker remains exposed until the limit is set. Choose a\u00a0value at or slightly above the largest legitimate decompressed record your applications\u00a0produce, and comfortably below the broker heap divided by the number of request-handler and\u00a0cleaner threads. Until you can upgrade and configure the limit, restrict Write access to\u00a0trusted producers; quotas and max.message.bytes do not mitigate this issue.\n\n\nResolution:\n\nFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0: the broker validates a record\u0027s declared decompressed\u00a0body size against max.decompressed.message.bytes before allocating, on the produce-validation,\u00a0log-compaction, and timestamp-lookup paths, and rejects oversized or negative sizes with\u00a0InvalidRecordException. Operators must set this configuration to a bounded value to be protected,\u00a0as its default is effectively unlimited."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "important"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "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"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-1284",
              "description": "CWE-1284 Improper validation of specified quantity in input",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-29T13:48:26.738Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://kafka.apache.org/cve-list"
        },
        {
          "tags": [
            "mailing-list"
          ],
          "url": "https://lists.apache.org/thread/hdy56hrd1h9btf30jb1noswsx32l17dq"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Apache Kafka: Denial of service via unbounded memory allocation when decoding compressed record batches",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-114349",
    "datePublished": "2026-10-28T16:46:54.920Z",
    "dateReserved": "2026-10-21T08:14:55.090Z",
    "dateUpdated": "2026-10-29T13:48:26.738Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2026-10-28T20:07:00.157Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/10/28/15"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "org.apache.kafka:connect-runtime",
          "packageURL": "pkg:maven/org.apache.kafka/connect-runtime",
          "product": "Apache Kafka",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "4.2.2",
              "status": "affected",
              "version": "2.4.0",
              "versionType": "semver"
            },
            {
              "lessThan": "4.3.2",
              "status": "affected",
              "version": "4.3.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Bart\u0142omiej Dmitruk \u003cbartek@striga.ai\u003e, Striga"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Mickael Maison \u003cmickael.maison@gmail.com\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cdiv\u003eApache Kafka Connect contains an authentication bypass vulnerability affecting the admin REST API when admin.listeners is configured with a separate listener from the main listeners property.\u003c/div\u003e\u003cdiv\u003eWhen operators isolate the admin REST API by explicitly configuring the \"admin.listeners\" property, REST extensions specified via rest.extension.classes (such as BasicAuthSecurityRestExtension) are not registered or applied to the admin resource configuration.\u003cbr\u003e\u003cbr\u003eWhile the primary REST API listener (configured via listeners) enforces configured authentication and authorization filters, endpoints mounted under the separate admin listener (/admin/loggers) fail to inherit or instantiate these extension filters. As a result, the admin logger endpoint accepts unauthenticated read and write requests even when security extensions are active on the main listener.\u003c/div\u003e\u003cdiv\u003eImpact:\u003c/div\u003e\u003cdiv\u003eAn unauthenticated attacker with network access to the admin listener can:\u003cbr\u003e\u003cbr\u003e  1. Read the complete set of logger names and levels, disclosing loaded class names and which security extensions are in use.\u003cbr\u003e  2. Write logger levels, including with scope=cluster which propagates the change to all workers in the Connect cluster. This can be used to suppress\u003cbr\u003e     logging (setting root to OFF) or generate excessive log output (setting root to TRACE), potentially impacting availability and observability.\u003c/div\u003e\u003cdiv\u003eMitigation:\u003cbr\u003e\u003cbr\u003e  Users who cannot upgrade immediately can remove the admin.listeners configuration (or leave it unset). When unset, admin resources share the regular listener and inherit its security extensions.\u003c/div\u003e\u003cdiv\u003eResolution:\u003c/div\u003e\u003cdiv\u003e\u003cbr\u003e\u003cdiv\u003eFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0, we make sure the\u0026nbsp;REST extensions specified via \"rest.extension.classes\" will also apply to\u0026nbsp;\"admin.listeners\".\u003c/div\u003e\u003c/div\u003e"
            }
          ],
          "value": "Apache Kafka Connect contains an authentication bypass vulnerability affecting the admin REST API when admin.listeners is configured with a separate listener from the main listeners property.\n\nWhen operators isolate the admin REST API by explicitly configuring the \"admin.listeners\" property, REST extensions specified via rest.extension.classes (such as BasicAuthSecurityRestExtension) are not registered or applied to the admin resource configuration.\n\nWhile the primary REST API listener (configured via listeners) enforces configured authentication and authorization filters, endpoints mounted under the separate admin listener (/admin/loggers) fail to inherit or instantiate these extension filters. As a result, the admin logger endpoint accepts unauthenticated read and write requests even when security extensions are active on the main listener.\n\nImpact:\n\nAn unauthenticated attacker with network access to the admin listener can:\n\n  1. Read the complete set of logger names and levels, disclosing loaded class names and which security extensions are in use.\n  2. Write logger levels, including with scope=cluster which propagates the change to all workers in the Connect cluster. This can be used to suppress\n     logging (setting root to OFF) or generate excessive log output (setting root to TRACE), potentially impacting availability and observability.\n\nMitigation:\n\n  Users who cannot upgrade immediately can remove the admin.listeners configuration (or leave it unset). When unset, admin resources share the regular listener and inherit its security extensions.\n\nResolution:\n\n\nFrom Apache Kafka 4.2.2, 4.3.2, and 4.4.0, we make sure the\u00a0REST extensions specified via \"rest.extension.classes\" will also apply to\u00a0\"admin.listeners\"."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "low"
            },
            "type": "Textual description of severity"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T16:45:36.440Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://kafka.apache.org/cve-list"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Apache Kafka: Connect Admin REST API Authentication Bypass via Unapplied REST Extensions",
      "x_generator": {
        "engine": "Vulnogram 1.0.3"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-115644",
    "datePublished": "2026-10-28T16:45:36.440Z",
    "dateReserved": "2026-10-23T03:48:31.242Z",
    "dateUpdated": "2026-10-28T20:07:00.157Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}