The Kafka CVE Register, 2026 Edition: Every Apache Kafka Vulnerability by Version

Severity is the CVSS v3 base score published through NVD: Apache's score where the Apache Software Foundation is the CVE's naming authority, which covers every row from 2024 on, and NVD's own primary score for the older ones. Apache's list itself gives no scores. Where two sources disagree this register keeps Apache's: CVE-2026-33557 is 9.1 Critical from Apache and 8.6 High from a second source. The two Critical rows are one live Kafka flaw and one in a bundled logging library.

Disclosure has run at one to four a year, and it comes in clusters: three Log4j 1.x advisories on 18 January 2022, three SASL and client advisories on 9 June 2025, and four between 7 April and 2 June 2026. The broker and its authentication code carry the most rows, but the recent ones sit in the clients, which every application embeds and patches on its own schedule.

The component decides who has to patch. A broker or Connect fix is an upgrade of the cluster. A kafka-clients fix means every producer and consumer application has to rebuild with a newer library, which is why CVE-2026-35554 and CVE-2026-33558 outlive the broker upgrade in many estates. The four Log4j 1.x rows are a bundled library, and Kafka 4.0 moved to Log4j 2, so they apply to 3.x and earlier.

The 22 entries fall into six kinds of security vulnerability, and the kind tells you what an attacker needs before the flaw matters.

• Remote code execution through SASL JAAS login modules. CVE-2023-25194, CVE-2025-27819 and CVE-2025-27818 let a user who can set a SASL-based security protocol configuration point sasl.jaas.config at a JNDI or LDAP login module. On the Kafka Connect server that can end in unrestricted deserialization of untrusted data, with gadget chains on the Kafka Connect classpath turning it into remote code execution. Each needs write access to connector or cluster configuration, so the exposure is REST API access to Kafka Connect and who can reach it; reconfigure the worker so that only trusted operators can create connectors, and review every Kafka cluster that exposes the API.
• Server-side request forgery (SSRF) and arbitrary file read. This vulnerability was identified in Apache Kafka clients: CVE-2025-27817 and CVE-2024-31141 let an untrusted party who controls Kafka client configuration read files and environment variables, or make requests to unintended places, through sasl.oauthbearer.token.endpoint.url, sasl.oauthbearer.jwks.endpoint.url and the ConfigProvider classes. Apache Kafka clients accept configuration data that Connect passes through from its REST API, so they matter most where Kafka Connect or a SaaS product accepts client configuration from users.
• Authentication and authorization weaknesses. CVE-2026-33557 (forged JWT accepted), CVE-2024-56128 (SCRAM replay), CVE-2018-17196 (ACL bypass for transactions), CVE-2017-12610 (impersonation), CVE-2024-27309 (ACLs ignored during a ZooKeeper to KRaft migration), CVE-2021-38153 (timing attack on credential checks), CVE-2018-1288 (replication interference) and CVE-2026-41115 (a group describe permission that the documentation described wrongly).
• Denial of service. CVE-2022-34917 lets unauthenticated clients exhaust broker memory, and CVE-2023-34455 does the same through a Snappy-compressed record from any user who can produce.
• Information exposure and data integrity. CVE-2026-33558 and CVE-2019-12399 leak credentials and secrets, and CVE-2026-35554 can deliver messages to the wrong topic. The client-side rows are fixed only when each application's own kafka-clients jar is upgraded, not by upgrading the Kafka brokers.
• Bundled logging library. The four Log4j 1.x entries (CVE-2021-4104, CVE-2022-23302, CVE-2022-23305 and CVE-2022-23307) need control over logging appenders or configuration and have no Kafka fix; Kafka 4.0 moved to Log4j 2.

Where a row names a system property, Apache gives it as the mitigation for users who cannot upgrade yet: org.apache.kafka.disallowed.login.modules, org.apache.kafka.sasl.oauthbearer.allowed.urls and org.apache.kafka.automatic.config.providers.

