CVE-2025-27817 in Kafka Client
Summary
by MITRE • 06/10/2025
A possible arbitrary file read and SSRF vulnerability has been identified in Apache Kafka Client. Apache Kafka Clients accept configuration data for setting the SASL/OAUTHBEARER connection with the brokers, including "sasl.oauthbearer.token.endpoint.url" and "sasl.oauthbearer.jwks.endpoint.url". Apache Kafka allows clients to read an arbitrary file and return the content in the error log, or sending requests to an unintended location. In applications where Apache Kafka Clients configurations can be specified by an untrusted party, attackers may use the "sasl.oauthbearer.token.endpoint.url" and "sasl.oauthbearer.jwks.endpoint.url" configuratin to read arbitrary contents of the disk and environment variables or make requests to an unintended location. In particular, this flaw may be used in Apache Kafka Connect to escalate from REST API access to filesystem/environment/URL access, which may be undesirable in certain environments, including SaaS products.
Since Apache Kafka 3.9.1/4.0.0, we have added a system property ("-Dorg.apache.kafka.sasl.oauthbearer.allowed.urls") to set the allowed urls in SASL JAAS configuration. In 3.9.1, it accepts all urls by default for backward compatibility. However in 4.0.0 and newer, the default value is empty list and users have to set the allowed urls explicitly.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 01/07/2026
The vulnerability described in CVE-2025-27817 represents a critical security flaw in Apache Kafka client implementations that enables both arbitrary file reading and server-side request forgery attacks through improper validation of SASL/OAUTHBEARER configuration parameters. This vulnerability specifically affects the handling of two critical configuration fields: "sasl.oauthbearer.token.endpoint.url" and "sasl.oauthbearer.jwks.endpoint.url" which are used to establish secure connections between Kafka clients and brokers. The flaw arises from insufficient input validation and sanitization of these URL parameters, allowing attackers to manipulate the client's behavior to access local filesystem resources or make unintended network requests to arbitrary endpoints.
The technical exploitation of this vulnerability occurs through the manipulation of OAuthBearer authentication configuration parameters that Kafka clients accept. When these parameters are improperly validated, attackers can craft malicious URLs that point to local file system paths or internal network endpoints, enabling them to read sensitive files from the local disk or extract environment variables. This arbitrary file read capability can potentially expose sensitive configuration data, authentication tokens, or other confidential information stored on the system. Additionally, the vulnerability enables server-side request forgery attacks where the Kafka client can be forced to make HTTP requests to unintended targets, potentially allowing attackers to probe internal networks or exfiltrate data through the client's connection to external services.
The operational impact of this vulnerability is particularly severe in environments where Kafka clients are configured by untrusted parties or when Kafka Connect components are deployed in multi-tenant or SaaS environments. The vulnerability can be exploited to escalate privileges from REST API access to full filesystem and network access, creating a significant attack surface that could be leveraged for lateral movement within a network. In Apache Kafka Connect deployments, this flaw becomes especially dangerous as it allows attackers to gain access to the underlying filesystem, potentially enabling them to read configuration files, deploy malicious code, or access other system resources that should remain isolated from external access. The vulnerability's severity is amplified by the fact that it affects widely deployed Kafka client libraries and can be exploited in various deployment scenarios including cloud environments, containerized applications, and enterprise messaging systems.
The vulnerability relates to multiple cybersecurity standards and frameworks, particularly CWE-22 for path traversal and CWE-918 for server-side request forgery, both of which are commonly referenced in security assessments and vulnerability categorizations. From an ATT&CK framework perspective, this vulnerability maps to techniques involving privilege escalation through configuration manipulation and initial access via exploitation of unpatched software components. The affected Apache Kafka versions 3.9.1 and 4.0.0 introduced a mitigation through the addition of the system property "-Dorg.apache.kafka.sasl.oauthbearer.allowed.urls" which allows administrators to define a whitelist of allowed URLs for OAuthBearer authentication. However, this protection mechanism defaults to permissive behavior in version 3.9.1 for backward compatibility, while enforcing strict validation in version 4.0.0 and later, requiring explicit configuration by system administrators to effectively protect against this vulnerability.
Organizations should immediately implement mitigation strategies including upgrading to Apache Kafka versions 4.0.0 or later where the default behavior is more secure, or if upgrading is not immediately possible, explicitly configuring the allowed URLs whitelist through the system property mentioned in the security advisory. The configuration should be carefully reviewed to ensure that only legitimate and trusted endpoints are included in the allowed URL list, preventing attackers from using this mechanism to bypass security controls. Additionally, organizations should monitor their Kafka client deployments for any signs of exploitation attempts and implement network segmentation to limit the potential impact of successful attacks. Regular security assessments should be conducted to identify any other potentially vulnerable components in the messaging infrastructure that may be susceptible to similar configuration-based vulnerabilities.