Vulnerability-Lookup

GHSA-F6X4-CQ8Q-X8CQ

Vulnerability from github – Published: 2026-10-28 18:32 – Updated: 2026-10-28 21:31

Details

Impact:

A single record is enough. The affected StreamThread stops processing, and because the record stays in the topic the hang returns on restart; an application whose partitions are all affected becomes unresponsive. Only the Streams application is affected, not the brokers or the cluster. Triggering it needs write access to a source topic whose topology uses stream-time punctuation, and a broker that stores the record: brokers from Apache Kafka 4.0.0 reject such a timestamp by default (log.message.timestamp.after.max.ms, one hour), so it is reachable only on older brokers or where that bound has been relaxed.

Mitigation:

Upgrade Kafka Streams to 4.2.2, 4.3.2, or 4.4.0. As defense in depth, keep log.message.timestamp.after.max.ms bounded on source topics and restrict write access to them.

Resolution:

From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: the next punctuation time is computed with overflow-checked arithmetic (clamped to Long.MAX_VALUE), and a rescheduled punctuation is re-queued only when its time moves forward.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-111496"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-28T17:17:39Z",
    "severity": null
  },
  "details": "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.",
  "id": "GHSA-f6x4-cq8q-x8cq",
  "modified": "2026-10-28T21:31:14Z",
  "published": "2026-10-28T18:32:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-111496"
    },
    {
      "type": "WEB",
      "url": "https://kafka.apache.org/cve-list"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/10/28/14"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

CVE-2026-111496 (GCVE-0-2026-111496)

Vulnerability from cvelistv5 – Published: 2026-10-28 16:45 – Updated: 2026-10-28 20:06

Title

Apache Kafka: Kafka Streams StreamThread hang from integer overflow in stream-time punctuation

Summary

Kafka Streams derives its stream-time clock from record timestamps. PunctuationSchedule.next() computed the next punctuation time as timestamp + (intervalsMissed + 1) * interval with no overflow check. A record with a timestamp at or near Long.MAX_VALUE advances stream time to that value, so the next stream-time punctuation overflows to a negative time. PunctuationQueue then re-queues that time and loops on it indefinitely while holding a lock, stalling the StreamThread. Impact: A single record is enough. The affected StreamThread stops processing, and because the record stays in the topic the hang returns on restart; an application whose partitions are all affected becomes unresponsive. Only the Streams application is affected, not the brokers or the cluster. Triggering it needs write access to a source topic whose topology uses stream-time punctuation, and a broker that stores the record: brokers from Apache Kafka 4.0.0 reject such a timestamp by default (log.message.timestamp.after.max.ms, one hour), so it is reachable only on older brokers or where that bound has been relaxed. Mitigation: Upgrade Kafka Streams to 4.2.2, 4.3.2, or 4.4.0. As defense in depth, keep log.message.timestamp.after.max.ms bounded on source topics and restrict write access to them. Resolution: From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: the next punctuation time is computed with overflow-checked arithmetic (clamped to Long.MAX_VALUE), and a rescheduled punctuation is re-queued only when its time moves forward.

Severity

No CVSS data available.

CWE

CWE-190 - Integer overflow or wraparound
CWE-835 - Loop with unreachable exit condition ('infinite loop')

Assigner

apache CNA under the mitre root

CNA scorecard B 76/100 over 1090 records in the last 180 days details

References

2 references

URL	Tags
https://kafka.apache.org/cve-list	vendor-advisory
http://www.openwall.com/lists/oss-security/2026/1…

Impacted products

1 product

Vendor	Product	Version
Apache Software Foundation	Apache Kafka	Affected: 1.1.0 , ≤ 4.1.2 (semver) Affected: 4.2.0 , ≤ 4.2.1 (semver) Affected: 4.3.0 , ≤ 4.3.1 (semver)

Credits

Mike Read (GitHub: Michael-JRead) Matthias J. Sax <matthias@confluent.io>

Show details on NVD website

JSON

To clipboard

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

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted