CVE List

Apache Kafka Security Vulnerabilities

This page lists all security vulnerabilities fixed in released versions of Apache Kafka.

This page does not list security advisories for dependencies of Kafka. If your security scanner warns that there is an advisory for a dependency of Kafka, please see this documentation. You can find the current development versions of various dependencies here. You can find a list of advisories that have been confirmed not to apply to Kafka here. You are invited to contribute version updates or (motivated) suppressions.

CVE-2026-114349 Apache Kafka: Denial of service via unbounded memory allocation when decoding compressed record batches

When a broker decodes a compressed record batch, the per-record decoder reads a declared body size from the decompressed stream and allocates a buffer of that size before validating it against the bytes available or any configured limit. The size is attacker-controlled, and the batch CRC does not constrain it, so a small (around 90-byte), CRC-valid compressed produce request can declare a body size of up to about 2 GiB and force the broker to attempt that allocation, raising OutOfMemoryError. The record size limit (max.message.bytes), the request size limit, and client/broker quotas bound only the compressed wire size, not the declared decompressed size.

Credit: Peyton Kennedy (reporter), Trung Nguyen (CyStack) (reporter), Bartłomiej Dmitruk (Striga) (reporter), 임성민 (reporter), Mike Read (GitHub: Michael-JRead) (reporter), Salman Aljardan (reporter), Yuchao Zhang (reporter), Yu Bao (PayPal Cyber Security Team) (reporter), Vamsi K (reporter), Srinivas Akhil Mallela (remediation developer)

References: CVE-2026-114349

Versions affected	0.11.0.0 through 4.1.2, 4.2.0 through 4.2.1, 4.3.0 through 4.3.1
Fixed versions	4.2.2, 4.3.2, 4.4.0
Impact	An authenticated principal with Write on a topic can crash broker request-handler threads (reached when a batch’s codec differs from the topic’s `compression.type` and records are re-encoded) and any consumer that fetches the record, denying service. On brokers started with `-XX:+ExitOnOutOfMemoryError`, a common hardening, a single crafted request terminates the broker JVM. More seriously, a crafted record is accepted at ingest and written to disk; when the log-cleaner later reads it on a compacted topic, the `OutOfMemoryError` (an Error, not an Exception) terminates the cleaner thread, which is not restarted. With the default of a single cleaner thread, log compaction then stops for the entire broker, including the internal `__consumer_offsets` and `__transaction_state` topics, and the condition persists across restarts until the offending record is removed. The impact is availability only; no data is disclosed or altered.
Advice	Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0, and set `max.decompressed.message.bytes` (at the broker and/or topic level) to a bounded value appropriate for your workload. Upgrading alone is not sufficient: for backward compatibility this configuration defaults to an effectively unlimited value (about 2 GiB), so a broker remains exposed until the limit is set. Choose a value at or slightly above the largest legitimate decompressed record your applications produce, and comfortably below the broker heap divided by the number of request-handler and cleaner threads. Until you can upgrade and configure the limit, restrict Write access to trusted producers; quotas and `max.message.bytes` do not mitigate this issue. From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: the broker validates a record’s declared decompressed body size against `max.decompressed.message.bytes` before allocating, on the produce-validation, log-compaction, and timestamp-lookup paths, and rejects oversized or negative sizes with `InvalidRecordException`. Operators must set this configuration to a bounded value to be protected, as its default is effectively unlimited.
Issue announced	28 Oct 2026

CVE-2026-112375 Apache Kafka: Unauthorized principal can read arbitrary broker files via IncrementalAlterConfigs

An authenticated Kafka principal with no authorization grants (not even ALTER_CONFIGS) can make a broker read a file or an environment variable from the broker host and return its contents. An IncrementalAlterConfigs (or AlterConfigs) request targeting a BROKER resource reaches the broker’s configuration validation before any authorization check is applied to that path. Validation resolves configuration variables such as ${file:/path:key} or ${env:VAR} using a ConfigProvider named in the request, and this resolution bypasses the org.apache.kafka.automatic.config.providers allowlist that was added as the mitigation for CVE-2024-31141. An arbitrary ConfigProvider (for example FileConfigProvider or EnvVarConfigProvider) is therefore instantiated and the referenced file or environment variable is read, and a type-validation error returns the resolved content to the caller.

Credit: Arthur Chan (Ada Logics and Anthropic Research) (reporter), OpenAI Codex Security - Amy Burnett and Khai Tran (reporter), Mickael Maison (remediation developer), Manikumar Reddy (remediation developer), Chia-Ping Tsai (remediation developer)

References: CVE-2026-112375

Versions affected	3.2.0 through 4.1.2, 4.2.0 through 4.2.1, 4.3.0 through 4.3.1
Fixed versions	4.2.2, 4.3.2, 4.4.0
Impact	On a cluster with an authorizer enabled, an authenticated principal with no authorization grants can read the contents of files accessible to the broker process, and the broker’s environment variables, exposing credentials, keystores, or other secrets, defeating the CVE-2024-31141 allowlist. The read is bounded by the broker process’s file permissions. The brokers and the cluster remain available; the issue is disclosure of file and environment-variable contents. Clusters with no authorizer configured are not affected in practice, because every principal already holds ALTER_CONFIGS there.
Advice	Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. As defense in depth, run brokers under a least-privileged operating-system account so that sensitive files are not readable by the broker process. From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: broker configuration changes are authorized (ALTER_CONFIGS on the cluster) before the configuration is validated, and configuration-variable resolution enforces the config-providers allowlist.
Issue announced	28 Oct 2026

CVE-2026-111551 Apache Kafka: Denial of service in Kafka Streams and client deserializers via unbounded memory allocation

