2023年8月，程代Apache Druid 被曝出一个 CVSS 评分高达 9.8 的码执远程代码执行漏洞，编号 CVE-2023-25194。行漏攻击者只需要向 Druid 的程代 Kafka 摄取任务提交一个特制的连接配置，就能在目标服务器上以 Druid 进程权限执行任意命令。码执不需要认证，行漏不需要用户交互，程代一条 HTTP 请求就能打穿。码执

这个漏洞的行漏根因不在 Druid 本身，而在它依赖的程代 Kafka 客户端。Druid 允许用户在创建 ingestion task 时自定义 Kafka 连接属性，码执比如 sasl.jaas.config。行漏Kafka 客户端支持一种叫 JndiLoginModule 的程代 JAAS 登录模块，而 JNDI 注入这条老路——Log4Shell 已经让全世界复习过一遍了——在这里同样成立。码执攻击者构造一个指向恶意 LDAP 服务的行漏 JNDI URL，Kafka 客户端在建立连接时会去加载远程 class 文件，代码就这么执行了。

危险的地方在于 Druid 的默认部署姿态。很多团队把 Druid 的 console 暴露在内网甚至公网，认为“反正只是查数据的”。但 Druid 的 ingestion 接口权限控制向来不是它的强项，默认配置下，能访问 console 的人就能提交任务。这意味着攻击面比想象中大得多。

修复路径有几条。最直接的是升级 Druid 到 24.0.1 或 25.0.0 以上，这些版本对 Kafka 连接属性做了白名单限制。如果短期内升不了，可以在 Druid 的 common.runtime.properties 里设置 druid.ingestion.security.enableKafkaSaslConfigValidation=true，把恶意配置拦在任务提交阶段。再退一步，至少把 console 和 ingestion API 从公网摘掉，加上认证层。不过说实话，后两种方案都是缓解，不是根治。

我翻了一下当时的 exploit 公开记录，从漏洞披露到 PoC 出现在 GitHub 上，间隔不到 48 小时。这种速度意味着留给运维的反应窗口极窄。更麻烦的是，Druid 在很多公司属于“数据平台团队维护、安全团队不熟”的那类中间件。资产清单里有没有它、跑的是哪个版本、console 有没有对外，这些问题在应急时经常一问三不知。

一个值得反思的点：Druid 的 Kafka 摄取功能本质上是在一个数据查询系统里嵌入了一个通用的消息队列客户端，而这个客户端又支持 JNDI 这种高风险的动态加载机制。功能叠加带来的攻击面扩张，在架构设计阶段很难完全预见，但每一次类似漏洞都在提醒我们——依赖链上的每一个“灵活配置项”，都可能是下一个入口。

如果你现在还在跑 Druid 且版本低于 24.0.1，先别管别的，去看一眼 console 的访问日志。有没有陌生 IP 提交过 ingestion task，比什么版本号都说明问题。