Apache Kafka Client 任意文件读取与SSRF 漏洞（CVE-2025-27817）分析-先知社区

漏洞描述

攻击者在可以控制Apache Kafka Connect 客户端的情况下，可通过SASL JAAS 配置和基于 SASL 的安全协议在其上创建或修改连接器相关配置，利用部分参数例如

sasl.oauthbearer.token.endpoint.url

和

sasl.oauthbearer.jwks.endpoint.url

，造成任意文件读取与SSRF漏洞。

漏洞影响范围

2.3.0 <= Apache Kafka Client <= 3.9.0

调试环境

从描述来看感觉像是老洞的绕过

https://github.com/vulhub/vulhub/blob/master/kafka/CVE-2023-25194/README.zh-cn.md

利用vulhub的docker可以快速部署，它的kafka-clients版本是3.3.1

但其实要跟踪逻辑调试漏洞，本地起一个maven项目写一个kafka consumer就可以了

pom依赖

最终代码如下

diff

现在进入实际的分析过程

从

github.com/apache/kafka/tags

下载3.9.0和3.9.1的代码做diff

图片加载失败

根据漏洞描述只需要关注clients下面oauthbearer部分即可，在AccessTokenRetrieverFactory可以看到新版本对SASL_OAUTHBEARER_TOKEN_ENDPOINT_URL有个合法性校验。

图片加载失败

总之可以确认

sasl.oauthbearer.token.endpoint.url

这个属性直接放payload就行

来自gemeni的介绍

OAUTHBEARER 是 Kafka 2.0.0 版本引入的一种 SASL (Simple Authentication and Security Layer) 机制，用于实现基于 OAuth 2.0 协议的认证。它允许 Kafka 客户端（生产者、消费者、Connect、Streams 等）使用 OAuth 2.0 访问令牌（Access Token，通常是 JWT - JSON Web Token）向 Kafka Broker 进行身份验证。

核心思想：

客户端不再直接向 Kafka Broker 提供用户名/密码，而是：

从一个独立的 OAuth 2.0 授权服务器 (Authorization Server / Identity Provider - IdP) 获取一个访问令牌 (Access Token)。

这个过程通常涉及客户端凭据授权 (Client Credentials Grant) 或其他 OAuth 2.0 授权流程。

将这个访问令牌发送给 Kafka Broker。

Kafka Broker 验证这个令牌。

Broker 不会直接与 IdP 交互获取令牌，而是验证收到的令牌的有效性（例如，JWT 签名验证、过期时间、颁发者、受众等）。如果令牌有效，认证通过。

其他的文件改动有部分正是和jwt相关的

接下来要处理的就是怎么走通这个流程

调用链

根据老洞poc，自己写个consumer把这些属性加上尝试debug看能不能走到有改动的文件。

在diff发现的新版本加了判断的地方下断点

图片加载失败

要读文件就要能进入return new FileTokenRetriever(cu.validateFile("sasl.oauthbearer.token.endpoint.url"));这一行

图片加载失败

把这个file对象设置到accesstokenfile

图片加载失败

进入登录流程

图片加载失败

OAuthBearerLoginCallbackHandler

图片加载失败

最终触发是在登录校验token的时候读取的文件内容不满足jwt格式被报错带出

图片加载失败

报错中成功带出文件信息

图片加载失败

上面的流程看着一气呵成，因为这是鼓捣出poc之后的正确路径。

讲一个坑点，因为我并不熟悉kafka,下断点其实跑不到，但是我注意到改动文件中有一个saslxxxxcallbackhandler，我猜测应该要被它处理到才能走到我想要的流程里去。于是问ai问出这么一个属性sasl.login.callback.handler.class可以设置。但debug之后发现实际并不是这个，有兴趣的可以自己调一下。

poc验证

在druid上验一下

图片加载失败