Several Kafka deserialization paths read a size or count field from input data and use it directly to allocate an array, collection, or byte buffer, with no check against the bytes actually available. A small crafted input can therefore declare a very large size and force a multi-gigabyte allocation. The affected paths are, in Kafka Streams, ProcessorRecordContext (header count), ChangedDeserializer (varint value length), CombinedKeySchema (foreign-key length, which could also produce a negative size), ProcessorMetadata (key length), and AssignmentInfo group-assignment decoding; and, in the clients library, ListDeserializer (used by ListSerde).

Credit: Peyton Kennedy (reporter), Bartłomiej Dmitruk (Striga) (reporter), Mike Read (GitHub: Michael-JRead) (reporter), Matthias J. Sax (remediation developer), Lucy Liu (remediation developer)

References: CVE-2026-111551

Versions affected	0.10.0.0 through 4.1.2, 4.2.0 through 4.2.1, 4.3.0 through 4.3.1
Fixed versions	4.2.2, 4.3.2, 4.4.0
Impact	An attacker can trigger the oversized allocation and raise an `OutOfMemoryError` that crashes the affected consumer or Kafka Streams thread; the broker and the rest of the cluster are unaffected. The reachable surface depends on the path: writing a crafted record to a Streams application’s internal changelog or repartition topics, or committing crafted offset metadata to its consumer group (Streams internal paths); writing a crafted record to any topic that a consumer reads with `ListSerde` (`ListDeserializer`); or, as a member of a Streams consumer group, returning crafted assignment data when elected leader (`AssignmentInfo`). Because a crafted record remains in its topic, the error can recur on restart. The record size limit (`max.message.bytes`) does not help, because the allocation is driven by a size field rather than by the input’s length.
Advice	Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Where authorization is enabled, restrict write access to each application’s internal topics and consumer group to its own principal, and restrict who can produce to topics that are consumed with `ListSerde`. From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: these deserialization paths validate the declared size against the remaining input before allocating and reject input that fails the check.
Issue announced	28 Oct 2026

CVE-2026-111115 Apache Kafka: Broker OutOfMemoryError via tagged-field allocation amplification in flexible protocol request parsing

Apache Kafka’s code-generated readers for flexible protocol versions read a tagged-field count declared by the sender and retain a RawTaggedField object for each unknown field. That count was bounded only by the outer request-frame size (socket.request.max.bytes); it was not checked against the remaining buffer bytes or capped. Because each entry can be encoded in as little as two bytes (unknown tag 0, size 0), a modest request can declare tens of millions of tagged fields and force one object allocation per declared field. Flexible request headers (header version 2, used by flexible APIs such as ApiVersions v3) are parsed this way, so the amplification applies to the request header itself.

Credit: Mufeed VH (finder), Vivek R (finder), Shay Elkin (remediation developer)

References: CVE-2026-111115

Versions affected	2.4.0 through 4.1.2, 4.2.0 through 4.2.1, 4.3.0 through 4.3.1
Fixed versions	4.2.2, 4.3.2, 4.4.0
Impact	The 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.
Advice	Mitigation: Upgrade 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. From 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.
Issue announced	28 Oct 2026

CVE-2026-111108 Apache Kafka: Broker OutOfMemoryError via array allocation amplification in code-generated protocol readers

Apache Kafka’s code-generated protocol readers pre-size an array’s collection from the element count declared by the sender. That count is checked only against the bytes remaining in the request buffer, which assumes about one byte per element; because most elements need several bytes, a request can declare far more elements than the buffer holds and still pass. For a keyed 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 before any element is read. The pattern is emitted into every generated reader, so it affects all Kafka API types with an array field.

Credit: Mike Read (GitHub: Michael-JRead) (reporter), Izzy Harker (remediation developer), Alyssa Huang (remediation developer), Truc Nguyen (remediation developer)

References: CVE-2026-111108

Versions affected	3.3.0 through 4.1.2, 4.2.0 through 4.2.1, 4.3.0 through 4.3.1
Fixed versions	4.2.2, 4.3.2, 4.4.0
Impact	Request parsing happens before any authorization check. On a listener that does not require authentication (for example PLAINTEXT), an unauthenticated attacker can send a few concurrent requests that each declare a very large array length and allocate many times their wire size in broker heap, crashing the broker with an `OutOfMemoryError`. The reporter demonstrated three concurrent ~90 MB ProduceRequest (v3) connections exhausting a 1 GB heap (~8x amplification). On listeners that require authentication, the attacker needs valid credentials but no specific ACL, since parsing precedes authorization.
Advice	Mitigation: Upgrade 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. From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers cap the initial array pre-allocation at `MessageUtil.MAX_PREALLOCATED_ARRAY_CAPACITY` (1000) and grow it on demand, and reject a declared array length above `MessageUtil.MAX_ARRAY_LENGTH` (1,000,000).
Issue announced	28 Oct 2026

CVE-2026-110985 Apache Kafka: Broker silently skips JWT signature verification for SASL/OAUTHBEARER when the JWKS endpoint URL is not configured

A Kafka broker using SASL/OAUTHBEARER with the default validator (sasl.oauthbearer.jwt.validator.class=DefaultJwtValidator) selects its implementation from configuration. When sasl.oauthbearer.jwks.endpoint.url is set, the validator verifies the JWT signature. When that URL is unset (the default) and no verification key resolver is supplied, DefaultJwtValidator silently falls back to ClientJwtValidator, which does not verify the JWT signature, algorithm, or issuer — and the broker starts with no warning or error. This is the residual of CVE-2026-33557, whose fix restored signature verification only on the path where the JWKS endpoint URL is set.

Credit: San Zhang (reporter), Kaixuan Li (reporter), Evan Zhou (remediation developer)

References: CVE-2026-110985

