Apache Kafka End of Life Versions: Which Are EOL and What To Do

Apache Kafka EOL Version Reference

Apache Kafka's community support model is less rigidly defined than PostgreSQL's 5-year lifecycle, but the practical support window for any given minor version is approximately 12–18 months from the release of the next minor version. Versions that have passed their community-supported window:

• Kafka 2.0–2.8: All 2.x versions are past their community window. No security patches are released for any 2.x version.
• Kafka 3.0, 3.1, 3.2, 3.3: Past community support window
• Kafka 3.4, 3.5: Approaching or past community support window
• Kafka 3.6, 3.7, 3.8: Currently within community support window

The Kafka project does not publish formal EOL announcements the way PostgreSQL does, but the practical effect is the same: when the community moves on, CVE fixes go to the current release line only.

What Changed with KRaft (Kafka Without ZooKeeper)?

Kafka 3.3 introduced KRaft mode as generally available, replacing Apache ZooKeeper as the metadata management layer. Kafka 3.8 removed ZooKeeper-based cluster support for new clusters. This creates a double challenge for enterprises on Kafka 2.x:

1. The version is EOL and unpatched
2. The migration path to a current version may require transitioning from ZooKeeper to KRaft, which is an operational change with its own testing requirements

OSSeva's Kafka extended lifecycle support covers Kafka 2.8 through 3.5 with both ZooKeeper and early KRaft configurations.

Confluent Platform and Kafka EOL

Many enterprises running "Kafka" are actually running Confluent Platform, which adds Schema Registry, Control Center, tiered storage, and RBAC on top of the community Kafka core. Confluent Platform has its own version lifecycle that doesn't perfectly align with community Kafka versions.

Key point: if you are running Confluent Platform, your CVE exposure depends on both the underlying Kafka version and Confluent's own patching for their proprietary components. Confluent Platform pricing — typically $1.00–$4.00 per GB of throughput — makes it one of the more expensive infrastructure line items for data-heavy enterprises.

OSSeva's Confluent exit program replaces Confluent Platform with OSSeva-supported community Kafka, typically reducing annual costs by 60–80% while maintaining equivalent security coverage and compliance documentation.

The FedRAMP Problem with EOL Kafka

Government agencies and contractors operating Kafka within a FedRAMP boundary face a specific challenge: the System Security Plan (SSP) and Plan of Action & Milestones (POA&M) must document known vulnerabilities and remediation timelines. An EOL Kafka version with disclosed CVEs and no authorized patch source is a POA&M item that can threaten ATO maintenance if not resolved.

OSSeva has worked with federal agencies to provide FedRAMP-aligned patch documentation and hardened Kafka builds with STIG-compatible configurations, resolving POA&M items that had been open for months.

JVM Considerations for Kafka on EOL Java

Kafka 2.x and early 3.x versions were typically deployed on Java 11, which itself reached Oracle end-of-premier-support in 2023. Enterprises running Kafka on Java 11 may have compounding EOL exposure: an EOL Kafka version on an EOL JVM. OSSeva coordinates Java and Kafka patch coverage for customers in this situation.

What To Do

For Kafka, the migration path depends on your architecture:

• Community Kafka 2.x → Kafka 3.8+: Possible with ZooKeeper-to-KRaft migration. OSSeva provides a migration playbook for this path with staged cutover guidance.
• Confluent Platform → OSSeva community Kafka: OSSeva's Confluent exit program handles Schema Registry migration, connector compatibility, and consumer group preservation.
• Extended lifecycle support during migration: OSSeva patches Kafka 2.8–3.5 with backported CVE fixes, providing compliance documentation and CVE attestations for the duration of your migration timeline.