Skip to content
VulniPulse
Sign in
Highest advisory severityMedium 2 vendors · 2 advisories

CVE-2026-111496

Denial of Service via integer overflow in timestamp calculation

CVE-2026-111496: Denial of Service via integer overflow in timestamp calculation. Not in the CISA KEV catalog. Medium advisory severity (CVSS 5.3, Red Hat).

Compare the source-linked records below. Ratings and product/version details belong to each advisory; they are not a single CVE-wide score or proof that every listed product is affected. How VulniPulse collects and checks evidence.

NVD detail CVE.org

Get an email when Apache publishes the next one.

VulniPulse checks Apache's security advisories around the clock and emails you new ones with the severity, the fixed version and the vendor's link. First month free, then US$15/month; we email you before the first charge.

Start your free month

CVE-2026-111496 key facts

CISA KEV
Not listed (catalog checked )
Highest advisory severity
Medium
CVSS base score
5.3 (Red Hat)
Vendor advisories
2 from Apache, Red Hat
VulniPulse record
Published · Updated

Scores, vectors, weaknesses and fixed releases are quoted from vendor advisories that cover only CVE-2026-111496; bulletin-wide values are not repeated here.

Is CVE-2026-111496 exploited?

No exploitation is reported in the sources VulniPulse tracks: CVE-2026-111496 is not in the CISA KEV catalog (checked ) and no tracked advisory for it reports exploitation. That is not proof the vulnerability cannot be exploited.

How do I fix CVE-2026-111496?

  • Mitigation: Upgrade Kafka Streams to 4.2.2, 4.3.2, or 4.4.0. (Apache)
  • To reduce exposure to this issue without modifying application binaries: 1. Restrict write access to source topics: Enforce Kafka Access Control Lists (ACLs) to restrict write permissions on topics consumed by Kafka Streams topologies that rely on stream-time punctuation, ensuring only authorized producers can publish records. 2. Enforce timestamp boundaries on brokers and topics: Configure timestamp limits on Kafka source topics to reject messages with extreme future timestamps. Apply the topic configuration dynamically using administrative scripts: kafka-configs.sh --bootstrap-server : --entity-type topics --entity-name --alter --add-config log.message.timestamp.after.max.ms=3600000 Alternatively, enforce `log.message.timestamp.after.max.ms` cluster-wide in the broker configuration file. Caveats: Restricting message timestamp boundaries causes brokers to reject records outside the configured time delta, which could disrupt producers with unsynchronized system clocks. If applying changes cluster-wide at the broker configuration level, a service restart or configuration reload of Kafka brokers is required, which may temporarily disrupt active client connections. (Red Hat)

Vendor advisory comparison

Apache

1 advisory
  • Advisory severityUnrated

    Advisory [CVE-2026-111496] Apache Kafka: Kafka Streams derives its stream-time clock from record timestamps

    CVE-2026-111496Source published Source updated

    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…

    Related products — impact not confirmed
    • Apache Kafka
    Source-reported affected versions
    • Apache Kafka 1.1.0 through 4.1.2
    • Apache Kafka 4.2.0 through 4.2.1
    • Apache Kafka 4.3.0 through 4.3.1
    Source-reported fixed versions
    No fixed-version detail extracted. This does not mean no fix exists.
    Mitigation guidance
    • Mitigation: Upgrade Kafka Streams to 4.2.2, 4.3.2, or 4.4.0.
    Workarounds
    • As defense in depth, keep log.message.timestamp.after.max.ms bounded on source topics and restrict write access to them.
    Full advisory and evidenceOpen source bulletin

Red Hat

1 advisory
  • Advisory severityMedium5.3

    Medium [CVE-2026-111496] Denial of Service via integer overflow in timestamp calculation

    CVE-2026-111496Source published Source updated

    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…

    Affected products in this advisory
    • Red Hat build of Quarkus
    • Red Hat Fuse 7
    • streams for Apache Kafka 3
    Source-reported affected versions
    Affected-version details not available in this record.
    Source-reported fixed versions
    No fixed-version detail extracted. This does not mean no fix exists.
    Mitigation guidance
    • To reduce exposure to this issue without modifying application binaries: 1. Restrict write access to source topics: Enforce Kafka Access Control Lists (ACLs) to restrict write permissions on topics consumed by Kafka Streams topologies that rely on stream-time punctuation, ensuring only authorized producers can publish records. 2. Enforce timestamp boundaries on brokers and topics: Configure timestamp limits on Kafka source topics to reject messages with extreme future timestamps. Apply the topic configuration dynamically using administrative scripts: kafka-configs.sh --bootstrap-server <broker-host>:<port> --entity-type topics --entity-name <topic-name> --alter --add-config log.message.timestamp.after.max.ms=3600000 Alternatively, enforce `log.message.timestamp.after.max.ms` cluster-wide in the broker configuration file. Caveats: Restricting message timestamp boundaries causes brokers to reject records outside the configured time delta, which could disrupt producers with unsynchronized system clocks. If applying changes cluster-wide at the broker configuration level, a service restart or configuration reload of Kafka brokers is required, which may temporarily disrupt active client connections.
    Full advisory and evidenceOpen source bulletin

More Apache advisories

All Apache advisories

Follow CVE-2026-111496 in the free weekly digest

Every Monday: whether it was added to CISA KEV, reported exploited, got a fix or changed severity, plus the week's critical and high advisories.

Free, no account. Confirm by email; unsubscribe in one click. Choose vendors and severity

Browse the latest tracked CVEs or the CVEs listed in CISA KEV.

Android app · Google Play

Get alerts for new CVEs on your phone.

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

Matching phone alertsOptional email delivery
Get CVE alertsSee app features