Versions affected	4.1.0 through 4.1.2, 4.2.0 through 4.2.1, 4.3.0
Fixed versions	4.2.2, 4.3.1, 4.4.0
Impact	A broker in this state accepts any structurally valid JWT, including `"alg":"none"` tokens. An unauthenticated remote attacker who can reach the listener can forge a token asserting any principal — including configured superusers — and gain full access to the cluster. Only brokers that enable SASL/OAUTHBEARER validation without a JWKS endpoint URL (and without a custom verification key resolver) are affected; brokers that set the URL verify signatures and are not affected. Unlike CVE-2026-110952 (issuer/audience not enforced by default), here no signature is verified at all.
Advice	Mitigation (all affected versions, no upgrade required): Set `sasl.oauthbearer.jwks.endpoint.url` for every listener/mechanism that uses `OAuthBearerValidatorCallbackHandler`, or configure a signature-verifying `sasl.oauthbearer.jwt.validator.class`. From Apache Kafka 4.2.2, 4.3.1, and 4.4.0: a broker that would fall back to the non-verifying `ClientJwtValidator` fails to start with a `ConfigException` instead of running without signature verification (secure by default).
Issue announced	28 Oct 2026

CVE-2026-116593 Apache Kafka: Kafka Connect configuration provider values exposed via validation REST API endpoint

Apache Kafka Connect has the /connector-plugins/{connector-type}/config/validate endpoint on its REST API to validate connector configurations. Apache Kafka Connect also supports Configuration Providers, which allow the values of sensitive configuration to be hidden and resolved only at runtime.

An attacker with access to the validate endpoint can use it to resolve and return plaintext values via any of the configuration providers installed on a Connect worker.

Credit: Hyunwoo Kim (reporter), Sudhanshu Chauhan (RedHunt Labs) (reporter), Bartłomiej Dmitruk (Striga) (reporter), Andrew MacPherson (reporter), Mickael Maison (remediation developer)

References: CVE-2026-116593

Versions affected	2.4.0 through 4.2.1, 4.3.0 through 4.3.1
Fixed versions	4.2.2, 4.3.2, 4.4.0
Impact	This issue could result in exposing sensitive configuration values (such as externalized secrets) that are normally hidden by Connect configuration providers.
Advice	Users are recommended to upgrade to 4.2.2, 4.3.2, 4.4.0, or above, which fix this issue.
Issue announced	28 Oct 2026

CVE-2026-111073 Apache Kafka: PushTelemetry (KIP-714) metrics payloads are decompressed without a size limit, allowing a broker out-of-memory denial of service

The broker-side PushTelemetry API (KIP-714) validates only the compressed size of a client’s metrics payload against telemetry.max.bytes (default 1 MB) before decompressing it. ClientTelemetryUtils.decompress() then decompresses the payload with no limit on the decompressed output size, growing a heap buffer until the compressed input is exhausted. A small, highly compressible payload (for example gzip-compressed zeros) can therefore expand to hundreds of megabytes of broker heap.

Credit: Dawit Jeong (reporter), Apoorv Mittal (remediation developer), Andrew Schofield (remediation reviewer)

References: CVE-2026-111073

Versions affected	3.7.0 through 4.1.2, 4.2.0 through 4.2.1, 4.3.0
Fixed versions	4.2.2, 4.3.1, 4.4.0
Impact	An authenticated client can send a PushTelemetry request with a small compressed payload that decompresses to a very large size, consuming broker heap out of proportion to the request size. Repeated or concurrent requests can exhaust the broker heap and cause an `OutOfMemoryError`, degrading or crashing the broker; a client that targets multiple brokers can affect cluster availability. PushTelemetry is available to any authenticated client and is not gated by an ACL.
Advice	Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.1, or 4.4.0. On affected versions there is no configuration that fully prevents the amplification, because `telemetry.max.bytes` bounds only the compressed size; lowering `telemetry.max.bytes` reduces the worst-case decompressed size proportionally and is a partial mitigation. From Apache Kafka 4.2.2, 4.3.1, and 4.4.0: `ClientTelemetryUtils.decompress()` enforces a maximum decompressed size equal to `telemetry.max.bytes` (default 1 MB). Decompression reads in bounded chunks and aborts with a `TelemetryTooLargeException` once the decompressed total exceeds the limit, so an over-large or highly compressible payload is rejected instead of being fully expanded in heap. The decompressed size is therefore bounded by default.
Issue announced	28 Oct 2026

CVE-2026-110952 Apache Kafka: Broker does not enforce JWT issuer and audience validation for SASL/OAUTHBEARER by default

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:

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.
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 still rejected when no expected audience is configured.)

Both options default to unset and have been documented as optional (Importance LOW) since KIP-768 (3.1.0).

Credit: Kai Aizen (SnailSploit) (reporter), Evan Zhou (remediation developer)

References: CVE-2026-110952

