CVE-2026-115644

Overview

Apache Kafka is an open-source distributed event streaming platform used for high-throughput, fault-tolerant data pipelines and stream processing. It stores records in partitioned, replicated, append-only logs on a cluster of brokers, and exposes producer, consumer, admin, Streams, and Connect APIs for publishing, subscribing to, and processing those records. The Java client and server components are published as Maven artifacts under org.apache.kafka.

An authorization bypass vulnerability (CVE-2026-115644) has been identified in the Kafka Connect REST server, which allows attackers with network access to a separately configured admin listener to read and change worker logger levels without authenticating. The REST extensions that secure the main listener, such as BasicAuthSecurityRestExtension, are never applied to the admin listener.

Per OWASP: Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits.

This issue affects multiple versions of Apache Kafka, from 2.4.0 up to but not including 4.2.2, and from 4.3.0 up to but not including 4.3.2.

‍

Details

Module Info

• Product: Apache Kafka
• Affected packages: org.apache.kafka:connect-runtime
• Affected versions: >=2.4.0 <4.2.2, >=4.3.0 <4.3.2
• GitHub repository: https://github.com/apache/kafka
• Published packages: https://central.sonatype.com/artifact/org.apache.kafka/connect-runtime
• Package manager: Gradle
• Fixed in:
  • OSS Apache Kafka 4.2.2, 4.3.2, 4.4.0
  • NES for Apache Kafka

Vulnerability Info

This Low-severity vulnerability is found in the org.apache.kafka:connect-runtime package in multiple versions of Apache Kafka. Kafka Connect lets operators secure its REST API with REST extensions listed in rest.extension.classes, such as BasicAuthSecurityRestExtension, which add authentication and authorization filters to the Jersey application. Operators can also move the admin endpoints (/admin/loggers) onto their own listener by setting admin.listeners.

When the REST server builds its resources, it registers the configured extensions on the main listener's ResourceConfig only. If admin.listeners is set to a separate listener, a new ResourceConfig is created for it with just the JSON provider, the logging resource and the exception mapper, and no extensions are ever registered on it:

registerRestExtensions(herder, resourceConfig);

List<String> adminListeners = config.getList(WorkerConfig.ADMIN_LISTENERS_CONFIG);
ResourceConfig adminResourceConfig;
if (adminListeners == null) {
    adminResourceConfig = resourceConfig;
    adminResourceConfig.register(new LoggingResource());
} else if (adminListeners.size() > 0) {
    adminResourceConfig = new ResourceConfig();
    adminResourceConfig.register(new JacksonJsonProvider());
    adminResourceConfig.register(new LoggingResource());
    adminResourceConfig.register(ConnectExceptionMapper.class);
}

The admin servlet is then served from this unprotected ResourceConfig. The main listener enforces the extension's filters, but requests to the admin listener never pass through them, so /admin/loggers accepts unauthenticated requests. An attacker who can reach the admin listener can list every logger and its level, which discloses loaded class names and the security extensions in use, and can set logger levels, for example turning the root logger off to suppress logging or to TRACE to flood the logs, which degrades the worker's observability and availability.

‍

Mitigation

Only recent versions of Apache Kafka are community-supported. Older lines are End-of-Life and will not receive public updates to address this issue. The Apache Kafka project does bugfix releases only for the last three minor releases; see the project's time-based release plan.

Users who cannot upgrade immediately can leave admin.listeners unset, so the admin endpoints share the main listener and its REST extensions.

Users of the affected components should apply one of the following mitigations:

• Upgrade Apache Kafka to a currently supported release that contains the fix, such as 4.2.2.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

‍

Credits

• Bartłomiej Dmitruk from Striga (finder)