Apache Kafka's release cadence is fast. A new minor version ships roughly every four months. EOL dates arrive quickly — and because Kafka sits at the heart of data pipelines, teams are slower to upgrade than they are with application-layer software.

The result: a lot of production Kafka clusters running EOL versions handling compliance-critical data.

Kafka 3.6 reached end of life in April 2026. If you're on 3.5 or earlier, you're already past EOL.

Complete Kafka EOL Schedule

The community maintains the two most recent minor versions. Everything else receives no further security patches or bug fixes.

EOL Risk Score for Kafka 2.8: 84 Critical
View → endoflife.ai/score/apache-kafka/2.8

Why Kafka EOL Risk Is Different

Kafka isn't stateless. It stores your data.

An EOL web framework is a security risk. An EOL Kafka cluster is a security risk that also has custody of every message in your topics. CVEs affecting Kafka directly impact the confidentiality, integrity, and availability of your event streams.

Historically significant Kafka CVEs include:

• Authentication bypass vulnerabilities
• SCRAM authentication weaknesses
• Denial-of-service issues in the broker's request handling

In regulated industries — financial services, healthcare, any organization handling PII — an EOL Kafka cluster processing that data creates direct compliance exposure.

The ZooKeeper Story: The Biggest Change in Kafka's History

Kafka 4.0, released March 2025, removed ZooKeeper support entirely.

The timeline:

• Kafka 2.8 — KRaft mode introduced as early access
• Kafka 3.3 — KRaft mode production-ready
• Kafka 3.5–3.8 — ZooKeeper deprecated, migration tooling available
• Kafka 4.0 — ZooKeeper removed, KRaft required

If your cluster still uses ZooKeeper for cluster metadata, you cannot upgrade to Kafka 4.0 without first migrating to KRaft. And ZooKeeper itself has its own EOL considerations: ZooKeeper 3.6 reached EOL March 2024.

How to migrate ZooKeeper → KRaft (without downtime)

Kafka 3.7 and 3.8 support a live migration path:

# 1. Generate a new KRaft cluster ID
kafka-storage.sh random-uuid

# 2. Start the migration using the built-in migration tool
kafka-metadata-migration.sh --bootstrap-server localhost:9092   --cluster-id <your-kraft-cluster-id>

The migration runs while the cluster continues serving traffic. Once complete, the ZooKeeper ensemble can be decommissioned.

Kafka Rolling Upgrade Guide

Kafka supports rolling upgrades — upgrade brokers one at a time while the cluster continues serving traffic.

Step 1 — Control the protocol version

During a rolling upgrade, pin inter.broker.protocol.version to the previous version:

inter.broker.protocol.version=3.7

Only bump this after all brokers are on the new version. This allows mixed-version brokers to communicate safely during the upgrade window.

Step 2 — Upgrade one broker at a time

# Graceful shutdown of one broker
kafka-server-stop.sh

# Install new version, update config, restart
kafka-server-start.sh config/server.properties

Wait for the broker to rejoin and partition leadership to rebalance before proceeding to the next broker.

Step 3 — Update the protocol version

After all brokers are upgraded:

inter.broker.protocol.version=3.8  # your new version

Rolling restart to apply.

Step 4 — Check client compatibility

The Kafka protocol is backward-compatible, but broker upgrades may surface client-side issues. Update producers and consumers as part of the upgrade project, not after.

Check Your Full Data Stack

Kafka doesn't run in isolation. Check EOL status for:

• Java — Kafka 4.0 requires Java 11+, recommends Java 17 or 21
• Your Linux distribution — Ubuntu, RHEL, Debian all have EOL dates
• ZooKeeper — if you're still on it
• Kafka Connect plugins — each has its own version lifecycle

Use the EOL Checker at endoflife.ai to look up any component's EOL status.

Full article with EOL Risk Scores for every Kafka version: endoflife.ai/article-kafka-eol