Apache Kafka Vulnerabilities by Version: CVEs for Kafka 2.8, 3.x and 4.x

The short answer

The Kafka downloads page lists three supported releases: 4.3.1 from 25 June 2026, 4.2.2 from 29 September 2026 and 4.1.2 from 17 March 2026. Every other line is archived, including 4.0, whose last release was 4.0.2 on 16 March 2026, and 3.9, the last line that can run with ZooKeeper, which stopped at 3.9.2 on 21 February 2026. Kafka publishes no end-of-life dates. The project aims for three releases a year and makes bug fix releases for supported releases only. Since June 2025 it has published seven CVEs. The 2025 fixes landed in 3.9.1 and 4.0.0, so every line from 3.8 down has no fix for them.

Kafka release lines and their CVEs

Each row lists the CVEs announced since 2024 that name the line as affected, and whether a release on that line carries the fix. Dates are from the Kafka downloads page.

For release and end-of-life dates on every line, see the Apache Kafka end of life tracker.

Notable Kafka CVEs by release line

Kafka's advisories carry no severity rating of their own. CVSS is NVD's own score where NVD has scored the record; for most Kafka records from 2024 onward the only CVSS 3.1 score is the one CISA-ADP added, marked CISA-ADP. None of these CVEs is in CISA's Known Exploited Vulnerabilities catalogue.

Two patterns cover most of the list. The first is configuration as an attack path: CVE-2023-25194, CVE-2025-27817, CVE-2025-27818, CVE-2025-27819 and CVE-2024-31141 all need someone who can set client or connector properties, usually through the Kafka Connect REST API or AlterConfigs. The second is authentication on the wire: CVE-2026-33557 and CVE-2024-56128 weaken OAUTHBEARER and SCRAM. CVE-2026-35554 and CVE-2026-33558 are client-side, so they are fixed by upgrading the kafka-clients library inside each application, not the brokers.

Kafka also lists the Log4j CVEs from December 2021. It says Kafka was not affected by Log4Shell, CVE-2021-44228, because it used Log4j 1.2.17 rather than Log4j 2. For the Log4j 1.x flaws such as CVE-2021-4104, which need a JMSAppender or JMSSink in the logging configuration, the advice was to remove those classes from the jar.

What each line gets

Kafka 4.1, 4.2 and 4.3

These are the supported lines. 4.1.2, 4.2.2 and 4.3.1 carry every fix above that applies to them. A broker on 4.1.0 or 4.1.1 that uses OAUTHBEARER should move to 4.1.2 now, or set sasl.oauthbearer.jwt.validator.class to BrokerJwtValidator, because CVE-2026-33557 lets anyone mint a token the broker accepts. CVE-2026-41115 needs no upgrade: Kafka found the code correct, changed the documentation instead, and advises reviewing group ACLs.

Kafka 4.0

4.0 is archived, and 4.0.2 is its last release. It has every fix that applies to it, so the reason to move is that later fixes will not reach it. 4.0 removed ZooKeeper mode, so 4.0 to 4.1 or later is a minor upgrade within KRaft.

Kafka 3.9

3.9 is the last line that can run with ZooKeeper, which is why clusters that still use ZooKeeper stop there. 3.9.1 fixed CVE-2025-27817, CVE-2025-27818 and CVE-2025-27819 and disabled JndiLoginModule and LdapLoginModule by default. For CVE-2025-27817 it added the org.apache.kafka.sasl.oauthbearer.allowed.urls system property, but on 3.9.1 it allows every URL unless you set it, while 4.0 defaults to an empty list. 3.9.2 added the client fixes for CVE-2026-35554 and CVE-2026-33558. Leaving 3.9 means migrating to KRaft first. See Kafka 3.9 end of life and the ZooKeeper to KRaft migration guide.

Kafka 3.4 to 3.8

None of these lines has a fix for the 2025 or 2026 CVEs. A cluster on 3.4.1 is exposed to CVE-2025-27818 through Connect and AlterConfigs, to CVE-2025-27817 in any client whose configuration an outside party can set, and to the SCRAM and ConfigProvider issues from 2024. 3.4.0 did disable JndiLoginModule by default, which is why CVE-2025-27819 stops at 3.3.2. 3.7 and 3.8 got the 2024 fixes in 3.7.1, 3.7.2 and 3.8.1, and nothing after. See Kafka 3.8 end of life.

Kafka 3.3 and older, including 2.8

These lines add CVE-2025-27819 and CVE-2023-25194 to the list, both JNDI attacks through SASL JAAS configuration. 2.8.2, 3.0.2, 3.1.2 and 3.2.3 fixed CVE-2022-34917, an unauthenticated memory exhaustion bug, so the first check on any of them is the exact patch release. These lines also run on ZooKeeper, often an ensemble as old as the brokers; see ZooKeeper for Kafka and Kafka 2.8 end of life.

What to do on each line

• 4.1 to 4.3. Stay on the latest patch release, and review group ACLs for CVE-2026-41115.
• 4.0. Move to 4.2 or 4.3 within KRaft.
• 3.9. Move to 3.9.2 if you are not there, set org.apache.kafka.sasl.oauthbearer.allowed.urls, and plan the KRaft migration.
• 3.8 and older. Upgrade to 3.9.2, or take patched builds from a supplier that backports fixes. Until then, restrict who can reach the Connect REST API and who holds AlterConfigs on the cluster resource, add LdapLoginModule to org.apache.kafka.disallowed.login.modules on 3.4 and later, run SCRAM only over TLS, and keep NetworkClient logging at INFO.
• Every line. Upgrade kafka-clients in producer applications to 3.9.2, 4.0.2, 4.1.2 or later for CVE-2026-35554, whatever version the brokers run.

For how these CVEs fit with Kafka's wider security model, see Kafka security CVEs and EOL versions.

Where OSSeva fits

OSSeva backports Kafka security fixes to the 2.8, 3.0, 3.3, 3.6, 3.7, 3.8 and 3.9 lines, covering both brokers and client libraries, in ZooKeeper or KRaft mode, and patches 4.x as well. They are available now on the Patch, Assure and Operate tiers. Patch covers the brokers and client libraries, and Assure and Operate add patches for Kafka Connect and Kafka Streams, which matters for CVE-2025-27818 and CVE-2023-25194. Assure also adds a cluster configuration audit and a compliance attestation package, and Operate adds 24/7 broker and consumer-lag monitoring with a 15-minute P1 response. See Apache Kafka support.