FreeBuf 上有一条新闻：Splunk sidecar 组件的一个漏洞，PoC 公开仅 6 天就被野外利用打穿。更讽刺的是，这个端点的认证校验完全是缺失的——不是实现有 bug，是压根没写。

当一个在企业内网广泛部署的日志平台，其 sidecar 组件暴露一个「谁都能写文件」的端点，结果可想而知。

CVE-2026-20253 是什么

Splunk sidecar 是 Splunk 生态里负责日志转发的组件。它部署在非 Splunk 服务器上，收集本地日志然后转发给 Splunk indexer。架构上是 agent-server 模型，sidecar 和 Splunk 之间通过 HTTP 管理端口通信。

漏洞出在 sidecar 暴露的管理 API 端点上——具体是 /services/sidecar/files 相关的写路径。这个端点接受文件内容和目标路径参数，然后直接写入磁盘。认证检查完全是空的，没有 token、没有证书验证、甚至连 Basic Auth 都没有。

审查一下这个端点的实现逻辑就会发现：它的路由注册里压根没挂认证中间件。不是 auth.require() 被绕过了，是开发团队根本没在路由上挂认证。一个 @router.post("/files") 后面直接跟了文件写入逻辑。

能访问到这个端口的攻击者，可以直接往 sidecar 所在服务器写入任意文件。配合 Splunk 的 TA（Technology Add-on）机制——Splunk 会定期扫描特定目录加载配置和脚本——从文件写入到命令执行只有一步之遥。

攻击链拆解：从文件写入到 Shell

攻击链路大致分三步：

第一步：发现暴露面。 内网存活的主机上扫描 8089 或其他 sidecar 监听端口。nmap 一个 -p 8089 --open 扫 C 段几分钟出结果。Shodan 上直接搜 splunk-sidecar 就能看到全球暴露面。

第二步：写入武器化载荷。 向 /services/sidecar/files POST 一个 JSON，指定文件名和内容。写入目标是 Splunk TA 的 inputs.conf 或 scripts 目录。Splunk TA 目录结构是固定的——$SPLUNK_HOME/etc/apps/<app_name>/local/inputs.conf。写入一个 script:// 输入就能让 Splunk 执行任意系统命令。

POST /services/sidecar/files HTTP/1.1
Host: target:8089
Content-Type: application/json

{
  "path": "/opt/splunk/etc/apps/search/local/inputs.conf",
  "content": "[script:///tmp/payload.sh]\ninterval = 60\nsource = payload\nsourcetype = exec\n"
}

第三步：触发执行。 Splunk 的脚本输入有轮询机制。配置文件一到位，Splunk 会在下一个轮询周期执行指定的脚本。输出通过正常的 Splunk 日志通道回传，攻击者从 indexer 侧看到执行结果。

从 PoC 公开到野外利用只用了 6 天，原因就在这里——它不是一个需要精心构造内存布局的漏洞，而是一个 HTTP POST 加一段配置文件文本的事。

威力分析：为什么 Splunk 的脚本能力放大了危害

这个漏洞本身的 CVSS 评分可能只是写入操作，但 Splunk 赋予了写入能力巨大的杠杆效应。

Splunk 的脚本执行点不止一处：

  • inputs.conf 的 script:// 输入：定时执行系统命令或脚本
  • savedsearches.conf 的 alert action：搜索结果匹配时触发外部脚本
  • props.conf + transforms.conf：数据解析阶段的变换脚本
  • REST API endpoint：通过 endpoints 暴露的自定义逻辑

只要攻击者能写入一次 TA 配置文件，以上任何一个渠道都能变成命令执行入口。所以这个漏洞的实际危害不是写入，而是 Splunk 整个脚本执行生态被撬开了。

检测：如何判断是否被利用

从网络层看，sidecar 管理端点通常不对外暴露，所以确认是否被扫描过很难。但主机层有几件事可以做：

  • sudo grep -r "script://" $SPLUNK_HOME/etc/apps/*/local/inputs.conf 检查是否有非预期的脚本输入
  • 检查 $SPLUNK_HOME/var/log/splunk/splunkd_access.log 看看 sidecar 端口上的 POST 请求来源
  • 看 sidecar 进程的网络连接状态：ss -tlnp | grep 8089 确认监听范围

对于已经部署了 sidecar 的环境，最紧急的动作是确认监听地址：

# 检查 sidecar 是否监听在 0.0.0.0
ss -tlnp | grep sidecar
# 期望看到 127.0.0.1:8089，如果是 0.0.0.0:8089 即刻修复

从防御者视角看这类漏洞

把这类问题简单归咎于「Splunk 开发不行」没有意义。更值得反思的是架构层面的设计缺陷。

Sidecar 组件的设计假设是「部署在可信网络内部」，所以开发团队没在认证上花心思。这个假设在十年前或许成立，在今天的混合网络环境下已经站不住脚了。DevOps 和云原生打破了网络边界，sidecar 这种组件的管理端口暴露出去只是时间问题。

几个实际的缓解措施：

  • 管理端点绑定 localhost 而非 0.0.0.0。如果只能本机访问，远程利用链在第一步就被切断。很多 sidecar 默认配置绑 0.0.0.0 是为了方便管理，但安全收益远大于便利性损失。
  • 加一层反向代理做认证代理。即使 sidecar 本身没认证，在前置加一个 nginx 做 basic auth 或 mTLS termination，也能阻断大部分的自动化扫描。
  • 网络分段 + 主机防火墙。 sidecar 管理端口不应该出现在非 Splunk 基础设施所在网段。

我的一点看法

这类「设计时假设网络可信，上线后发现不是那么回事」的漏洞会越来越多。网闸时代的内网可信假设已经被云原生和混合网络彻底打破。开发阶段就该问一个问题：「如果这个端口被人扫到了，最坏情况是什么？」如果答案是任意文件写入或者远程代码执行，那认证是不可协商的需求。

对于 Splunk 管理员，今天下班前能做的事：检查 sidecar 绑定地址，确认不是 0.0.0.0。别等补丁了——扫描器已经到了，补丁还在路上。

⚠️ 网络安全免责声明

本文内容仅供技术研究与安全学习之用。文中描述的漏洞分析、攻击链拆解和代码示例均基于公开披露的安全研究，旨在帮助开发者理解攻击原理、提升安全意识和防御能力。

请勿将本文所述技术用于任何未经授权的安全测试、渗透攻击或非法用途。任何因滥用本文信息而造成的法律后果，由使用者自行承担，与本文作者无关。

如发现系统安全漏洞，请通过合法渠道向相关厂商或平台报告，共同维护网络安全生态。