How to track Apache Kafka CVEs and security releases
If you run a self-hosted Kafka cluster, you need to track the project's supported releases and patch both brokers and clients on a planned cycle. Apache Kafka is licensed under the Apache License 2.0 and has no paid edition, so security fixes reach you only through the project's own release and bugfix policy. Nobody sends you a vendor patch notice, so the job of finding out what is fixed, and in which release, falls to your team or to a partner you engage.
The project's downloads page lists the releases it currently supports, and it is the first place to check. Bugfix releases are made only for supported releases, and older versions are archived. Confirm which 4.x line your brokers run, then confirm that line is still supported before you schedule work. Also watch the project's time-based release plan, which states that rolling upgrades are supported from each release in the past year to the latest version. If a cluster sits outside that window, the upgrade becomes a prerequisite for the security fix, not an option.
Patching has to cover clients as well as brokers. The recent OAUTHBEARER validation flaw in the client-side code is a reminder that a fix can land in a library your applications, Connect workers and Kafka Streams jobs bundle, even when the broker is current. Inventory every service that embeds a Kafka client, record its version and build pipeline, and decide who rebuilds and redeploys each one. In-house teams usually need a monitored advisory feed and a named owner per component, while a partner can run that watch and prepare the upgrade plan. Ask any partner for written scope on advisory monitoring, test environments and the rollout window before work starts.
Which Kafka releases receive security fixes
The Kafka project publishes a small set of supported release lines and fixes only those. Knowing which line you run, how often new releases arrive and how far a rolling upgrade can reach determines how quickly a security fix can reach your cluster.
Supported release lines
The downloads page lists 4.3.1 (June 25, 2026), 4.2.2 (September 29, 2026) and 4.1.2 (March 17, 2026) as the supported releases. Check which of these lines your brokers and clients run, and confirm the current list on the downloads page before each patch window, since the list changes as new releases ship. A cluster on a line not in this list will not receive project fixes.
Archived earlier versions
All versions earlier than the supported lines are archived. The project does not make bugfix or security releases for them, so a cluster still running an archived version carries known issues with no upstream fix. Plan a move onto a supported line rather than waiting for a patch that will not come. Treat any archived version found in an inventory as a finding that needs an owner and a date.
Bugfix releases on demand
The project makes bugfix releases as needed, and only for supported releases. There is no fixed patch day, so security fixes arrive whenever the project ships one. Subscribe to the project's release announcements and watch the repository's releases, then decide in advance how quickly your team will test and roll out a bugfix on each line you run.
Four-month release cadence
The project aims for three feature releases a year, one every four months. Each feature release moves the supported window forward, so a line that is current today will fall out of support on a predictable cycle. Build a standing review that compares your running version against the downloads page at least once per release cycle, so a version falls behind on your schedule rather than by surprise.
Rolling upgrade range
The time-based release plan says rolling upgrades are supported from each release in the past year, which is the last three releases, to the latest version. A cluster that is more than three releases behind may need a staged path instead of a single rolling step. Confirm the exact supported path in the upgrade notes for your target version before you schedule a security upgrade.
Where to watch for Kafka CVEs and fixed releases
Start with the sources the Apache Kafka project itself publishes, because a CVE feed alone will not tell you which release contains the fix. The Kafka downloads page lists the supported releases, currently 4.3.1, 4.2.2 and 4.1.2, and marks earlier versions as archived. The project makes bugfix releases only for supported lines, so a version that falls outside that list is one you should plan to leave, not just patch. Pair that page with the Time Based Release Plan, which shows the cadence of new feature releases and the upgrade window the project supports. Watch the upgrade notes for each line as well, since they record breaking changes that affect how a patch must be applied. The apache/kafka repository on GitHub shows fix activity before a release is cut, so a security-relevant commit merged to a branch tells you a release is coming and which code path changed.
Treat every advisory as a question about exact versions, not a headline. For each CVE, record the affected version range, the fixed release on each supported line, and whether your deployment actually runs the affected component, such as the broker, Kafka Connect, the tools or a client library. Confirm those details with the project's published security information before you act on them, and keep the confirmation with the ticket. Do not assume that a fix on one release line applies to another, and do not assume that because your broker is current, your clients are too. Build the mapping into a short, dated register that your patch owner updates whenever a new advisory or release appears.
The OAUTHBEARER validation flaw is a useful example of why client libraries belong on the watch list. Clients and applications that bundle their own Kafka client libraries can carry a vulnerable version even when the brokers are current, so inventory the client jars and language libraries in each service alongside the broker versions. Confirm the affected client versions, the fixed client releases and any configuration that reduces exposure with the project before you state them in an internal advisory or change request. Then assign separate owners for broker and client patching, because the rollout order and the testing burden differ.
How to patch brokers, controllers and clients in order
This sequence moves a Kafka estate from a known vulnerable release to a supported patched release without breaking producers, consumers or stream processors. Each stage ends with a check you can record as evidence.
Inventory every component and version
The platform team lists every broker, KRaft controller, Kafka Connect worker, command-line tool host, Kafka Streams application and client library in use, including the version and Java runtime of each. Owners of Connect workers and Streams applications often sit outside the platform team, so the inventory should name them. The step is done when every running component has a version, an owner and a deployment location recorded in one place.
Confirm the target supported release
Check the Kafka downloads page for the releases the project currently supports and the bugfix notes for each. Identify the lowest supported release that contains the fix for each CVE or security issue affecting your estate, and prefer the newest patch level within your current minor line. Confirm the upgrade path in the upgrade notes, including the rolling upgrade range from the time-based release plan and the Java version each component needs. The step is done when you have a written target version per component and a note on any Java change.
Rehearse the upgrade on a staging cluster
Build a staging cluster that mirrors production topology, with the same KRaft layout, listener and authentication settings, and a representative set of topics and client applications. Run the upgrade from the current version to the target, then replay producer and consumer traffic and confirm that client authentication, ACLs and TLS still behave as expected. Record any configuration keys that were deprecated or changed. The step is done when staging reaches the target version with no unexplained errors in broker and controller logs.
Roll controllers and brokers one node at a time
Upgrade KRaft controllers first, then brokers, restarting one node at a time so that partitions stay available. Before each restart, confirm the cluster has no under-replicated partitions and that the node you are about to stop is not the last in-sync replica for any partition you care about. After each restart, wait for the node to rejoin and for the under-replicated count to return to its baseline. The step is done when every controller and broker reports the target version and the cluster is healthy.
Check broker health and client connections
Once all brokers run the target release, verify cluster health across the full set: under-replicated and offline partitions, leader balance, request error rates and authentication failures in broker logs. Watch for client connection errors that indicate a mismatch in TLS, SASL mechanism or protocol version after the restart. Keep the evidence, such as dashboards or command output with timestamps, for the change record. The step is done when the health indicators match the pre-upgrade baseline for a period your operations team agrees on.
Update Kafka Connect workers
Upgrade Connect workers after the brokers, because they run as clients and must match the supported broker range. Confirm Java 17 is installed on each worker, update the Kafka libraries and connector plugins they load, and restart workers in a rolling pattern so connector tasks rebalance without losing progress. Review the Connect REST API and connector override settings after the change, since security configuration can reset with a new install. The step is done when every worker runs the target version, all connectors report running and no task is in a failed state.
Update Streams applications, producers and consumers
Rebuild Kafka Streams applications and client applications against the target client library, confirming Java 11 or later at runtime. Roll them out service by service, starting with consumers and producers that carry the least business risk, and watch consumer lag and producer error rates after each release. Check that authentication settings, including SASL mechanism and TLS truststores, are present in every deployed configuration. The step is done when each application runs the patched library, consumer lag has returned to normal and no client logs repeated authentication or connection errors.
Record the change and close the advisory
Write a change record that lists each component, its prior and new version, the upgrade date, the checks passed at each stage and any exceptions. Keep the staging test results and the release notes that justify the target version. Update the inventory from the first step so it reflects the new state, and set a review date for the next release check. The step is done when the inventory, the change record and the security advisory tracker all show the same patched versions.
Why client libraries and Connect need patches too
The broker is not the only place a Kafka vulnerability can sit. Java clients, Kafka Streams applications, Connect workers, connector plugins and command-line tools each ship their own dependencies and run on their own JVM, and each is patched on its own schedule. A fixed broker can still leave an application exposed if the producer or consumer that talks to it bundles an older client library. Treat every artifact that opens a Kafka connection as part of the patch scope, not only the cluster in your data center.
Runtime requirements can turn a library update into a JVM change. Since Kafka 4.0, brokers, Kafka Connect and tools require Java 17, while clients and Kafka Streams applications need at least Java 11, according to the Apache Kafka upgrade notes. Before you schedule a client upgrade, confirm which Java version each application and worker image runs. Applications still on Java 8 or 11 may need a runtime upgrade before they can take a fixed client, so add that work to the plan rather than discovering it during the change window.
Connect deserves a separate inventory. List every third-party connector plugin on each worker, its version, the libraries it bundles and the team that owns it, then check each vendor or project for security releases. Confirm which Connect REST API access and connector override settings are in place, since a plugin update does not change them. Record the result in the same register you use for broker versions, so a single advisory lets you answer which clients, workers and tools are affected.
Which patching approach fits your team
This table compares three ways to keep Kafka brokers and clients patched: in-house work on a fixed window, a retainer for ongoing upgrades and testing, and a fixed-scope one-time upgrade with inventory. Read each row against your team's capacity, change process and how often you expect to move between supported releases.
| Approach | When it fits | Who runs the work | What you must provide |
|---|---|---|---|
| In-house patching on a fixed monthly window | Your platform team already runs Kafka, has spare capacity and can test each bugfix release in a staging cluster before production | Your engineers, following your change calendar | Staging cluster that mirrors production, a named owner for release tracking, and rollback steps for each broker and client |
| Retainer for ongoing upgrades and testing | You want a partner to watch releases, test fixes against your topology and handle rolling upgrades on a continuing basis | A DeployOpen team under a retainer agreement, working alongside your operators | Access to non-production and production environments, change approval contacts, and a current inventory of brokers, Connect workers and client applications |
| Fixed-scope one-time upgrade with inventory | You are behind supported releases, have not kept an inventory, or need a documented baseline before handing patching back to your team | A DeployOpen team under a written scope, with deliverables and timeline agreed before work starts | Cluster access, configuration files, a list of client libraries and Java versions, and a sign-off owner for the agreed scope |
Set up a Kafka security release process
This sequence turns Kafka patching from an ad hoc reaction into a repeatable routine with a named owner, a current inventory, a tested path to production and a written record of every change. Each step ends with an artifact that the next step depends on.
Assign a named owner and backup
Name one person accountable for tracking Kafka security notices and approving patches, plus a backup who can act when the owner is unavailable. Write the responsibilities into the platform runbook, including who may approve an emergency change and who informs the application teams that depend on the cluster. The step is done when the owner and backup have acknowledged the role in writing and both have access to the project channels and the change record.
Build a component inventory with versions
List every Kafka component you run: brokers, controllers, Kafka Connect workers, MirrorMaker 2 clusters, Schema Registry or other supporting services, admin tools, and the client libraries used by producers, consumers and Kafka Streams applications. Record the exact version of each, the Java runtime it uses, the host or namespace where it runs and the owning team. Include clients that teams package inside their own applications, since they are easy to miss. The output is a single inventory that the owner reviews before each release check.
Subscribe to project and repository notices
Subscribe the owner and backup to the Kafka downloads page and the release notices published by the Apache Kafka project, and watch the apache/kafka repository on GitHub for security-related issues and release tags. Confirm with the project how it announces security fixes, since the process for private disclosure and public advisories should be verified in the project's own documentation rather than assumed. The step is done when a test notice reaches the owner's inbox or channel and the notice source is listed in the runbook.
Check each release against the supported list
Compare every version in the inventory against the releases the project lists as supported on its downloads page. Mark any cluster or client on an archived version as a finding with a target release. Use the project release plan to see which upgrade paths are supported, because rolling upgrades are documented from each release in the past year to the latest version. For KRaft clusters on releases older than 3.3.x, the upgrade notes recommend moving to 3.9.x before 4.x. The output is a short findings list ranked by how far each component sits from supported status.
Verify the Java range for clients
Check the Java runtime of every application that uses a Kafka client against the minimum the upgrade notes give: brokers, Connect and tools require Java 17 from Kafka 4.0, and clients and Kafka Streams applications require at least Java 11. Flag applications packaged with an older runtime, and confirm with each owning team whether their container base image or application server limits the upgrade. The step is complete when every client has a recorded runtime and every gap has an owner and a planned fix.
Test patches in a staging environment
Apply the candidate release to a staging cluster that matches production in listener configuration, authentication, authorization and Connect workers. Run the producer, consumer and Streams workloads that matter most, and confirm that metrics, alerts and ACL-dependent access still behave as expected. Include a client-side test that proves the updated client library connects through each listener, because broker and client fixes may ship separately. The step ends with a signed test record listing what was tested, what passed and any known issues.
Schedule a patch window tied to the release cadence
Set a recurring patch window that follows the project's release rhythm, which the release plan describes as three releases a year, with bugfix releases made as needed for supported releases. Add an out-of-cycle path for urgent security fixes that the owner can invoke. Agree the window with the application teams and the platform change board, and publish it with the rollback steps and the criteria for skipping a window. Confirm the schedule with the change board in writing before the first window.
Record every change and review the outcome
After each patch, record the old and new versions, the date, the approver, the test record, the rollout order, any client changes and the post-change checks such as consumer lag and error rates. Update the component inventory so it reflects the new state, and close each finding from the supported-release check. Review the log at the next cadence review to confirm every cluster runs a supported release and no client falls outside the supported Java range. The step is done when the inventory and the change log agree.
Security risks when patching is delayed
Kafka exposure rarely comes from one bad release. It builds up when an archived version keeps running, when clients fall behind the brokers, when Connect workers stay reachable, or when a jump between versions is too large to roll. Each risk below has a check you can run now and a control that keeps it from returning.
Running archived releases
The downloads page lists 4.3.1, 4.2.2 and 4.1.2 as supported, and all earlier versions are archived. Archived releases no longer receive bugfix releases, so a cluster on one of them carries any known flaw indefinitely. Start by inventorying the exact version of every broker, Connect worker and tool in each environment, including copies that were deployed by a container image or a vendor package. Then set a written policy that only supported lines run in production, with a named owner for tracking the release notes.
Clients left behind after broker upgrades
Upgrading brokers does not upgrade the Kafka clients in producer, consumer and Kafka Streams applications. Those clients are often built into service images that nobody owns, so a flaw in a client library can stay live after the brokers are patched. Keep a registry of every application that embeds a Kafka client, with its library version and its owning team. Make client version bumps part of the same change calendar as broker releases, and verify each application after the bump.
Connect workers reachable through REST
The Kafka Connect REST API can create connectors and change their configuration, so anyone who reaches an unprotected worker can affect data movement and, through connector overrides, the worker itself. A patch cycle that only touches brokers leaves workers with the same exposure. Check which network segments can reach the REST port, confirm that the worker principal has only the ACLs it needs, and treat worker upgrades as security changes with their own review. Confirm the exact configuration keys against the Connect documentation for your version before you change them.
Unplanned version jumps
Rolling upgrades are supported from each release in the past year, up to the latest version, according to the Kafka time-based release plan. Skipping several releases or moving a KRaft cluster directly from an old line can break the rolling path and force a riskier maintenance window. Record the current version of each cluster, plan the sequence of intermediate releases before the target, and check the upgrade notes for each step. Clusters still on ZooKeeper must migrate to KRaft before moving to 4.x.
Patches applied without staging
A security release applied straight to production can introduce a regression in serialization, authentication or ACL behavior that only appears under real traffic. Staging the patch on a non-production cluster with the same listener and authorization setup lets you test authentication flows and client connections before the production roll. Keep a rollback plan for each step, and record which broker and client versions were tested together. This step is what turns a fast patch into a safe one.
Questions teams ask before patching Kafka
What drives the cost of patching a Kafka cluster?
The main drivers are how many clusters you run, how many client applications and Kafka Connect connectors depend on them, where each cluster sits on the Java and KRaft migration path, and how deeply you test before production. A single KRaft cluster with a short list of well-documented clients is a much smaller job than several clusters with dozens of connectors and custom plugins. Cost splits into assessment, the change itself, regression testing and post-upgrade verification. Ask any provider to price each of these separately, so you can see which parts are one-time and which recur with every security release. Ask for the list of assumed clusters, clients and connectors in writing before you compare quotes.
How long does a rolling Kafka upgrade take?
A rolling upgrade moves brokers one at a time so the cluster stays available, so its duration grows with broker count, the depth of your pre-production testing and how many change windows your organization needs. The Kafka time-based release plan says rolling upgrades are supported from each release in the past year, the last three releases, to the latest version, which tells you whether a jump is a single step or needs an intermediate release. Patch releases within a supported line are usually the simplest moves, while cluster-wide changes that cross a release line need more planning. Ask for a timeline built from your cluster inventory, not a generic figure, and confirm the rollback plan for each step.
Which Kafka versions still receive security fixes?
Check the downloads page of the Apache Kafka project for the current list of supported releases, because the list changes as new releases ship. The project makes bugfix releases as needed for supported releases only, and older versions are archived. If you run a release that is no longer listed, plan an upgrade before the next security advisory rather than after it. Also check which Java version each release needs, since brokers, Kafka Connect and tools require Java 17 from Kafka 4.0, and clients need at least Java 11. Your patch plan should name the exact release each cluster will move to.
Do we need to migrate off ZooKeeper before patching?
Yes, if any cluster still runs in ZooKeeper mode and you plan to move to Kafka 4.x. According to the Kafka upgrade notes, Apache Kafka 4.0 supports only KRaft mode and ZooKeeper mode has been removed, so ZooKeeper-based clusters must migrate to KRaft before upgrading to 4.x. The same notes recommend that KRaft clusters older than 3.3.x upgrade to 3.9.x before moving to 4.x. This means a cluster on an old line may need two or more steps, and each step adds testing and change windows. Inventory the mode and version of every cluster first, because that single fact often moves the effort more than anything else.
Can our own team patch Kafka without outside help?
Yes, many teams do, provided they have engineers who can run rolling restarts, read the upgrade notes for each step and validate producers and consumers after each broker moves. Kafka is open source under the Apache License 2.0, so there is no vendor license to buy for the software itself. The work that usually stretches internal teams is the verification: confirming client compatibility, checking Connect workers and plugins, and proving the change in the environment auditors will review. Be honest about on-call capacity during change windows. Outside help makes the most sense when the cluster count is high, the release gap is large, or the team has no recent Kafka upgrade history.
What does the client's team need to provide?
The engagement needs access to the cluster inventory, the upgrade and client dependency map, and staging environments that resemble production. Your team should supply named owners for each producing and consuming application, the Connect workers and plugins in use, and the change windows your organization permits. You will also need to confirm how brokers are deployed, whether through configuration management, containers or Kubernetes, and where certificates, keytabs and credentials are stored. Security and operations staff should review the rollback criteria before the first broker moves. Clear ownership on the client side is often the factor that decides whether a patch lands on schedule.
Do DeployOpen retainers cover ongoing Kafka patching?
DeployOpen offers ongoing support, upgrades and continuous testing as retainers, so a retainer can cover recurring patch work after the initial engagement. The exact scope, including how many clusters are covered, how security releases are triaged, how quickly work starts after a release, and which client applications are included, is set out in the written agreement. Engagements are generally fixed-scope, so the first patch project is priced from its own written scope. Ask for the retainer terms in writing and confirm what happens when a release crosses a major line, because that change usually needs a separate project. Do not assume that a retainer includes testing of your custom applications unless it is named in the scope.
How do we know a patch was applied correctly?
Confirm each broker reports the target version, check that the cluster has no under-replicated partitions after each restart, and run the same producer and consumer tests you use in staging against production after the change. Then verify that clients built on older libraries still connect, since client libraries are patched separately from brokers. Record the release version of every broker, client and Connect worker in your asset inventory, so the next advisory can be matched to real exposure. Keep the change record, test results and rollback decision together, because auditors and internal reviewers will ask for that evidence. DeployOpen prepares these controls and evidence, but independent auditors and certification bodies make any formal assessment.
How DeployOpen scopes and supports Kafka patching
DeployOpen agrees the patching scope in writing before any work starts. For a Kafka topic like this one, the written scope names the target release line, the brokers, the controllers, every client application and Kafka Connect worker in use, and who approves each change window. We inventory the running versions first, because a cluster often runs brokers on one release while Connect workers, Kafka Streams applications and producer libraries lag behind. The inventory records the Java runtime on each host as well, since brokers and Connect require Java 17 from Kafka 4.0 onward and clients require at least Java 11. Each item in the inventory gets an owner and a target version, which turns a security advisory into a concrete list of changes.
We run the upgrade in infrastructure you control, in your cloud accounts, data centers or restricted networks, and we keep the sequence within the project's supported upgrade path. Clients and Connect workers are upgraded and verified alongside the brokers, not treated as an afterthought, so that a client-side fix such as an OAUTHBEARER validation correction reaches every consumer. Before each change we confirm the release notes and the advisory against the versions you run, and we document the rollback point. Verification uses the test environment first, then a controlled production window, with checks on authentication, ACL behavior and consumer lag. Confirm with us whether the written scope includes the test cluster, the staging clients and the post-upgrade evidence you need for your own records.
Ongoing support and upgrades are available as retainers. A one-time patch engagement covers a known set of releases. A retainer covers the recurring work: watching the project's security releases, scheduling bugfix upgrades on the supported lines, and re-inventorying clients after new applications are onboarded. Ask any partner, including us, to state in the quote which items are one-time and which recur, how an out-of-cycle emergency fix is handled, and who holds the change approval. We do not hold certifications or partner status with the Apache Software Foundation, and we do not issue security attestations. For the project's own release and security information, read the Apache Kafka downloads page directly before you sign off on any scope.
