Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:NSummary
CVE-2025-27817 is a high-severity SSRF (CWE-918) vulnerability in Apache Kafka. Its CVSS base score is 7.5 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploit Public-Facing Application (T1190); ranked in the top 0.8% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to AC-4 (Information Flow Enforcement) and SI-10 (Information Input Validation) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
A possible arbitrary file read and SSRF vulnerability exists in Apache Kafka Clients. The issue stems from the client's acceptance of unvalidated configuration values for SASL/OAUTHBEARER connections, specifically the "sasl.oauthbearer.token.endpoint.url" and "sasl.oauthbearer.jwks.endpoint.url" properties. When these values are supplied by an untrusted party, the client can be directed to read arbitrary local files (including environment variables) or issue requests to unintended network locations, with the retrieved content surfaced in error logs. The flaw is particularly relevant to Apache Kafka Connect deployments where configuration can be supplied through the REST API.
An attacker with the ability to influence Kafka client configuration—such as through a compromised or multi-tenant Connect deployment—can leverage the properties to obtain filesystem contents or perform SSRF. This grants access to sensitive data on disk or environment variables and may allow requests to internal services that would otherwise be unreachable. The CVSS 7.5 score reflects network-exploitable confidentiality impact without authentication or user interaction.
Advisories from the Apache Kafka project and the oss-security mailing list describe the addition of the system property "-Dorg.apache.kafka.sasl.oauthbearer.allowed.urls" starting in versions 3.9.1 and 4.0.0. Version 3.9.1 retains permissive defaults for backward compatibility, while 4.0.0 and later default to an empty allow list, requiring explicit configuration of permitted endpoints.
The EPSS score rose from lower values after disclosure to a peak of 0.2509 on 2026-05-05 before receding to the current 0.2142, indicating measurable post-publication exploitation interest.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2025-17640
Vulnerability Data
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…
more
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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V1.3.6V1.5.3V5.3.2V10.4.7
Mitigating Controls (NIST 800-53 r5) AI
Information flow enforcement can restrict which destinations the server is allowed to contact on behalf of users.
Input validation directly stops untrusted URLs from being accepted and fetched without destination checks.
Boundary protection limits the network reach of server-initiated requests even if SSRF occurs.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure development practices directly include input validation and destination allow-listing that prevent SSRF.
Runtime monitoring of web applications and services can detect anomalous outbound requests indicative of SSRF.
Vulnerability identification processes can discover and record SSRF flaws in web applications.
Network segmentation and egress controls can limit the damage from successful SSRF requests.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Operational threat data describing SSRF campaigns can be used to tighten outbound-request allow-lists and detection rules before attackers exploit them.