Patchfirst
CVE-2025-27817 Public exploit High · 7.5 EPSS 68.8%

Apache Kafka Client: Arbitrary file read and SSRF vulnerability

Apache Software Foundation · Apache Kafka Client

Summary

A flaw in the Apache Kafka Client component, where the SASL/OAUTHBEARER settings "sasl.oauthbearer.token.endpoint.url" and "sasl.oauthbearer.jwks.endpoint.url" can be abused to make the client read arbitrary local files and return their contents in error logs, or send requests to unintended locations. An attacker who can supply client configuration data, such as an untrusted party in an application that lets configurations be specified externally (for example, via the Kafka Connect REST API), can exploit this over the network without authentication or user interaction.

Official description · CVE.org

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.

Breakdown
71.2 / 100
Exploited
Yes, in VulnCheck KEV
Reports
0
Tactics
0/15

First seen exploited 10 months after disclosure. Public exploit code (PoC-in-GitHub) appeared 24 days after disclosure.

  1. Disclosedday 0
  2. Public exploit codePoC-in-GitHub+24 days
  3. First seen exploitedVulnCheck KEV evidence+10 mo

7 fixes in kafka-clients over 8 years. The latest fix listed for kafka-clients is 4.1.2.

Fixes in kafka-clientsMaven package, by fixed version. Earlier and later fixes in the same package, not necessarily the same bug.

  1. 0.11.0.2CVE-2017-1261026 Jul 2018
  2. 2.8.1CVE-2021-3815322 Sep 2021
  3. 3.7.1CVE-2024-3114119 Nov 2024
  4. 3.9.1CVE-2025-2781710 Jun 2025
  5. 4.0.1CVE-2026-3355820 Apr 2026
  6. 4.1.2CVE-2026-355547 Apr 2026
  7. 4.1.2CVE-2026-3355720 Apr 2026Latest listed

techniques

No techniques linked

No ATT&CK techniques are linked to this CVE yet. MITRE CTID has not mapped it, and no report passage in the corpus ties it to a technique.

Am I affected? What do I upgrade to?

From GitHub Security Advisories and OSV

1 package in 1 ecosystem. Main package: org.apache.kafka:kafka-clients.

Mavenorg.apache.kafka:kafka-clientsGHSA-vgq5-3255-v292

Upgrade to 3.9.1 or later

Set the version to 3.9.1 or later in your pom.xml or build.gradle.

The first fix for CVE-2025-27817.

Affected versions

If you runUpgrade to
3.1.0 up to 3.9.13.9.1

“Up to” means the second version is the fix and is not affected.

Check your lockfile against all CVEs

What security researchers reported

Not named in any threat report yet

Also mentioned in 2 community threat pulses (AlienVault OTX)

Weaker evidence

Pulses are indicator collections that anyone can publish. A mention is not confirmation of exploitation.

References

2 links, grouped by NVD tag
↑ ↓ chooseEnter openEsc close