Versions affected	3.1.0 through 4.3.2
Fixed versions	4.4.0
Impact	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 minted for a different issuer, or a token lacking an audience, may be accepted to authenticate — potentially as a higher-privileged principal. In a single-issuer deployment where the provider controls the `iss` 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 signature is validated and only the issuer/audience checks are not enforced by default.
Advice	Mitigation (all affected versions, no upgrade required): Set both `sasl.oauthbearer.expected.issuer` (to your provider’s exact `iss` value) and `sasl.oauthbearer.expected.audience` (to the audience(s) your brokers expect), per listener. Brokers that set these perform exact-match issuer/audience checks and are not affected. Both have been available since 3.1.0. 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 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`.
Issue announced	28 Oct 2026

CVE-2026-115644 Apache Kafka: Connect Admin REST API Authentication Bypass via Unapplied REST Extensions

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.

When 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.

While 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.

Credit: Bartłomiej Dmitruk (Striga) (reporter), Mickael Maison (remediation developer)

References: CVE-2026-115644

Versions affected	2.4.0 through 4.2.1, 4.3.0 through 4.3.1
Fixed versions	4.2.2, 4.3.2, 4.4.0
Impact	An unauthenticated attacker with network access to the admin listener can: Read the complete set of logger names and levels, disclosing loaded class names and which security extensions are in use. Write logger levels, including with `scope=cluster` which propagates the change to all workers in the Connect cluster. This can be used to suppress logging (setting root to OFF) or generate excessive log output (setting root to TRACE), potentially impacting availability and observability.
Advice	Mitigation: 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. From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: the REST extensions specified via `rest.extension.classes` are also applied to `admin.listeners`.
Issue announced	28 Oct 2026

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

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.

Credit: Mike Read (GitHub: Michael-JRead) (reporter), Matthias J. Sax (remediation developer)

References: CVE-2026-111496

Versions affected	1.1.0 through 4.1.2, 4.2.0 through 4.2.1, 4.3.0 through 4.3.1
Fixed versions	4.2.2, 4.3.2, 4.4.0
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.
Advice	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. 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.
Issue announced	28 Oct 2026

CVE-2026-83525 Apache Kafka: Incorrect boolean operator in FetchSnapshot RPC handler allows authenticated network clients to crash the KRaft controller via a malformed request

Incorrect operator (CWE-480) in the FetchSnapshot RPC handler in Apache Kafka from 2.8.0 before 4.2.2, and from 4.3.0 before 4.3.2, on all platforms allows an authenticated attacker with CLUSTER_ACTION privilege to cause a denial of service (controller process termination) via a crafted FetchSnapshotRequest with an empty topics array or a topic with no partitions.

Users are recommended to upgrade to version 4.2.2, 4.3.2, or 4.4.0, which fix this issue. Users on unsupported branches (4.1.x and earlier) should upgrade to 4.2.2 or later.

Credit: Mike Read (GitHub: Michael-JRead) (reporter), Kevin Wu (remediation developer)

References: apache/kafka#23185, CVE-2026-83525

Versions affected	2.8.0 through 4.2.1, 4.3.0 through 4.3.1
Fixed versions	4.2.2, 4.3.2, 4.4.0
Impact	An authenticated attacker with CLUSTER_ACTION privilege can cause a denial of service (KRaft controller process termination) by sending a crafted FetchSnapshotRequest with an empty topics array or a topic with no partitions.
Advice	Users are recommended to upgrade to 4.2.2, 4.3.2, or 4.4.0, which fix this issue. Users on unsupported branches (4.1.x and earlier) should upgrade to 4.2.2 or later.
Issue announced	28 Oct 2026

CVE-2026-41115 Apache Kafka: Improper Authorization in CONSUMER_GROUP_DESCRIBE API

The implementation of the CONSUMER_GROUP_DESCRIBE (69) API validates the DESCRIBE operation on the GROUP resource instead of the READ operation as documented in the official Kafka documentation and KIP-848. This discrepancy can result in misconfigured Access Control Lists (ACLs) and unintended security postures, like granting READ permission to users who should not be able to join/sync groups, or allowing users without READ permission (but with DESCRIBE permission) to access sensitive group metadata.

The correct permission for CONSUMER_GROUP_DESCRIBE API is DESCRIBE GROUP so the current implementation is correct. However, the Kafka documentation as well as KIP-848 have been updated to reflect the correct permission. We advise the Kafka users to review existing group ACLs to ensure the principle of least privilege.

Versions affected	4.0.0 - 4.3.0
Fixed versions	4.0.0 - 4.3.0
Impact	This improper authorization can result in misconfigured ACLs and unintended security postures, like granting READ permission to users who should not be able to join/sync groups, or allowing users without READ permission (but with DESCRIBE permission) to access sensitive group metadata.
Advice	Kafka users using 4.0.0 - 4.3.0 are advised to review existing group ACLs to ensure the principle of least privilege.
Issue announced	2 Jun 2026

CVE-2026-33558 Apache Kafka, Apache Kafka Clients: Information Exposure Through Network Client Log Output

The NetworkClient component will output entire requests and responses information in the DEBUG log level in the logs. By default, the log level is set to INFO level. If the DEBUG level is enabled, the sensitive information will be exposed via the requests and responses output log. The entire lists of impacted requests and responses are:

AlterConfigsRequest
AlterUserScramCredentialsRequest
ExpireDelegationTokenRequest
IncrementalAlterConfigsRequest
RenewDelegationTokenRequest
SaslAuthenticateRequest
createDelegationTokenResponse
describeDelegationTokenResponse
SaslAuthenticateResponse

Versions affected	Apache Kafka Clients (kafka-clients) 0.11.0 through 3.9.1, 4.0.0
Fixed versions	3.9.2, 4.0.1, 4.1.0
Impact	Sensitive information exposure through network client log output
Advice	Kafka users are advised to use INFO log level or higher for NetworkClient class or upgrade to 3.9.2, 4.0.1, 4.1.0, or later to address this vulnerability.
Issue announced	17 Apr 2026

CVE-2026-33557 Apache Kafka: Missing JWT token validation in OAUTHBEARER authentication

When sasl.enabled.mechanisms=OAUTHBEARER is configured on the server side, by default the broker property sasl.oauthbearer.jwt.validator.class is set to org.apache.kafka.common.security.oauthbearer.DefaultJwtValidator. It accepts any JWT token without validating its signature, issuer, or audience. An attacker can generate a JWT token from any issuer with the preferred_username set to any user, and the broker will accept it.

Versions affected	4.1.0 - 4.1.1
Fixed versions	4.1.2, 4.2.0
Impact	An attacker can generate a JWT token from any issuer with the `preferred_username` set to any user, and the broker will accept it.
Advice	We advise the Kafka users using kafka v4.1.0 or v4.1.1 to set the config `sasl.oauthbearer.jwt.validator.class` to `org.apache.kafka.common.security.oauthbearer.BrokerJwtValidator` explicitly to avoid this vulnerability. Or upgrade to v4.1.2, v4.2.0 and later.
Issue announced	17 Apr 2026

CVE-2026-35554 Apache Kafka Clients: Kafka Producer Message Corruption and Misrouting via Buffer Pool Race Condition

A race condition in the Apache Kafka Java producer client’s buffer pool management can cause messages to be silently delivered to incorrect topics.

When a produce batch expires due to delivery.timeout.ms while a network request containing that batch is still in flight, the batch’s ByteBuffer is prematurely deallocated and returned to the buffer pool. If a subsequent producer batch—potentially destined for a different topic—reuses this freed buffer before the original network request completes, the buffer contents may become corrupted. This can result in messages being delivered to unintended topics without any error being reported to the producer.

Data Confidentiality: Messages intended for one topic may be delivered to a different topic, potentially exposing sensitive data to consumers who have access to the destination topic but not the intended source topic.

Data Integrity: Consumers on the receiving topic may encounter unexpected or incompatible messages, leading to deserialization failures, processing errors, and corrupted downstream data.

Credit: Bharath Vissapragada (reporter), Donny Nadolny (finder, remediation developer)

References: KAFKA-19012, CVE-2026-35554

Versions affected	Apache Kafka Clients (kafka-clients) 2.8.0 through 3.9.1, 4.0.0 through 4.0.1, 4.1.0 through 4.1.1
Fixed versions	3.9.2, 4.0.2, 4.1.2, 4.2.0
Impact	Kafka producer messages may be silently delivered to incorrect topics due to a buffer pool race condition, potentially exposing sensitive data to unintended consumers and causing data integrity issues.
Advice	Kafka users are advised to upgrade to 3.9.2, 4.0.2, 4.1.2, 4.2.0, or later to address this vulnerability.
Issue announced	7 Apr 2026

CVE-2025-27819 Apache Kafka: Possible RCE/Denial of service attack via SASL JAAS JndiLoginModule configuration

In CVE-2023-25194, we announced the RCE/Denial of service attack via SASL JAAS JndiLoginModule configuration in Kafka Connect API. But not only Kafka Connect API is vulnerable to this attack, the Apache Kafka brokers also have this vulnerability. To exploit this vulnerability, the attacker needs to be able to connect to the Kafka cluster and have the AlterConfigs permission on the cluster resource.

Since Apache Kafka 3.4.0, we have added a system property ("-Dorg.apache.kafka.disallowed.login.modules") to disable the problematic login modules usage in SASL JAAS configuration. Also by default “com.sun.security.auth.module.JndiLoginModule” is disabled in Apache Kafka 3.4.0, and “com.sun.security.auth.module.JndiLoginModule,com.sun.security.auth.module.LdapLoginModule” is disabled by default in Apache Kafka 3.9.1/4.0.0.

Versions affected	2.0.0 - 3.3.2
Fixed versions	3.9.1, 4.0.0
Impact	Possible RCE/Denial of service attack via SASL JAAS JndiLoginModule configuration
Advice	We advise all Kafka users to upgrade kafka to version >=3.9.1.
Issue announced	9 Jun 2025

CVE-2025-27818 Apache Kafka: Possible RCE attack via SASL JAAS LdapLoginModule configuration

A possible security vulnerability has been identified in Apache Kafka. This requires access to a alterConfig to the cluster resource, or Kafka Connect worker, and the ability to create/modify connectors on it with an arbitrary Kafka client SASL JAAS config and a SASL-based security protocol, which has been possible on Kafka clusters since Apache Kafka 2.0.0 (Kafka Connect 2.3.0). When configuring the broker via config file or AlterConfig command, or connector via the Kafka Kafka Connect REST API, an authenticated operator can set the sasl.jaas.config property for any of the connector’s Kafka clients to “com.sun.security.auth.module.LdapLoginModule”, which can be done via the producer.override.sasl.jaas.config, consumer.override.sasl.jaas.config, or admin.override.sasl.jaas.config properties. This will allow the server to connect to the attacker’s LDAP server and deserialize the LDAP response, which the attacker can use to execute java deserialization gadget chains on the Kafka connect server. Attacker can cause unrestricted deserialization of untrusted data (or) RCE vulnerability when there are gadgets in the classpath.

Since Apache Kafka 3.9.1/4.0.0, we have added a system property ("-Dorg.apache.kafka.disallowed.login.modules") to disable the problematic login modules usage in SASL JAAS configuration. Also by default “com.sun.security.auth.module.JndiLoginModule,com.sun.security.auth.module.LdapLoginModule” are disabled in Apache Kafka Connect 3.9.1/4.0.0.

Versions affected	2.3.0 - 3.9.0
Fixed versions	3.9.1, 4.0.0
Impact	Possible RCE attack via SASL JAAS LdapLoginModule configuration
Advice	We advise all Kafka users to upgrade kafka to version >=3.9.1.
Issue announced	9 Jun 2025

CVE-2025-27817 Apache Kafka Client: Arbitrary file read and SSRF vulnerability

A possible arbitrary file read and SSRF vulnerability has been identified in Apache Kafka Client. Apache Kafka Clients accept configuration data for setting the SASL/OAUTHBEARER connection with the brokers, including “sasl.oauthbearer.token.endpoint.url” and “sasl.oauthbearer.jwks.endpoint.url”. Apache Kafka allows clients to read an arbitrary file and return the content in the error log, or sending requests to an unintended location. In applications where Apache Kafka Clients configurations can be specified by an untrusted party, attackers may use the “sasl.oauthbearer.token.endpoint.url” and “sasl.oauthbearer.jwks.endpoint.url” configuration to read arbitrary contents of the disk and environment variables or make requests to an unintended location. In particular, this flaw may be used in Apache Kafka Connect to escalate from REST API access to filesystem/environment/URL access, which may be undesirable in certain environments, including SaaS products.

Since Apache Kafka 3.9.1/4.0.0, we have added a system property ("-Dorg.apache.kafka.sasl.oauthbearer.allowed.urls") to set the allowed urls in SASL JAAS configuration. In 3.9.1, it accepts all urls by default for backward compatibility. However in 4.0.0 and newer, the default value is empty list and users have to set the allowed urls explicitly.

Versions affected	3.1.0 - 3.9.0
Fixed versions	3.9.1, 4.0.0
Impact	Arbitrary file read and SSRF vulnerability
Advice	We advise all Kafka users to upgrade kafka to version >=3.9.1 and set the JVM system property `org.apache.kafka.sasl.oauthbearer.allowed.urls` to the desired value.
Issue announced	9 Jun 2025

CVE-2024-56128 SCRAM authentication vulnerable to replay attacks when used without encryption

Apache Kafka’s implementation of the Salted Challenge Response Authentication Mechanism (SCRAM) did not fully adhere to the requirements of RFC 5802. Specifically, as per RFC 5802, the server must verify that the nonce sent by the client in the second message matches the nonce sent by the server in its first message. However, Kafka’s SCRAM implementation did not perform this validation.

This vulnerability is exploitable only when an attacker has plaintext access to the SCRAM authentication exchange. However, the usage of SCRAM over plaintext is strongly discouraged as it is considered an insecure practice. Apache Kafka recommends deploying SCRAM exclusively with TLS encryption to protect SCRAM exchanges from interception. Deployments using SCRAM with TLS are not affected by this issue.

Versions affected	0.10.2.0 - 3.7.1, 3.8.0
Fixed versions	3.7.2, 3.8.1, 3.9.0
Impact	SCRAM authentication vulnerable to replay attacks when used without encryption.
Advice	Users are advised to upgrade to 3.7.2 or later to mitigate this issue. Users unable to upgrade to the fixed versions can mitigate the issue by using TLS with SCRAM Authentication. Considering alternative authentication mechanisms such as PLAIN, Kerberos or OAuth with TLS, which provide additional layers of security
Issue announced	18 Dec 2024

CVE-2024-31141 Files or Directories Accessible to External Parties, Improper Privilege Management vulnerability in Apache Kafka Clients

Apache Kafka Clients accept configuration data for customizing behavior, and includes ConfigProvider plugins in order to manipulate these configurations. Apache Kafka also provides FileConfigProvider, DirectoryConfigProvider, and EnvVarConfigProvider implementations which include the ability to read from disk or environment variables.

In applications where Apache Kafka Clients configurations can be specified by an untrusted party, attackers may use these ConfigProviders to read arbitrary contents of the disk and environment variables. In particular, this flaw may be used in Apache Kafka Connect to escalate from REST API access to filesystem/environment access, which may be undesirable in certain environments, including SaaS products.

Versions affected	2.3.0 - 3.7.0
Fixed versions	3.7.1, 3.8.0
Impact	Contents of disks and environment variables of applications using Kafka Clients may be leaked to untrusted parties.
Advice	Users with affected applications are recommended to upgrade kafka-clients to version >=3.8.0, and set the JVM system property “org.apache.kafka.automatic.config.providers=none”. Users of Kafka Connect with one of the listed ConfigProvider implementations specified in their worker config are also recommended to add appropriate “allowlist.pattern” and “allowed.paths” to restrict their operation to appropriate bounds. For users of Kafka Clients or Kafka Connect in environments that trust users with disk and environment variable access, it is not recommended to set the system property. For users of the Kafka Broker, Kafka MirrorMaker 2.0, Kafka Streams, and Kafka command-line tools, it is not recommended to set the system property.
Issue announced	18 Nov 2024

CVE-2024-27309 Potential incorrect access control during migration from ZK mode to KRaft mode

While an Apache Kafka cluster is being migrated from ZooKeeper mode to KRaft mode, in some cases ACLs will not be correctly enforced. Two preconditions are needed to trigger the bug:

The administrator decides to remove an ACL
The resource associated with the removed ACL continues to have two or more other ACLs associated with it after the removal. When those two preconditions are met, Kafka will treat the resource as if it had only one ACL associated with it after the removal, rather than the two or more that would be correct. The incorrect condition is cleared by removing all brokers in ZK mode, or by adding a new ACL to the affected resource. Once the migration is completed, there is no metadata loss (the ACLs all remain).

Versions affected	3.5.0 - 3.6.1
Fixed versions	3.6.2
Impact	The impact depends on the ACLs in use. If only ALLOW ACLs were configured during the migration, the impact would be limited to availability impact. if DENY ACLs were configured, the impact could include confidentiality and integrity impact depending on the ACLs configured, as the DENY ACLs might be ignored due to this vulnerability during the migration period.
Advice	We advise all Kafka users using ACLs to only perform ZooKeeper to KRaft migrations when using Kafka 3.6.2 or above.
Issue announced	12 Apr 2024

CVE-2023-34455 Clients using Snappy compression may cause out of memory error on brokers

This CVE identifies a vulnerability in snappy-java which could be used to cause an Out-of-Memory (OOM) condition, leading to Denial-of-Service(DoS) on the Kafka broker. The vulnerability allows any user who can producer data to the broker to exploit the vulnerability by sending a malicious payload in the record which is compressed using snappy. For more details on the vulnerability, please refer to the following link: snappy-java GitHub advisory.

Versions affected	0.8.0 - 3.5.0
Fixed versions	3.5.1
Impact	This vulnerability allows any user who can produce data to the broker to exploit the vulnerability, potentially causing an Out-of-Memory (OOM) condition, leading to Denial-of-Service(DoS) on the Kafka broker. It could be exploited by sending a malicious payload in the record which is compressed using snappy. On receiving the record, the broker will try to de-compress the record to perform record validation and it will delegate decompression to snappy-java library. The vulnerability in the snappy-java library may cause allocation of an unexpected amount of heap memory, causing an OOM on the broker. Any configured quota will not be able to prevent this because a single record can exploit this vulnerability.
Advice	We advise all Kafka users to promptly upgrade to a version of snappy-java (>=1.1.10.1) to mitigate this vulnerability. The latest version (1.1.10.1, as of July 5, 2023) of snappy-java is backward compatible with all affected versions of Kafka. The affected library jar for snappy-java should be replaced with this newer version.
Issue announced	5 Jul 2023

CVE-2023-25194 Possible RCE/Denial of service attack via SASL JAAS JndiLoginModule configuration using Apache Kafka Connect API

A possible security vulnerability has been identified in Apache Kafka Connect API. This requires access to a Kafka Connect worker, and the ability to create/modify connectors on it with an arbitrary Kafka client SASL JAAS config and a SASL-based security protocol, which has been possible on Kafka Connect clusters since Apache Kafka 2.3.0. This will allow to perform JNDI requests that result in Denial of service/remote code execution.

Versions affected	Apache Kafka Connect API (connect-api,connect-runtime) : 2.3.0 - 3.3.2
Fixed versions	Apache Kafka Connect API (connect-api,connect-runtime) : 3.4.0
Impact	When configuring the connector via the Kafka Connect REST API, an authenticated operator can set the `sasl.jaas.config` property for any of the connector’s Kafka clients to “com.sun.security.auth.module.JndiLoginModule”, which can be done via the `producer.override.sasl.jaas.config`, `consumer.override.sasl.jaas.config`, or `admin.override.sasl.jaas.config` properties. This will allow the server to connect to the attacker’s LDAP server and deserialize the LDAP response, which the attacker can use to execute java deserialization gadget chains on the Kafka connect server. Attacker can cause unrestricted deserialization of untrusted data (or) RCE vulnerability when there are gadgets in the classpath.
Advice	Since Apache Kafka 3.0.0, users are allowed to specify these properties in connector configurations for Kafka Connect clusters running with out-of-the-box configurations. Before Apache Kafka 3.0.0, users may not specify these properties unless the Kafka Connect cluster has been reconfigured with a connector client override policy that permits them. Since Apache Kafka 3.4.0, we have added a system property ("-Dorg.apache.kafka.disallowed.login.modules") to disable the problematic login modules usage in SASL JAAS configuration. Also by default “com.sun.security.auth.module.JndiLoginModule” is disabled in Apache Kafka 3.4.0. We advise the Kafka Connect users to validate connector configurations and only allow trusted JNDI configurations. Also examine connector dependencies for vulnerable versions and either upgrade their connectors, upgrading that specific dependency, or removing the connectors as options for remediation. Finally, in addition to leveraging the “org.apache.kafka.disallowed.login.modules” system property, Kafka Connect users can also implement their own connector client config override policy, which can be used to control which Kafka client properties can be overridden directly in a connector config and which cannot.
Issue announced	8 Feb 2023

CVE-2022-34917 Unauthenticated clients may cause OutOfMemoryError on brokers

This CVE identified a flaw where it allows the malicious unauthenticated clients to allocate large amounts of memory on brokers. This can lead to brokers hitting OutOfMemoryException and causing denial of service.

Versions affected	2.8.0 - 2.8.1, 3.0.0 - 3.0.1, 3.1.0 - 3.1.1, 3.2.0 - 3.2.1
Fixed versions	2.8.2, 3.0.2, 3.1.2, 3.2.3
Impact	Example scenarios in which attacker can cause OutOfMemoryError on brokers - Kafka cluster without authentication: Any clients able to establish a network connection to a broker can trigger the issue. - Kafka cluster with SASL authentication: Any clients able to establish a network connection to a broker, without the need for valid SASL credentials, can trigger the issue. - Kafka cluster with TLS authentication: Only clients able to successfully authenticate via TLS can trigger the issue.
Issue announced	19 Sep 2022

CVE-2022-23302 Deserialization of Untrusted Data Flaw in JMSSink of Apache Log4j logging library in versions 1.x

This CVE identified a flaw where it allows the attacker to provide a TopicConnectionFactoryBindingName configuration that will cause JMSSink to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-4104.

Versions affected	All AK versions
Fixed versions	In the absence of a new log4j 1.x release, one can remove JMSSink class from the log4j-1.2.17.jar artifact.
Impact	When the attacker has write access to the Log4j configuration or if the configuration references an LDAP service the attacker has access to. The attacker can provide a configuration causing JMSSink to perform JNDI requests that result in remote code execution.
Issue announced	18 Jan 2022

CVE-2022-23305 SQL injection Flaw in Apache Log4j logging library in versions 1.x

This CVE identified a flaw where it allows a remote attacker to run SQL statements in the database if the deployed application is configured to use JDBCAppender with certain interpolation tokens.

Versions affected	All AK versions
Fixed versions	In the absence of a new log4j 1.x release, one can remove JDBCAppender class from the log4j-1.2.17.jar artifact.
Impact	This issue could result in a SQL injection attack when the application is configured to use JDBCAppender.
Issue announced	18 Jan 2022

CVE-2022-23307 Deserialization of Untrusted Data Flaw in Apache Log4j logging library in versions 1.x

This CVE identified a flaw where it allows an attacker to send a malicious request with serialized data to the component running log4j 1.x to be deserialized when the chainsaw component is run. Chainsaw is a standalone GUI for viewing log entries in log4j. An attacker not only needs to be able to generate malicious log entries, but also, have the necessary access and permissions to start chainsaw (or if it is already enabled by a customer / consumer of Apache Kafka).

Versions affected	All AK versions
Fixed versions	In the absence of a new log4j 1.x release, one can remove Chainsaw from the log4j-1.2.17.jar artifact.
Impact	When an attacker has the ability to start Chainsaw and is able to generate malicious log entries it allows deserialization of untrusted data.
Issue announced	18 Jan 2022

CVE-2021-45046 Flaw in Apache Log4j logging library in versions from 2.0-beta9 through 2.12.1 and from 2.13.0 through 2.15.0

Some components in Apache Kafka use Log4j-v1.2.17 there is no dependence on Log4j v2.*. Check with the vendor of any connector plugin that includes a Log4J 2.x JAR file.

Users should NOT be impacted by this vulnerability

Versions affected	NA
Fixed versions	NA
Impact	NA
Issue announced	14 Dec 2021

CVE-2021-44228 Flaw in Apache Log4j logging library in versions from 2.0.0 and before 2.15.0

Some components in Apache Kafka use Log4j-v1.2.17 there is no dependence on Log4j v2.*. Check with the vendor of any connector plugin that includes a Log4J 2.x JAR file.

Lookups feature was introduced in Log4j v2.x in order to allow specifying Log4j configuration parameters in arbitrary locations (even outside of the configuration files). Log4j v1.x does not offer the same functionality and thus is not vulnerable to CVE-2021-44228.

Users should NOT be impacted by this vulnerability

Versions affected	NA
Fixed versions	NA
Impact	NA
Issue announced	09 Dec 2021

CVE-2021-4104 Flaw in Apache Log4j logging library in versions 1.x

The following components in Apache Kafka use Log4j-v1.2.17: broker, controller, zookeeper, connect, mirrormaker and tools. Clients may also be configured to use Log4j-v1.x.

Version 1.x of Log4J can be configured to use JMS Appender, which publishes log events to a JMS Topic. Log4j 1.x is vulnerable if the deployed application is configured to use JMSAppender.

Versions affected	All versions
Fixed versions	In the absence of a new log4j 1.x release, one can remove JMSAppender from the log4j-1.2.17.jar artifact. Commands are listed in the page http://slf4j.org/log4shell.html. We also recommend that configuration files be protected against write access as stated in http://slf4j.org/log4shell.html.
Impact	This issue could result in a remote code execution attack when the application is configured to use JMSAppender AND the attacker has access to directly modify the TopicBindingName or TopicConnectionFactoryBindingName configuration variables in property files which is typically an unlikely exploitation scenario.
Issue announced	09 Dec 2021

CVE-2021-38153 Timing Attack Vulnerability for Apache Kafka Connect and Clients

Some components in Apache Kafka use Arrays.equals to validate a password or key, which is vulnerable to timing attacks that make brute force attacks for such credentials more likely to be successful. Users should upgrade to 2.8.1 or higher, or 3.0.0 or higher where this vulnerability has been fixed.

Versions affected	2.0.0, 2.0.1, 2.1.0, 2.1.1, 2.2.0, 2.2.1, 2.2.2, 2.3.0, 2.3.1, 2.4.0, 2.4.1, 2.5.0, 2.5.1, 2.6.0, 2.6.1, 2.6.2, 2.7.0, 2.7.1, 2.8.0.
Fixed versions	2.6.3, 2.7.2, 2.8.1, 3.0.0 and later
Impact	This issue could result in privilege escalation.
Issue announced	21 Sep 2021

CVE-2019-12399 Apache Kafka Connect REST API may expose plaintext secrets in tasks endpoint

When Connect workers in Apache Kafka 2.0.0, 2.0.1, 2.1.0, 2.1.1, 2.2.0, 2.2.1, or 2.3.0 are configured with one or more config providers, and a connector is created/updated on that Connect cluster to use an externalized secret variable in a substring of a connector configuration property value (the externalized secret variable is not the whole configuration property value), then any client can issue a request to the same Connect cluster to obtain the connector’s task configurations and the response will contain the plaintext secret rather than the externalized secrets variable. Users should upgrade to 2.2.2 or higher, or 2.3.1 or higher where this vulnerability has been fixed.

Versions affected	2.0.0, 2.0.1, 2.1.0, 2.1.1, 2.2.0, 2.2.1, 2.3.0
Fixed versions	2.2.2, 2.3.1 and later
Impact	This issue could result in exposing externalized connector secrets.
Issue announced	13 Jan 2020

CVE-2018-17196 Authenticated clients with Write permission may bypass transaction/idempotent ACL validation

In Apache Kafka versions between 0.11.0.0 and 2.1.0, it is possible to manually craft a Produce request which bypasses transaction/idempotent ACL validation. Only authenticated clients with Write permission on the respective topics are able to exploit this vulnerability. Users should upgrade to 2.1.1 or later where this vulnerability has been fixed.

Versions affected	0.11.0.0 to 2.1.0
Fixed versions	2.1.1 and later
Impact	This issue could result in privilege escalation.
Issue announced	10 July 2019

CVE-2018-1288 Authenticated Kafka clients may interfere with data replication

Authenticated Kafka users may perform action reserved for the Broker via a manually created fetch request interfering with data replication, resulting in data loss.

Versions affected	0.9.0.0 to 0.9.0.1, 0.10.0.0 to 0.10.2.1, 0.11.0.0 to 0.11.0.2, 1.0.0
Fixed versions	0.10.2.2, 0.11.0.3, 1.0.1, 1.1.0
Impact	This issue could potentially lead to data loss.
Issue announced	26 July 2018

CVE-2017-12610 Authenticated Kafka clients may impersonate other users

Authenticated Kafka clients may use impersonation via a manually crafted protocol message with SASL/PLAIN or SASL/SCRAM authentication when using the built-in PLAIN or SCRAM server implementations in Apache Kafka.

Versions affected	0.10.0.0 to 0.10.2.1, 0.11.0.0 to 0.11.0.1
Fixed versions	0.10.2.2, 0.11.0.2, 1.0.0
Impact	This issue could result in privilege escalation.
Issue announced	26 July 2018

Last modified October 28, 2026: MINOR: Add October 2026 CVE entries to the CVE list (#932) (e6cb1ef29f)