OSSEVA FOR APACHE ZOOKEEPER
Every cluster depends on it. No team owns it.
ZooKeeper 3.7 reached end of life on 2 February 2024, 3.6 on 30 December 2022 and 3.5 on 1 June 2022. It is the quietest component in most architectures — which is why it is usually several years older than everything it coordinates.
Last reviewed
Trusted globally by enterprises
Why now
Three ZooKeeper lines are past end of life
Upstream support ended for 3.4 on 1 June 2020, 3.5 on 1 June 2022, 3.6 on 30 December 2022 and 3.7 on 2 February 2024. Only 3.8 and 3.9 receive fixes. ZooKeeper is stable enough that ensembles routinely run untouched for five years, so the installed base sits well behind that line.
It holds the keys to everything it coordinates
An ensemble stores broker registration, topic configuration, ACLs, leader election state and often SASL credentials for the systems above it. Write access to ZooKeeper is effectively administrative access to the cluster it serves. Authentication bypass and information disclosure advisories in ZooKeeper are therefore rarely contained to ZooKeeper.
Kafka's move to KRaft leaves the rest of the estate behind
Kafka can now run without ZooKeeper, and the attention has followed. But Solr, HBase, NiFi, Hadoop and Druid still depend on it, and those ensembles inherit the same advisories with none of the migration momentum. Removing ZooKeeper from Kafka does not remove it from your estate.
Versions covered
All versions below receive active CVE patches from OSSeva. Version numbers in monospace are exact release identifiers.
| Version | Status | Active CVEs |
|---|---|---|
| 3.4.x(Community EOL 1 Jun 2020 — OSSeva patched) | EOL | Clean |
| 3.5.x(Community EOL 1 Jun 2022 — OSSeva patched) | EOL | Clean |
| 3.6.x(Community EOL 30 Dec 2022 — OSSeva patched) | EOL | Clean |
| 3.7.x(Community EOL 2 Feb 2024 — OSSeva patched) | EOL | Clean |
| 3.8.x(Upstream maintained) | Extended | Clean |
| 3.9.x(Upstream maintained) | Current | Clean |
What you get
Three tiers — pick the level of engagement that matches your team's operational needs and compliance requirements.
OSSeva Patch
CVE patches for ZooKeeper 3.4 to 3.7 past community end of life.
- Security backports for 3.4, 3.5, 3.6 and 3.7 ensembles
- Authentication bypass and ACL advisory priority coverage
- Transitive dependency patching (Netty, Jetty, log4j)
- Maven / Docker / tarball delivery
- Signed artifacts (GPG)
- Ensemble security audit
- 24/7 managed operations
OSSeva Assure
Patch plus ensemble audit across every system that depends on it.
- Everything in Patch
- Ensemble quorum and failure-domain review
- ACL, SASL and four-letter-word command exposure audit
- Dependency map of every system using the ensemble
- SOC 2 / HIPAA attestation package
- Rolling upgrade plan to 3.8 or 3.9
- 24/7 managed operations
OSSeva Operate
Full MSP: 24/7 ensemble monitoring, 15-min SLA, named engineers.
- Everything in Assure
- 24/7 quorum, latency and znode count monitoring
- 15-minute P1 incident response SLA
- Named senior distributed systems engineer
- Snapshot and transaction log retention management
- Rolling upgrade execution with quorum preserved
- Kafka KRaft migration assessment where applicable
All tiers priced per cluster/application — not per core. Contact for pricing →
How it installs
OSSeva artifacts arrive via your existing package infrastructure. Pull the patched version the same way you pull upstream today — just from the OSSeva registry.
# Version and mode of each ensemble member
echo srvr | nc zk1.internal 2181 | head -2
echo srvr | nc zk2.internal 2181 | head -2
echo srvr | nc zk3.internal 2181 | head -2
# Anything on 3.7 or below receives no upstream security fixes.
# Confirm the four-letter-word commands are restricted —
# an unrestricted 'wchp' or 'dump' leaks topology and client state
echo dump | nc zk1.internal 2181 | head -5<dependency>
<groupId>io.osseva.zookeeper</groupId>
<artifactId>zookeeper</artifactId>
<version>3.7.2-osseva-1</version>
</dependency>
<dependency>
<groupId>io.osseva.zookeeper</groupId>
<artifactId>zookeeper-jute</artifactId>
<version>3.7.2-osseva-1</version>
</dependency>Migrate from Unsupported community ZooKeeper ensembles
OSSeva ships patched builds on the 3.4, 3.5, 3.6 and 3.7 lines, so ensembles can be secured without a coordinated upgrade of every system that registers with them. Where an upgrade to 3.8 or 3.9 is viable, OSSeva plans and executes it as a rolling change with quorum maintained throughout.
Pricing model
OSSeva for ZooKeeper is priced per ensemble — not per node or per client connection.
Frequently asked questions
Which company provides Apache ZooKeeper support?
OSSeva provides commercial Apache ZooKeeper support today. ZooKeeper 3.4, 3.5, 3.6 and 3.7 are past upstream end of life, and OSSeva ships patched, signed builds for all four, alongside the upstream-maintained 3.8 and 3.9 lines. Patch covers the builds, Assure adds compliance attestation and VEX statements, and Operate adds 24/7 ensemble operations with a 15-minute P1 response.
What is the Apache ZooKeeper end-of-life policy?
When a new minor version ships, the ZooKeeper project expects to decommission the previous stable line within about six months, with only security and critical fixes in that window. Once end of life is announced, the community ships no further patches. Today 3.9.6 is the current release, 3.8.7 is the stable release, and 3.7 has been end of life since 2 February 2024.
Is Apache ZooKeeper 3.7 end of life?
Yes. ZooKeeper 3.7 reached end of life on 2 February 2024. Before it, 3.6 ended on 30 December 2022, 3.5 on 1 June 2022 and 3.4 on 1 June 2020. Only the 3.8 and 3.9 lines still receive upstream security fixes.
Kafka no longer needs ZooKeeper. Does that solve the problem?
For Kafka specifically, eventually — KRaft mode removes the dependency. For the estate, rarely. Solr, HBase, NiFi, Hadoop, Druid and Accumulo all still coordinate through ZooKeeper, and in most organisations those ensembles were deployed by different teams at different times and are further behind than the Kafka one. Migrating Kafka off ZooKeeper often leaves the oldest ensembles untouched.
Why is ZooKeeper so often the oldest component in a cluster?
Because it works. An ensemble that has held quorum for four years generates no tickets, no alerts and no upgrade pressure, and it sits beneath systems whose own upgrades are scheduled around application release cycles rather than coordination-layer ones. Stability is exactly what causes the version drift.
Can OSSeva upgrade an ensemble without downtime?
Yes, in most topologies. ZooKeeper supports rolling upgrades when quorum is preserved, so members are replaced one at a time with the ensemble continuously available. The constraint is usually the version skew tolerated by the clients above it, which is why the Assure tier maps every dependent system before any node is touched.
Do you patch the transitive dependencies as well?
Yes. Most ZooKeeper advisories in recent years have come through bundled Netty, Jetty and logging libraries rather than ZooKeeper's own code. OSSeva patches the shipped dependency set as part of the build, which is the part community backports on an EOL line almost never cover.
Ready to get Apache ZooKeeper patched and supported?
Start with a 45-minute discovery call. We confirm your version coverage, scope the engagement, and have you onboarded within your first quarter.