CVE-2026-112375 in Kafka
Summary
by MITRE • 10/28/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/28/2026
This vulnerability represents a critical authentication bypass and information disclosure flaw within Apache Kafka brokers, specifically affecting versions prior to 4.2.2, 4.3.2, and 4.4.0. The core technical issue stems from an incorrect ordering of security controls during the processing of configuration update requests. When an authenticated principal submits an IncrementalAlterConfigs or AlterConfigs request targeting a BROKER resource, the broker initiates the validation phase before executing authorization checks. This sequence allows any authenticated user, even those lacking explicit ALTER_CONFIGS permissions, to trigger internal configuration resolution mechanisms that were intended to be restricted by previous security patches addressing CVE-2024-31141.
The mechanism of exploitation relies on the broker's ability to resolve dynamic configuration variables embedded within the request payload. By injecting syntax such as ${file:/path:key} or ${env:VAR}, an attacker can instruct the broker to read arbitrary files from the host filesystem or retrieve environment variable values. Crucially, this resolution process bypasses the allowlist of permitted ConfigProviders that was introduced in CVE-2024-31141 mitigation efforts. Instead of rejecting requests for unauthorized providers like FileConfigProvider or EnvVarConfigProvider, the broker instantiates these providers to resolve the variables. The attack is completed when a type-validation error occurs during this resolution process; rather than suppressing the detailed error message as intended, the broker returns the resolved content—the actual file contents or environment variable values—to the caller in the response body.
The operational impact of this vulnerability is severe due to its potential for sensitive data exfiltration. An attacker with minimal authentication credentials can extract secrets stored on the broker host, including database passwords, API keys, TLS keystores, and other cryptographic materials. This effectively nullifies the security boundary established by Kafka's authorizer, as the attack does not require elevated privileges but merely valid cluster access. The scope of data exposure is bounded only by the file system permissions assigned to the user account under which the Kafka broker process executes. Consequently, if the broker runs with broad read access, an attacker can potentially dump a significant portion of the host's sensitive configuration and secret files.
From a classification perspective, this vulnerability aligns with CWE-209: Generation of Error Message Containing Sensitive Information, as it leverages error responses to leak data. It also relates to CWE-862: Missing Authorization, since an authenticated user without specific privileges can perform actions reserved for administrators. In the context of the MITRE ATT&CK framework, this technique corresponds to T1504: Weak or Reused Configuration Parameters and potentially T1078: Valid Accounts, as it exploits valid credentials to access resources outside their intended scope. The attack vector is remote if Kafka listeners are exposed, but typically requires network proximity to the broker's administrative ports.
To mitigate this risk immediately, organizations should upgrade Apache Kafka to version 4.2.2, 4.3.2, or later versions such as 4.4.0 where the fix has been implemented. The resolution in these newer versions corrects the control flow by ensuring that authorization checks for ALTER_CONFIGS are performed before any configuration validation occurs. Furthermore, the updated code enforces the allowlist of ConfigProviders during variable resolution, preventing the instantiation of dangerous providers like FileConfigProvider or EnvVarConfigProvider unless explicitly permitted and authorized.
As a defense-in-depth measure beyond software upgrades, administrators should configure Kafka brokers to run under least-privileged operating system accounts. By restricting the file system permissions for the user account running the broker process, even if an attacker successfully exploits this vulnerability, they will be limited by the OS-level access controls. This ensures that sensitive files and environment variables are not readable by the broker process, thereby containing the blast radius of any potential information disclosure incident.