EUVD-2026-112175
GHSA-pvjw-82p3-hmj7
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as low-privilege Kafka principal
-
DeliverySend IncrementalAlterConfigs targeting BROKER resource
-
ExploitEmbed ${file:} or ${env:} config variable
-
ExecutionConfigProvider resolves it before authorization check
-
ImpactResolved secret returned in validation error
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization checks on every request
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires (1) a cluster with a Kafka authorizer enabled - Apache states clusters without an authorizer are not affected because every principal already holds ALTER_CONFIGS; (2) a valid authenticated Kafka principal, which may have no authorization grants whatsoever (not even ALTER_CONFIGS); and (3) an IncrementalAlterConfigs or AlterConfigs request against a BROKER resource that references a configuration variable (${file:/path:key} or ${env:VAR}) resolved by a ConfigProvider such as FileConfigProvider or EnvVarConfigProvider. Limiting factors: exploitation needs valid credentials (not anonymous), the disclosure is bounded strictly by the broker process's OS file permissions, and only confidentiality is affected (no cluster availability or data-integrity impact). The resolution path bypasses the org.apache.kafka.automatic.config.providers allowlist introduced for CVE-2024-31141, so that prior mitigation does not limit this attack. |
| Impact | No CVSS vector, EPSS score, KEV entry, or PoC reference was supplied in the feed, so the real-world ranking leans on the vendor description, CWE-862 (Missing Authorization), and the vuln.today Decision label of 'this_week'. My independent reading of the mechanism is AV:N/AC:L/PR:L/UI:N with a confidentiality-only impact and a security-authority scope change (a Kafka-authenticated client reads OS-level host secrets), which lands in the High band (~7.7) - but note this is an assessment, not a vendor-published score, since CVSS is N/A in the input. The practical bar is low-but-not-zero: the Apache description explicitly requires an authenticated Kafka principal (no ACL grants needed, not even ALTER_CONFIGS), so this is an insider/stolen-credential exposure rather than a fully anonymous internet attack, and it only applies to clusters that actually run an authorizer - Apache states clusters with no authorizer are not affected in practice because every principal already holds ALTER_CONFIGS. The impact is pure disclosure (credentials, keystores, environment variables, arbitrary broker-readable files); brokers and cluster availability are unaffected, and there is no integrity impact. There is no exploitation-status conflict to resolve here because no KEV, EPSS, or PoC signal is present - the 'this_week' urgency is driven by the ease of triggering and the sensitivity of what leaks (it defeats the CVE-2024-31141 allowlist hardening), not by observed exploitation. Bottom line: a genuine priority for any Kafka deployment that runs an authorizer and stores secrets on broker hosts, but gated by the need for a valid principal; no public exploit identified at time of analysis. |
| Exploit ScenarioDerived | An attacker holding any valid Kafka credential with zero ACL grants (for example a leaked low-privilege service account) sends an IncrementalAlterConfigs request targeting a BROKER resource that embeds a configuration variable such as ${file:/etc/kafka/secrets/keystore.jks:key} or ${env:AWS_SECRET_ACCESS_KEY}. The broker resolves the variable through the named ConfigProvider during validation - before the authorization check - and returns the resolved file or environment-variable content inside a type-validation error. No public exploit identified at time of analysis; the trigger mechanism is described by the Apache advisory. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 28, 2026
Apache Kafka brokers that have an authorizer enabled will read a file or environment variable from the broker host and return its contents to any authenticated principal, including one holding no ACL grants at all - not even ALTER_CONFIGS. The flaw is a missing-authorization ordering problem (CWE-862): an IncrementalAlterConfigs or AlterConfigs request aimed at a BROKER resource reaches configuration validation, which resolves ${file:/path:key} or ${env:VAR} variables through a ConfigProvider instantiated from the request, before any authorization check is applied, and a type-validation error reflects the resolved secret back to the caller. This defeats the org.apache.kafka.automatic.config.providers allowlist introduced for CVE-2024-31141, but the read is bounded by the broker process's OS file permissions and impacts only confidentiality, not cluster availability or data integrity; there is no public exploit identified at time of analysis and the vendor-supplied fix set is Kafka 4.2.2, 4.3.2, and 4.4.0.
RemediationAI
Vendor-released patch: Apache Kafka 4.2.2, 4.3.2, and 4.4.0 - upgrade to the release matching your branch. In those versions broker configuration changes are authorized (ALTER_CONFIGS on the cluster) before the configuration is validated, and configuration-variable resolution enforces the config-providers allowlist, closing both the ordering flaw and the CVE-2024-31141 bypass; note that relying on the earlier allowlist alone is not sufficient on unfixed releases. As defense in depth, Apache advises running brokers under a least-privileged operating-system account so sensitive files are not readable by the broker process, which caps what any successful read can return - the trade-off is that brokers may then need explicit read access to keystores and truststores they legitimately use. Confirm whether an authorizer is enabled on each cluster to determine exposure, since clusters without one are not affected in practice. Advisory details are at https://kafka.apache.org/cve-list. Prioritization: the vuln.today Decision label is 'this_week'; no CVSS vector, EPSS score, KEV entry, or PoC reference was supplied, so scheduling the upgrade within the current week is consistent with the available signals.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Kafka's dynamic broker configuration path accepts IncrementalAlterConfigs/AlterConfigs RPCs that can target a BROKER resource. Config values may contain variable placeholders such as ${file:/path:key} or ${env:VAR}, which the broker expands at validation time by instantiating a ConfigProvider named in the request (for example FileConfigProvider or EnvVarConfigProvider). The root cause is CWE-862, Missing Authorization: the authorization check for BROKER-resource configuration changes is sequenced after validation and variable resolution, so a principal with no grants is still able to cause arbitrary ConfigProvider instantiation and file or environment lookups. Because resolution occurs outside the org.apache.kafka.automatic.config.providers allowlist that Apache added as the mitigation for CVE-2024-31141, that earlier hardening does not constrain which provider the caller selects here. The disclosure channel is the validation error itself, which is returned to the requester carrying the resolved content. Per the vendor and independent assessment, clusters running without an authorizer are not affected in practice because every principal already holds ALTER_CONFIGS there; exploitation needs valid credentials (PR:L) rather than anonymity, the assessment rates the scope as changed with high confidentiality impact, and no availability or integrity impact applies. The trigger requires the specific BROKER-targeted alter-config request with a ConfigProvider reference; the sources do not describe additional preconditions beyond those stated.
Know when Apache Kafka gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
Network-reachable Kafka request (AV:N/AC:L), needs any authenticated principal so PR:L; Kafka-authz bypass reads OS-governed host files, hence S:C; disclosure-only so C:H, I:N, A:N.
Primary rating from Vendor (apache).
DescriptionCVE.org
An authenticated Kafka principal with no authorization grants (not even ALTER_CONFIGS) can make a broker read a file or an environment variable from the broker host and return its contents. An IncrementalAlterConfigs (or AlterConfigs) request targeting a BROKER resource reaches the broker's configuration validation before any authorization check is applied to that path. Validation resolves configuration variables such as ${file:/path:key} or ${env:VAR} using a ConfigProvider named in the request, and this resolution bypasses the org.apache.kafka.automatic.config.providers allowlist that was added as the mitigation for CVE-2024-31141. An arbitrary ConfigProvider (for example FileConfigProvider or EnvVarConfigProvider) is therefore instantiated and the referenced file or environment variable is read, and a type-validation error returns the resolved content to the caller.
Impact:
On a cluster with an authorizer enabled, an authenticated principal with no authorization grants can read the contents of files accessible to the broker process, and the broker's environment variables, exposing credentials, keystores, or other secrets, defeating the CVE-2024-31141 allowlist. The read is bounded by the broker process's file permissions. The brokers and the cluster remain available; the issue is disclosure of file and environment- variable contents. Clusters with no authorizer configured are not affected in practice, because every principal already holds ALTER_CONFIGS there.
Mitigation:
Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. As defense in depth, run brokers under a least-privileged operating-system account so that sensitive files are not readable by the broker process.
Resolution:
From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: broker configuration changes are authorized (ALTER_CONFIGS on the cluster) before the configuration is validated, and configuration- variable resolution enforces the config-providers allowlist.
Executive ViewAI
Apache Kafka brokers with an authorizer enabled are exposed to a high-severity authorization bypass (CVE-2026-112375) that allows any authenticated user, even those with no permissions, to read files and environment variables from the broker host, including secrets like credentials and keys. This could lead to credential theft, lateral movement, and compliance breaches, affecting all organizations running Kafka clusters with authorizers; immediate action is required to assess exposure and implement mitigations.
No vendor-released patch identified at time of analysis. Interim mitigations include disabling the authorizer (if operationally acceptable), restricting broker process OS file permissions to least privilege, enabling and strictly configuring the ConfigProvider allowlist, and monitoring for suspicious AlterConfigs requests. Apply vendor patch when available.
Threat Intelligence Overview
CVE.org
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
More in Apache Kafka
View allApache Kafka 4.1.0 and 4.1.1 accept forged JWT tokens without signature validation, allowing remote unauthenticated atta
Apache Kafka's NetworkClient component logs entire request and response payloads at DEBUG level, exposing sensitive auth
Improper authorization in Apache Kafka 4.0.0-4.3.0 arises from a discrepancy between the documented ACL requirement and
Memory exhaustion in the Apache Kafka broker lets an authenticated principal holding Write permission on a topic submit
Kafka Connect workers leak plaintext secrets through the REST API's /connector-plugins/{connector-type}/config/validate
Authentication bypass in Apache Kafka Connect's isolated admin REST API allows unauthenticated network attackers to read
Network-reachable, unauthenticated deserialization flaws in Apache Kafka’s clients library and Kafka Streams can force m
Kafka Streams can be stalled indefinitely by a single record whose timestamp is at or near Long.MAX_VALUE, causing an in
Unauthenticated remote attackers can exhaust broker heap and trigger process-wide GC stalls on Apache Kafka by declaring
Heap exhaustion in Apache Kafka allows remote attackers to crash brokers by sending requests that declare an array eleme
Apache Kafka brokers can be driven into heap exhaustion by any authenticated client because the PushTelemetry (KIP-714)
Apache Kafka brokers that run SASL/OAUTHBEARER with the default DefaultJwtValidator and leave sasl.oauthbearer.jwks.endp
Exploit-DB