Three Kafka vulnerabilities are remote code execution (RCE) bugs reached through the SASL JAAS configuration. CVE-2023-25194 sits in the Kafka Connect API, and CVE-2025-27818 and CVE-2025-27819 extend the same attack to the brokers. All three need an authenticated user who can set a Kafka client SASL JAAS config, so the risk sits with whoever can create or modify connectors or alter cluster configuration, not with anonymous clients. The table is taken from the Apache Kafka CVE list.

To check a Kafka Connect worker, work through four steps. First, compare the worker version with the table. Second, look for producer.override.sasl.jaas.config, consumer.override.sasl.jaas.config and admin.override.sasl.jaas.config in connector configurations, because those are the properties an operator uses to set a login module. Third, confirm the login modules are disabled: Kafka 3.4.0 added the system property -Dorg.apache.kafka.disallowed.login.modules and disabled JndiLoginModule by default, and Kafka 3.9.1 and 4.0.0 disable both JndiLoginModule and LdapLoginModule by default. Fourth, limit who holds AlterConfigs on the cluster resource and who can call the Connect REST API.

Apache's advisory also explains why the Connect exposure depends on the version. Since Kafka 3.0.0, users can set these override properties on a Connect cluster running its out-of-the-box configuration. Before 3.0.0 they could not, unless the cluster was configured with a connector client override policy that permits them. Apache advises Connect users to validate connector configurations, allow only trusted JNDI configurations, and examine connector dependencies for vulnerable versions, upgrading the connector or the dependency. Its upgrade advice for the 2025 entries is to move to 3.9.1 or later.

CVE-2025-27817 lets an untrusted party who controls Kafka client configuration read files and environment variables, or send requests to an unintended location, through sasl.oauthbearer.token.endpoint.url and sasl.oauthbearer.jwks.endpoint.url. Apache lists it as affecting versions 3.1.0 to 3.9.0, fixed in 3.9.1 and 4.0.0. In Kafka Connect it can escalate access to the REST API into access to the filesystem, environment and URLs, which matters most where users other than your own team can submit connector configurations, such as a SaaS product. To configure the fix, set the JVM system property -Dorg.apache.kafka.sasl.oauthbearer.allowed.urls. In 3.9.1 it accepts all URLs by default for backward compatibility, and in 4.0.0 and later the default is an empty list, so you must list the allowed URLs explicitly. Apache's advice is to upgrade to 3.9.1 or later and set that property. See the Apache Kafka CVE list entry for CVE-2025-27817.

Each row counts the code CVEs in this register that affected a release of that series, how many a later release in the same series fixed, and how many have no fix on that line. The count leaves out the four Log4j 1.x rows, which have no Kafka fix on any release (the mitigation is removing the class from the jar), and CVE-2026-41115, which is a documentation correction. A series that shipped after a fix landed, such as 4.2 for the 4.1 bugs, is not counted as affected. The "no fix in the series" column is the one to read: on an archived line it is permanent, because the project only fixes its last three releases.

Affected and fixed versions are quoted from Apache's CVE list. A fixed version is the floor, not the target: later releases on the same line include every earlier fix. Rows from the same announcement day keep Apache's order. CVE-2021-44228 and CVE-2021-45046 (Log4j 2.x) are on Apache's list as not affecting Kafka, which uses Log4j 1.2.17 up to 3.9 and moved to Log4j 2 in 4.0; check any connector plugin that bundles its own Log4j 2.x jar. Kafka-adjacent software is covered in a separate table below.

CVE-2026-33557 (OAUTHBEARER, 4.1.0 and 4.1.1). Brokers that enabled OAUTHBEARER on 4.1.0 or 4.1.1 accepted a JWT from any issuer, with any user in preferred_username. Apache's advice is to set sasl.oauthbearer.jwt.validator.class to org.apache.kafka.common.security.oauthbearer.BrokerJwtValidator explicitly or upgrade to 4.1.2, 4.2.0 or later. Kafka 4.4 goes further: the broker now fails at startup when a JWKS endpoint is configured but the expected audience or issuer is not set, per the 4.4 upgrade notes.

CVE-2026-35554 (producer misrouting, up to 4.1.1). It needs a batch to expire on delivery.timeout.ms while its request is still in flight. The client reports no error. It is the CVE most likely to survive a broker upgrade, because it lives in the application's kafka-clients jar: 3.9.2, 4.0.2, 4.1.2 and 4.2.0 or later fix it.

