CVE-2025-27817

What it actually does

Apache Kafka Client OAuthBearer handling can be abused when an untrusted user can supply client, connector, or JAAS configuration values. The vulnerable behavior involves the `sasl.oauthbearer.token.endpoint.url` and `sasl.oauthbearer.jwks.endpoint.url` settings: instead of restricting them to intended trusted OAuth/JWKS endpoints, affected clients may attempt to read attacker-supplied URLs, including local files or unintended internal network locations. In practical terms, this can produce arbitrary local file read through error logging, exposure of environment variables or secrets, and server-side request forgery from the Kafka client or Kafka Connect process. The risk is highest in Kafka Connect or managed/SaaS platforms where REST API users can create or modify connector configurations.

Why it matters to the business

Successful exploitation can expose secrets, service credentials, configuration files, environment variables, or internal service responses from systems running Kafka clients or Kafka Connect. It can also allow attackers to probe internal networks from a trusted application location, which may support further compromise. Because the issue is described as weaponized and has a high EPSS score, organizations that allow user-controlled Kafka connector or client configuration should treat it as urgent even though it is not currently listed in CISA KEV. Multi-tenant and SaaS offerings are especially exposed because a low-privileged user with connector configuration access may be able to reach data or services outside their intended boundary.

How an attack unfolds

An attacker first obtains the ability to influence Apache Kafka Client configuration, commonly through Kafka Connect REST APIs, connector creation/update workflows, or an application feature that accepts Kafka connection settings from users. The attacker supplies OAuthBearer-related configuration values such as `sasl.oauthbearer.token.endpoint.url` or `sasl.oauthbearer.jwks.endpoint.url` that point to a local file, process environment source, cloud metadata endpoint, loopback service, or otherwise unintended internal URL. When the Kafka client initializes or refreshes OAuthBearer token or JWKS material, it attempts to access the supplied location. For local files or invalid responses, sensitive content may be reflected into application or Kafka Connect error logs. For HTTP(S) destinations, the client may send outbound requests from the server-side environment, enabling SSRF-based internal reconnaissance or access to metadata and internal services. The attacker then retrieves the leaked output through application logs, connector task errors, REST API status responses, or other observable error surfaces.

How to fix it

Upgrade Apache Kafka Client and Kafka Connect components to fixed versions that include the OAuthBearer URL allowlist behavior. For Apache Kafka source deployments, use a version containing commit `f745dfdcee2b9851204ddbbcd423626ab87294bc`; Kafka 3.9.1 and 4.0.0 introduced the `-Dorg.apache.kafka.sasl.oauthbearer.allowed.urls` system property. On Kafka 3.9.1, explicitly set `-Dorg.apache.kafka.sasl.oauthbearer.allowed.urls` to a minimal allowlist because the default remains permissive for backward compatibility. On Kafka 4.0.0 and newer, keep the default empty list unless OAuthBearer endpoints are required, and explicitly allow only trusted token and JWKS URLs. Remove the ability for untrusted users to set `sasl.oauthbearer.token.endpoint.url`, `sasl.oauthbearer.jwks.endpoint.url`, SASL JAAS options, or other security-sensitive Kafka client properties. For Kafka Connect, enforce connector configuration validation, block dangerous URL schemes such as `file:`, restrict loopback and link-local addresses, and require authentication and authorization on the Connect REST API. Apply listed Android downstream fixes where relevant: platform/frameworks/base and platform/packages/services/Telephony fixed in Android 12, 12L, 13, 14, 15, and 15-next at the 2025-03-01 patch level.

How to confirm the fix worked

Inventory all applications, Kafka Connect workers, and services that embed `kafka-clients` or accept Kafka client configuration from users. Confirm the deployed Apache Kafka Client version contains the fix or the referenced commit, and verify Kafka Connect workers are launched with a restrictive `-Dorg.apache.kafka.sasl.oauthbearer.allowed.urls` value. Review connector and application configuration paths to ensure untrusted users cannot provide `sasl.oauthbearer.token.endpoint.url`, `sasl.oauthbearer.jwks.endpoint.url`, or arbitrary SASL JAAS content. Perform a controlled negative test in a non-production environment by attempting to configure a `file:` URL, loopback URL, and cloud metadata URL; the configuration should be rejected or the URL should be denied before any request or file read occurs. Check runtime logs to ensure sensitive file contents are not echoed in OAuthBearer/JWKS error messages. For Android downstream exposure, confirm the device or build security patch level is 2025-03-01 or later for the affected components.

