Apache Kafka
Monthly
Memory exhaustion in the Apache Kafka broker lets an authenticated principal holding Write permission on a topic submit a roughly 90-byte, CRC-valid compressed produce request that declares a decompressed record body of up to about 2 GiB, forcing the broker to attempt that allocation and raise OutOfMemoryError. The flaw is reachable on the produce-validation path when a batch's codec differs from the topic's configured compression.type and records are re-encoded, and a crafted record accepted at ingest can also kill the single default log-cleaner thread when it is later read on a compacted topic, stopping compaction broker-wide (including __consumer_offsets and __transaction_state) across restarts until the record is removed; because OutOfMemoryError is an Error rather than an Exception, the cleaner thread is not restarted. Impact is availability only - no data disclosure or modification - and no public exploit code has been identified at time of analysis. Critically, patching alone does not close exposure: the new max.decompressed.message.bytes setting defaults to an effectively unlimited (~2 GiB) value for backward compatibility, so operators must both upgrade and configure a bounded limit.
Apache Kafka brokers that have an authorizer enabled will read a file or environment variable from the broker host and return its contents to any authenticated principal, including one holding no ACL grants at all - not even ALTER_CONFIGS. The flaw is a missing-authorization ordering problem (CWE-862): an IncrementalAlterConfigs or AlterConfigs request aimed at a BROKER resource reaches configuration validation, which resolves ${file:/path:key} or ${env:VAR} variables through a ConfigProvider instantiated from the request, before any authorization check is applied, and a type-validation error reflects the resolved secret back to the caller. This defeats the org.apache.kafka.automatic.config.providers allowlist introduced for CVE-2024-31141, but the read is bounded by the broker process's OS file permissions and impacts only confidentiality, not cluster availability or data integrity; there is no public exploit identified at time of analysis and the vendor-supplied fix set is Kafka 4.2.2, 4.3.2, and 4.4.0.
Network-reachable, unauthenticated deserialization flaws in Apache Kafka’s clients library and Kafka Streams can force multi-gigabyte allocations and crash the consuming application or Streams thread with an OutOfMemoryError; the broker and other cluster components are unaffected. Versions 0.10.0.0 through 4.1.2, 4.2.0 through 4.2.1, and 4.3.0 through 4.3.1 are affected across the Kafka Streams paths (ProcessorRecordContext, ChangedDeserializer, CombinedKeySchema, ProcessorMetadata, AssignmentInfo) and the clients ListDeserializer used by ListSerde. Exploitation requires the ability to place crafted data on the relevant deserialization path-writing to internal changelog or repartition topics, committing offset metadata, supplying crafted group-assignment data as Streams group leader, or producing to a topic consumed with ListSerde; Kafka ACLs block many of these paths when authorization is enabled, no CISA KEV entry is reported in the supplied data, no EPSS score is available, and no public exploit identified at time of analysis.
Unauthenticated remote attackers can exhaust broker heap and trigger process-wide GC stalls on Apache Kafka by declaring an enormous tagged-field count in the flexible request header, which generated readers accept without checking it against the remaining buffer. The affected lines are 2.4.0 through 4.1.2, 4.2.0 through 4.2.1, and 4.3.0 through 4.3.1; because each declared field costs one RawTaggedField allocation and can be encoded in as little as two bytes, a request of a few tens of megabytes can force roughly 20 million allocations, and this happens on the network thread before authentication, request dispatch and request-time quota accounting, so APIs such as ApiVersions v3 are reachable pre-authentication. The outcome is availability-only denial of service; no public exploit identified at time of analysis, and vendor fixes are available in 4.2.2, 4.3.2 and 4.4.0, making this a this-week priority rather than an emergency.
Heap exhaustion in Apache Kafka allows remote attackers to crash brokers by sending requests that declare an array element count far exceeding the actual buffer contents, causing generated protocol readers to pre-allocate an ImplicitLinkedHashCollection with capacity 2*count+1 before reading any elements. Because parsing happens before authorization, listeners without authentication such as PLAINTEXT are exposed to unauthenticated attackers, while authenticated listeners require valid credentials but no specific ACL; the reporter demonstrated three concurrent ~90 MB ProduceRequest v3 connections exhausting a 1 GB heap (~8x amplification). Affected releases are prior to 4.2.2, 4.3.2, and 4.4.0, and no public exploit code has been identified at time of analysis.
Apache Kafka brokers that run SASL/OAUTHBEARER with the default DefaultJwtValidator and leave sasl.oauthbearer.jwks.endpoint.url unset silently fall back to a validator that performs no JWT signature, algorithm, or issuer checks, allowing unauthenticated remote attackers with listener reachability to forge tokens for arbitrary principals, including configured superusers, and gain full cluster access. The flaw is a residual of CVE-2026-33557 and only affects brokers in this specific OAUTHBEARER-without-JWKS-URL configuration with no custom verification key resolver; brokers that set the JWKS URL verify signatures and are not affected. No CISA KEV listing or public exploit code is identified in the available data, no public exploit identified at time of analysis, and no EPSS score is provided.
Apache Kafka 4.1.0 and 4.1.1 accept forged JWT tokens without signature validation, allowing remote unauthenticated attackers to authenticate as any user and gain unauthorized access to Kafka resources. The default SASL/OAUTHBEARER validator (DefaultJwtValidator) fails to verify token signatures, issuers, or audiences, enabling complete authentication bypass. CVSS 9.1 (Critical) with network vector and no privileges required. SSVC indicates the vulnerability is automatable with partial technical impact. No active exploitation confirmed at time of analysis, but the attack requires minimal sophistication and could be scripted trivially given the token acceptance behavior.
Kafka Connect workers leak plaintext secrets through the REST API's /connector-plugins/{connector-type}/config/validate endpoint, which resolves Configuration Provider variables and returns the resolved values in its response, so anyone who can reach the endpoint can read credentials that were meant to stay hidden until runtime. Deployments are affected from Kafka 2.4.0 up to but not including 4.2.2, and from 4.3.0 up to but not including 4.3.2; the vendor fixed the behaviour in 4.2.2, 4.3.2 and 4.4.0. The request path requires no credentials (the assessed CVSS vector is AV:N/AC:L/PR:N/UI:N, and the Connect REST API has no authentication enabled by default), though disclosure is bounded to secrets that the Configuration Providers actually configured on that worker can resolve; no public exploit code, CISA KEV listing, or EPSS score was identified at time of analysis.
Authentication bypass in Apache Kafka Connect's isolated admin REST API allows unauthenticated network attackers to read and write logger settings, including cluster-wide changes via scope=cluster, when admin.listeners is explicitly configured as a separate listener and REST security extensions such as BasicAuthSecurityRestExtension are used. The issue affects Apache Kafka 2.4.0 through versions before 4.2.2 and 4.3.0 through versions before 4.3.2, with fixes released in 4.2.2, 4.3.2, and 4.4.0; deployments that leave admin.listeners unset are not affected. No public exploit was identified at time of analysis, and the assessed severity is moderate with limited confidentiality, integrity, and availability impact confined to the /admin/loggers endpoint.
Kafka Streams can be stalled indefinitely by a single record whose timestamp is at or near Long.MAX_VALUE, causing an integer overflow that moves the next stream-time punctuation to a negative time and makes PunctuationQueue re-queue it in a lock-holding loop until the StreamThread stops. EUVD lists Apache Kafka 1.1.0 through 4.1.2, 4.2.0 through 4.2.1, and 4.3.0 through 4.3.1 as affected; only the Streams application is impacted, not the brokers or cluster, and the hang returns on restart while the record stays in the topic. Exploitation requires producer write access to a source topic feeding a stream-time-punctuation topology and a broker that stores the extreme timestamp-brokers from 4.0.0 reject timestamps more than one hour in the future by default-so reachability is limited to older brokers or relaxed bounds; the assessed vector is CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H, no EPSS score is present, no KEV entry is listed, and no public exploit identified at time of analysis, with priority monitor.
Apache Kafka brokers can be driven into heap exhaustion by any authenticated client because the PushTelemetry (KIP-714) path limits the compressed request size but not the decompressed output. A tiny, highly compressible payload can expand to hundreds of megabytes, and repeated or concurrent requests can trigger OutOfMemoryError, degrade brokers, and affect cluster availability; PushTelemetry is not ACL-gated. No public exploit was identified at time of analysis, and vendor fixes are available in Apache Kafka 4.2.2, 4.3.1, and 4.4.0.
Apache Kafka brokers that authenticate clients via SASL/OAUTHBEARER using the bundled JWKS-backed validator can accept a validly-signed JWT that was minted by a different issuer, or that omits the aud claim, because the issuer check only runs when sasl.oauthbearer.expected.issuer is set and an audience claim is only required when sasl.oauthbearer.expected.audience is set - both default to unset. The practical exposure is concentrated in deployments whose JWKS endpoint publishes signing keys for more than one issuer (multi-tenant IdP, aggregated/shared JWKS, shared signing keys), where such a token may authenticate a client, potentially as a higher-privileged principal; single-issuer deployments that control the iss claim and issue audience-scoped tokens are far less exposed. The JWT signature trust anchor is still enforced in every case, no public exploit code has been identified at time of analysis, and the flaw is not listed in CISA KEV; an analyst-derived CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N places severity at the high end while acknowledging the configuration and token-availability preconditions.
Denial of service in Apache Kafka's KRaft controller affects releases 2.8.0 through 4.2.1 and 4.3.0 through 4.3.1, where a remote authenticated principal holding CLUSTER_ACTION authorization can terminate the controller process by sending a crafted FetchSnapshotRequest whose topics array is empty or whose single topic carries no partitions. The impact is availability-only: the controller dies, taking cluster metadata management down with it, but no data is exposed or altered (assessed CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). CLUSTER_ACTION is a cluster-level permission normally held by broker/controller identities rather than ordinary producers or consumers, so the realistic attacker is a compromised or malicious broker or a holder of inter-broker credentials. No public exploit has been identified at time of analysis, no CISA KEV entry exists, and the vuln.today decision label is 'monitor'.
Improper authorization in Apache Kafka 4.0.0-4.3.0 arises from a discrepancy between the documented ACL requirement and the actual runtime behavior of the CONSUMER_GROUP_DESCRIBE (API key 69) endpoint. The API checks for DESCRIBE permission on the GROUP resource at runtime, while official Kafka documentation and KIP-848 specify READ as the required operation - causing administrators who followed the documentation to configure ACLs that either over-grant READ access to users who should only observe group metadata, or under-restrict DESCRIBE-only users who can nonetheless access sensitive consumer group state. No public exploit has been identified at time of analysis, and EPSS exploitation probability is 0.02% (4th percentile), indicating negligible opportunistic exploitation risk.
Apache Kafka's NetworkClient component logs entire request and response payloads at DEBUG level, exposing sensitive authentication credentials, delegation tokens, and configuration data in plaintext logs. This affects Kafka versions 0.11.0 through 3.9.1 and 4.0.0 across the broker and client libraries. While DEBUG logging is not enabled by default (INFO is the standard), organizations that enable DEBUG logging for troubleshooting inadvertently create persistent records of authentication material and secrets that can be harvested by local log readers or accessed via log aggregation systems. CVSS 5.3 reflects low network attack surface (requires prior DEBUG enablement), but SSVC rates this as automatable with partial technical impact, suitable for prioritization in environments using centralized logging.
Memory exhaustion in the Apache Kafka broker lets an authenticated principal holding Write permission on a topic submit a roughly 90-byte, CRC-valid compressed produce request that declares a decompressed record body of up to about 2 GiB, forcing the broker to attempt that allocation and raise OutOfMemoryError. The flaw is reachable on the produce-validation path when a batch's codec differs from the topic's configured compression.type and records are re-encoded, and a crafted record accepted at ingest can also kill the single default log-cleaner thread when it is later read on a compacted topic, stopping compaction broker-wide (including __consumer_offsets and __transaction_state) across restarts until the record is removed; because OutOfMemoryError is an Error rather than an Exception, the cleaner thread is not restarted. Impact is availability only - no data disclosure or modification - and no public exploit code has been identified at time of analysis. Critically, patching alone does not close exposure: the new max.decompressed.message.bytes setting defaults to an effectively unlimited (~2 GiB) value for backward compatibility, so operators must both upgrade and configure a bounded limit.
Apache Kafka brokers that have an authorizer enabled will read a file or environment variable from the broker host and return its contents to any authenticated principal, including one holding no ACL grants at all - not even ALTER_CONFIGS. The flaw is a missing-authorization ordering problem (CWE-862): an IncrementalAlterConfigs or AlterConfigs request aimed at a BROKER resource reaches configuration validation, which resolves ${file:/path:key} or ${env:VAR} variables through a ConfigProvider instantiated from the request, before any authorization check is applied, and a type-validation error reflects the resolved secret back to the caller. This defeats the org.apache.kafka.automatic.config.providers allowlist introduced for CVE-2024-31141, but the read is bounded by the broker process's OS file permissions and impacts only confidentiality, not cluster availability or data integrity; there is no public exploit identified at time of analysis and the vendor-supplied fix set is Kafka 4.2.2, 4.3.2, and 4.4.0.
Network-reachable, unauthenticated deserialization flaws in Apache Kafka’s clients library and Kafka Streams can force multi-gigabyte allocations and crash the consuming application or Streams thread with an OutOfMemoryError; the broker and other cluster components are unaffected. Versions 0.10.0.0 through 4.1.2, 4.2.0 through 4.2.1, and 4.3.0 through 4.3.1 are affected across the Kafka Streams paths (ProcessorRecordContext, ChangedDeserializer, CombinedKeySchema, ProcessorMetadata, AssignmentInfo) and the clients ListDeserializer used by ListSerde. Exploitation requires the ability to place crafted data on the relevant deserialization path-writing to internal changelog or repartition topics, committing offset metadata, supplying crafted group-assignment data as Streams group leader, or producing to a topic consumed with ListSerde; Kafka ACLs block many of these paths when authorization is enabled, no CISA KEV entry is reported in the supplied data, no EPSS score is available, and no public exploit identified at time of analysis.
Unauthenticated remote attackers can exhaust broker heap and trigger process-wide GC stalls on Apache Kafka by declaring an enormous tagged-field count in the flexible request header, which generated readers accept without checking it against the remaining buffer. The affected lines are 2.4.0 through 4.1.2, 4.2.0 through 4.2.1, and 4.3.0 through 4.3.1; because each declared field costs one RawTaggedField allocation and can be encoded in as little as two bytes, a request of a few tens of megabytes can force roughly 20 million allocations, and this happens on the network thread before authentication, request dispatch and request-time quota accounting, so APIs such as ApiVersions v3 are reachable pre-authentication. The outcome is availability-only denial of service; no public exploit identified at time of analysis, and vendor fixes are available in 4.2.2, 4.3.2 and 4.4.0, making this a this-week priority rather than an emergency.
Heap exhaustion in Apache Kafka allows remote attackers to crash brokers by sending requests that declare an array element count far exceeding the actual buffer contents, causing generated protocol readers to pre-allocate an ImplicitLinkedHashCollection with capacity 2*count+1 before reading any elements. Because parsing happens before authorization, listeners without authentication such as PLAINTEXT are exposed to unauthenticated attackers, while authenticated listeners require valid credentials but no specific ACL; the reporter demonstrated three concurrent ~90 MB ProduceRequest v3 connections exhausting a 1 GB heap (~8x amplification). Affected releases are prior to 4.2.2, 4.3.2, and 4.4.0, and no public exploit code has been identified at time of analysis.
Apache Kafka brokers that run SASL/OAUTHBEARER with the default DefaultJwtValidator and leave sasl.oauthbearer.jwks.endpoint.url unset silently fall back to a validator that performs no JWT signature, algorithm, or issuer checks, allowing unauthenticated remote attackers with listener reachability to forge tokens for arbitrary principals, including configured superusers, and gain full cluster access. The flaw is a residual of CVE-2026-33557 and only affects brokers in this specific OAUTHBEARER-without-JWKS-URL configuration with no custom verification key resolver; brokers that set the JWKS URL verify signatures and are not affected. No CISA KEV listing or public exploit code is identified in the available data, no public exploit identified at time of analysis, and no EPSS score is provided.
Apache Kafka 4.1.0 and 4.1.1 accept forged JWT tokens without signature validation, allowing remote unauthenticated attackers to authenticate as any user and gain unauthorized access to Kafka resources. The default SASL/OAUTHBEARER validator (DefaultJwtValidator) fails to verify token signatures, issuers, or audiences, enabling complete authentication bypass. CVSS 9.1 (Critical) with network vector and no privileges required. SSVC indicates the vulnerability is automatable with partial technical impact. No active exploitation confirmed at time of analysis, but the attack requires minimal sophistication and could be scripted trivially given the token acceptance behavior.
Kafka Connect workers leak plaintext secrets through the REST API's /connector-plugins/{connector-type}/config/validate endpoint, which resolves Configuration Provider variables and returns the resolved values in its response, so anyone who can reach the endpoint can read credentials that were meant to stay hidden until runtime. Deployments are affected from Kafka 2.4.0 up to but not including 4.2.2, and from 4.3.0 up to but not including 4.3.2; the vendor fixed the behaviour in 4.2.2, 4.3.2 and 4.4.0. The request path requires no credentials (the assessed CVSS vector is AV:N/AC:L/PR:N/UI:N, and the Connect REST API has no authentication enabled by default), though disclosure is bounded to secrets that the Configuration Providers actually configured on that worker can resolve; no public exploit code, CISA KEV listing, or EPSS score was identified at time of analysis.
Authentication bypass in Apache Kafka Connect's isolated admin REST API allows unauthenticated network attackers to read and write logger settings, including cluster-wide changes via scope=cluster, when admin.listeners is explicitly configured as a separate listener and REST security extensions such as BasicAuthSecurityRestExtension are used. The issue affects Apache Kafka 2.4.0 through versions before 4.2.2 and 4.3.0 through versions before 4.3.2, with fixes released in 4.2.2, 4.3.2, and 4.4.0; deployments that leave admin.listeners unset are not affected. No public exploit was identified at time of analysis, and the assessed severity is moderate with limited confidentiality, integrity, and availability impact confined to the /admin/loggers endpoint.
Kafka Streams can be stalled indefinitely by a single record whose timestamp is at or near Long.MAX_VALUE, causing an integer overflow that moves the next stream-time punctuation to a negative time and makes PunctuationQueue re-queue it in a lock-holding loop until the StreamThread stops. EUVD lists Apache Kafka 1.1.0 through 4.1.2, 4.2.0 through 4.2.1, and 4.3.0 through 4.3.1 as affected; only the Streams application is impacted, not the brokers or cluster, and the hang returns on restart while the record stays in the topic. Exploitation requires producer write access to a source topic feeding a stream-time-punctuation topology and a broker that stores the extreme timestamp-brokers from 4.0.0 reject timestamps more than one hour in the future by default-so reachability is limited to older brokers or relaxed bounds; the assessed vector is CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H, no EPSS score is present, no KEV entry is listed, and no public exploit identified at time of analysis, with priority monitor.
Apache Kafka brokers can be driven into heap exhaustion by any authenticated client because the PushTelemetry (KIP-714) path limits the compressed request size but not the decompressed output. A tiny, highly compressible payload can expand to hundreds of megabytes, and repeated or concurrent requests can trigger OutOfMemoryError, degrade brokers, and affect cluster availability; PushTelemetry is not ACL-gated. No public exploit was identified at time of analysis, and vendor fixes are available in Apache Kafka 4.2.2, 4.3.1, and 4.4.0.
Apache Kafka brokers that authenticate clients via SASL/OAUTHBEARER using the bundled JWKS-backed validator can accept a validly-signed JWT that was minted by a different issuer, or that omits the aud claim, because the issuer check only runs when sasl.oauthbearer.expected.issuer is set and an audience claim is only required when sasl.oauthbearer.expected.audience is set - both default to unset. The practical exposure is concentrated in deployments whose JWKS endpoint publishes signing keys for more than one issuer (multi-tenant IdP, aggregated/shared JWKS, shared signing keys), where such a token may authenticate a client, potentially as a higher-privileged principal; single-issuer deployments that control the iss claim and issue audience-scoped tokens are far less exposed. The JWT signature trust anchor is still enforced in every case, no public exploit code has been identified at time of analysis, and the flaw is not listed in CISA KEV; an analyst-derived CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N places severity at the high end while acknowledging the configuration and token-availability preconditions.
Denial of service in Apache Kafka's KRaft controller affects releases 2.8.0 through 4.2.1 and 4.3.0 through 4.3.1, where a remote authenticated principal holding CLUSTER_ACTION authorization can terminate the controller process by sending a crafted FetchSnapshotRequest whose topics array is empty or whose single topic carries no partitions. The impact is availability-only: the controller dies, taking cluster metadata management down with it, but no data is exposed or altered (assessed CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). CLUSTER_ACTION is a cluster-level permission normally held by broker/controller identities rather than ordinary producers or consumers, so the realistic attacker is a compromised or malicious broker or a holder of inter-broker credentials. No public exploit has been identified at time of analysis, no CISA KEV entry exists, and the vuln.today decision label is 'monitor'.
Improper authorization in Apache Kafka 4.0.0-4.3.0 arises from a discrepancy between the documented ACL requirement and the actual runtime behavior of the CONSUMER_GROUP_DESCRIBE (API key 69) endpoint. The API checks for DESCRIBE permission on the GROUP resource at runtime, while official Kafka documentation and KIP-848 specify READ as the required operation - causing administrators who followed the documentation to configure ACLs that either over-grant READ access to users who should only observe group metadata, or under-restrict DESCRIBE-only users who can nonetheless access sensitive consumer group state. No public exploit has been identified at time of analysis, and EPSS exploitation probability is 0.02% (4th percentile), indicating negligible opportunistic exploitation risk.
Apache Kafka's NetworkClient component logs entire request and response payloads at DEBUG level, exposing sensitive authentication credentials, delegation tokens, and configuration data in plaintext logs. This affects Kafka versions 0.11.0 through 3.9.1 and 4.0.0 across the broker and client libraries. While DEBUG logging is not enabled by default (INFO is the standard), organizations that enable DEBUG logging for troubleshooting inadvertently create persistent records of authentication material and secrets that can be harvested by local log readers or accessed via log aggregation systems. CVSS 5.3 reflects low network attack surface (requires prior DEBUG enablement), but SSVC rates this as automatable with partial technical impact, suitable for prioritization in environments using centralized logging.