CVE-2024-27309 (ZooKeeper to KRaft migration, 3.5.0 to 3.6.1). Removing an ACL during a migration can leave DENY rules ignored. Anyone planning the move should be on 3.6.2 or later, and Apache's current migration instructions require 3.9.1 anyway. The step-by-step migration runbook covers the sequence.

CVE-2026-41115 (consumer group describe, 4.0.0 to 4.3.0). Not a code defect by Apache's account: the API checks DESCRIBE on the group, and the documentation and KIP-848 said READ. Apache's advice is to review existing group ACLs against least privilege. The list shows the affected range as the fixed range, because the change was to the documentation.

Scanners also flag software that runs around Kafka, and it is not on Apache's list. The table below is the result of an NVD keyword search for "kafka" for CVEs published between 1 June and 28 October 2026, limited to Kafka-specific products. It is not exhaustive, scores are the highest NVD shows for the product, and the vendors' own advisories are the authority on fixed versions. Cloud services such as Confluent Cloud and Amazon MSK patch on their own schedule and are out of scope.

Apache fixes its last three releases and nothing older, and the register shows what that costs. A cluster on 3.8 or earlier cannot get the fixes for CVE-2025-27817, CVE-2025-27818, CVE-2026-33558 or CVE-2026-35554 from the project, because they exist only in 3.9.1 and later. A cluster on 3.9 is covered to 3.9.2 but cannot move to 4.x without first migrating from ZooKeeper to KRaft. Kafka 4.1.2, archived but protected against everything listed here, will not receive a fix for whatever is disclosed next.

Where an upgrade cannot happen before the next disclosure, the options are a backport or compensating controls. Apache's advisories carry workarounds for many rows: keep SCRAM on TLS, set org.apache.kafka.disallowed.login.modules, set org.apache.kafka.sasl.oauthbearer.allowed.urls, pin the OAUTHBEARER validator class, and set org.apache.kafka.automatic.config.providers=none where untrusted users control client config. AceMQ's OSSeva service publishes patched builds of Apache Kafka 3.9, 3.8, 3.7, 3.6, 3.3, 3.0 and 2.8 after upstream support ends, per its site on 28 October 2026. Its Kafka page tracks CVEs in bundled dependencies as well, a wider scope than this register. For incident response and upgrade planning on the version you run, see Kafka support.

Three questions rank any row for a given estate. Is an affected series running in your estate? Check broker, Connect and every application's kafka-clients version separately; they rarely match. Is the vulnerable surface exposed? Several rows need a specific precondition: OAUTHBEARER enabled, SASL JAAS configured by users, DEBUG logging on, SCRAM without TLS, or a migration in progress. Confirm it applies before treating every row as equally urgent. Is the fixed version current? The fixed column is a floor; the target is the latest patch release on a supported line, which on 28 October 2026 is 4.4.0, 4.3.2 or 4.2.2.

The production readiness checklist turns the security rows into checks 25 to 28.

Sources. Apache's Kafka CVE list, last modified 2 June 2026, for IDs, announcement dates and affected and fixed versions; NVD for every CVE's CVSS v3 score and publication record; the Apache Kafka downloads page for the release list and supported releases; the 4.4 upgrade notes for the OAUTHBEARER startup check and the Log4j 2 move in 4.0. Descriptions in the register's Summary column are AceMQ's wording of Apache's advisories.

Scope. The 22 CVEs on Apache's list that affect Apache Kafka, announced between 26 July 2018 and 2 June 2026. Two Log4j 2.x entries on the list that Apache says do not affect Kafka are excluded. Advisories in dependencies, in Confluent Platform, and in managed services are out of scope; Apache keeps a separate dependency page. The series counts use the releases listed on the downloads page on 28 October 2026.

Date checked. 28 October 2026. A search of NVD for "kafka" found no new Apache Kafka CVE published after CVE-2026-41115 on 2 June 2026. New advisories publish without notice, so check Apache's live list before a compliance submission. This page is re-issued when Apache adds an entry.