Typical attack path

1. Identify an application, Kafka Connect deployment, or managed service that allows users to submit or modify Kafka client or connector configuration.
2. Create or update a Kafka client/connector configuration using SASL/OAUTHBEARER settings.
3. Set `sasl.oauthbearer.token.endpoint.url` or `sasl.oauthbearer.jwks.endpoint.url` to a local file path, environment-related path, cloud metadata address, loopback URL, or internal service URL.
4. Trigger connector startup, task restart, authentication refresh, or client connection logic so the Kafka client resolves the supplied endpoint.
5. Collect leaked file contents, environment values, or internal service responses from error logs, task status, application responses, or monitoring output.
6. Use the disclosed secrets or internal reconnaissance results to expand access, pivot to other services, or compromise downstream systems.

How to detect it

To determine whether exploitation already occurred, review Kafka Connect worker logs, application logs, connector task error logs, REST API audit logs, and configuration history for suspicious use of OAuthBearer token or JWKS endpoint settings. Focus on connector create/update events and Kafka client configuration changes containing `sasl.oauthbearer.token.endpoint.url` or `sasl.oauthbearer.jwks.endpoint.url`, especially values using `file:`, loopback addresses, link-local addresses, private IP ranges, cloud metadata endpoints, or unexpected internal hostnames. Search logs for sensitive file contents that may have been reflected in errors, such as `/etc/passwd`-style entries, environment variable dumps, private keys, access tokens, or cloud credential JSON. Review outbound proxy, firewall, VPC flow, DNS, and service mesh logs from Kafka Connect and Kafka client hosts for unexpected requests to metadata services, localhost, internal admin panels, or non-approved OAuth/JWKS destinations. If suspicious configuration is found, preserve the connector configuration, worker logs, task status output, and network telemetry; rotate any secrets that may have been exposed in logs or via SSRF responses.

• sasl.oauthbearer.token.endpoint.url
• sasl.oauthbearer.jwks.endpoint.url
• org.apache.kafka.sasl.oauthbearer.allowed.urls
• file:/etc/passwd
• file:///etc/passwd
• file:/proc/self/environ
• file:///proc/self/environ
• file:/proc/1/environ
• file:///proc/1/environ
• file:/var/run/secrets/kubernetes.io/serviceaccount/token
• file:///var/run/secrets/kubernetes.io/serviceaccount/token
• http://169.254.169.254
• https://169.254.169.254
• http://metadata.google.internal
• http://169.254.170.2
• http://100.100.100.200
• http://127.0.0.1
• http://localhost
• http://[::1]
• BEGIN PRIVATE KEY
• BEGIN RSA PRIVATE KEY
• AWS_ACCESS_KEY_ID=
• AWS_SECRET_ACCESS_KEY=
• GOOGLE_APPLICATION_CREDENTIALS
• AZURE_CLIENT_SECRET
• root:x:0:0:
• connect-distributed
• connect-standalone
• /connectors
• /connectors/
• /connector-plugins

What your security team should do

• Prioritize remediation for Kafka Connect, managed connector platforms, SaaS control planes, and any service where non-admin users can submit Kafka client configuration.
• Upgrade Apache Kafka Client/Kafka Connect to fixed builds and set `-Dorg.apache.kafka.sasl.oauthbearer.allowed.urls` to an explicit minimal allowlist.
• Block untrusted configuration of `sasl.oauthbearer.token.endpoint.url`, `sasl.oauthbearer.jwks.endpoint.url`, `sasl.jaas.config`, and related SASL/OAUTHBEARER properties.
• Harden Kafka Connect REST APIs with strong authentication, authorization, network restrictions, and audit logging.
• Search existing connector configurations and configuration history for `file:`, loopback, link-local, RFC1918, cloud metadata, or unexpected OAuth/JWKS endpoint values.
• Review Kafka Connect and application logs for evidence of file disclosure, environment variable leakage, or unexpected outbound requests tied to OAuthBearer token or JWKS retrieval.
• Use egress controls to prevent Kafka clients and Connect workers from reaching cloud metadata services, loopback-only services, and unauthorized internal networks.
• Treat exposed credentials discovered in logs as compromised: rotate secrets, invalidate tokens, and purge sensitive log copies where feasible.