Splunk Enterprise 曝出高危漏洞链，攻击者可通过配置不当的 PostgreSQL 辅助服务实现远程代码执行（RCE）。该漏洞编号为（CVE-2026-20253），CVSS评分达9.8，影响 Splunk Enterprise 10 及后续版本。

漏洞源于新版 Splunk 引入的内部组件 PostgreSQL Sidecar Service。虽然本地部署环境中该服务并非默认启用，但在 AWS 上的 Splunk Enterprise 云部署中该服务默认激活，使得云环境面临开箱即用的安全风险。

漏洞利用链分析

据 watchTowr Labs 披露，该服务虽监听本地端口，但攻击者可通过 Splunk 主Web界面（端口8000）发送特制HTTP请求访问内部API端点，如"/v1/postgres/recovery/backup"和"/restore"。

漏洞核心在于认证控制缺失——API接受包括空值在内的任意凭证，并将其转发给 pg_dump、pg_restore 等 PostgreSQL 后端工具。由于这些工具执行时未实施严格认证检查，攻击者可触发未授权数据库操作。

研究人员发现，通过操纵"backupFile"参数，攻击者能利用目录遍历技术在系统任意位置创建或截断文件。更严重的是，攻击者可通过组合多个攻击行为实现更深层次的入侵：

1. 向"database"参数注入 PostgreSQL 连接字符串，强制 Splunk 连接至攻击者控制的数据库，将恶意数据库内容写入文件系统
2. 利用恢复功能中暴露的.pgpass文件凭证，在恢复过程中向内部 PostgreSQL 实例执行任意SQL语句

通过 PostgreSQL 大对象导出函数，攻击者可实现 Splunk 用户权限下的任意文件写入。在PoC中，攻击者通过覆盖正常操作时执行的 Splunk Python 脚本，最终在目标系统实现命令执行。

该漏洞表明，通过代理机制暴露的内部服务可能破坏安全假设，特别是当认证机制实施不当时。Splunk 已发布安全公告，强烈建议用户立即更新受影响版本。AWS 上的 Splunk Enterprise 用户应优先修补，因为漏洞组件在云环境中默认启用。

研究人员建议采取以下措施：

• 监控内部API端点的访问
• 限制非必要的服务暴露
• 检查关键Splunk组件的文件完整性
• 使用检测工具识别存在访问控制缺陷的系统

此案例证明，看似有限的漏洞（如任意文件写入）在与设计缺陷和凭证泄露结合时，可能演变为完整的系统入侵。

参考来源：

Splunk Enterprise Pre-Auth RCE Chain Exposes Database With Zero Authentication

本文为 独立观点，未经授权禁止转载。
如需授权、对文章有疑问或需删除稿件，请联系 FreeBuf 客服小蜜蜂（微信：freebee1024）