CVE-2026-116779:FreeSWITCH 一条 SIP MESSAGE 即可执行系统命令

FreeSWITCH 的 SIP MESSAGE 处理逻辑存在命令注入缺陷 CVE-2026-116779(CVSS 3.1 评分 9.8),任何能向一个 SIP profile 投递 MESSAGE 的对端,都可以自行选择服务端要执行的 FreeSWITCH API 命令,进而以守护进程权限执行系统命令。项目方在公告中明确写明「该路径的利用已在野外被观测到」,修复版本为 1.11.3。

事件概述

该问题由 GitHub 安全公告 GHSA-mg63-h38w-8p9p 于 2026 年 10 月 28 日公开,CVE 记录在 11 月 5 日建档,弱点为 CWE-77、CWE-78 与 CWE-749。修复其实更早:FreeSWITCH 1.11.3 于 8 月 28 日发布,发布说明中「mod_sofia 新增 enable-chat-api-proto 以限制 api chat proto」一条对应的正是这个缺陷。

也就是说,从补丁落地到安全公告公开之间隔了约两个月。这段时间里,只关注安全公告、不跟踪版本更新日志的运维者,并不知道自己错过了一个 9.8 分的远程命令执行修复。

技术细节:proto 选择器与 api 接口

根因在 sofia_presence_handle_sip_i_message() 这个函数:它把入站 SIP MESSAGE 的 To 用户部分按加号拆开,并把左半边直接当作「聊天协议名」(chat proto)去匹配已注册的聊天接口。而 mod_dptools 恰好注册了一个名为 api 的聊天接口,其地址被原样交给 switch_api_execute()。于是协议名变成了命令选择器,且没有任何限制——消息投递类接口与命令执行类接口,在分发层被混为一谈。

用伪代码描述这条路径:

To: <api+originate@example.com>
        |
        v
sofia_presence_handle_sip_i_message()
  split(To_user, "+") -> ["api", "originate"]
  proto = "api"          # left half becomes chat proto
        |
        v
mod_dptools api chat interface
        |
        v
switch_api_execute("originate ...")   # 任意 API 命令

环境还加载了 mod_lua(官方默认配置即加载),因此还存在第二个落点:内联 Lua 脚本可直接调用完整标准库,攻击者不必依赖系统命令拼接。

为什么默认配置就在范围内

公告对暴露面写得很直白:任何接受入站 MESSAGE 的 SIP profile 都受影响,而这正是默认状态——除非某个 profile 显式设置 enable-chat=false,否则聊天处理默认开启,官方 conf/vanilla 对内网与外网两个 profile 都没有关闭。此外,入站 ACL 不覆盖 MESSAGE,因此收紧 ACL 并不能把 profile 移出受影响范围。

攻击前提只有一条:让一条 MESSAGE 被 profile 接受。若 profile 启用了 MESSAGE 认证,那么该 profile 上任意一个能注册的账号(分机、话机、中继对端)就足够。更糟的是,仍保留 conf/vanilla/directory/default/default.xml 的部署连账号都不需要——该文件定义了无 password、无 a1-hash 的 default 用户,而这两项均为空时,目录用户默认认证成功(除非为它设置 allow-empty-password=false)。官方 vanilla 配置中带此类空凭证的用户有两个。

影响评估

CVSS 向量为 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H,未认证、无需交互、单条消息即可完成。落地后的能力包括:以 FreeSWITCH 进程权限执行任意系统命令、读取配置与其中的 SIP 中继凭证、完全接管呼叫路由(窃听、任意外呼、话费套现)。对 VoIP 服务商与呼叫中心,这三项任意一项都足以造成直接经济损失与合规问题。

EPSS 目前给出约 1.3% 的 30 天利用概率(第 70 百分位),在同期漏洞中偏高,与「已在野」一致。

需要特别提示的是暴露面分布。FreeSWITCH 常见于呼叫中心、IVR 语音导航、运营商中继对接与云通信平台,这类部署往往把 SIP 端口直接映射到公网以便远端分机注册,而运维习惯上只对 5060 做限速或 ACL,很少意识到「聊天」这条与通话无关的功能同样走同一条 UDP/TCP 通道。容器化部署的团队还容易忽略镜像里的 conf/vanilla 原样保留,连带保留了那两个空凭证目录用户。

修复建议

  • 升级到 FreeSWITCH 1.11.3 或更高版本。新版新增按 profile 生效的 enable-chat-api-proto 参数,默认关闭,未启用时选择 api 的 MESSAGE 会被回以 403 并记录来源与所请求的命令。
  • 无法立即升级时,对所有不需要入站 SIP 聊天功能的 profile 设置 enable-chat=false。这会在解析 proto 选择器之前拦下消息。
  • 删除目录中所有无 password、无 a1-hash 的用户(vanilla 配置自带 default 与 Skinny 示例两个)。这一步只能把问题降级为「已认证命令执行」,不能关闭路径。
  • 设置 disable_system_api_commands=true 可移除 system 接口,但路由仍在,模块加载、呼叫发起等 API 依然可达,属于加固而非修复。
  • 排查方向:FreeSWITCH 日志中出现 403 且带有 api proto 的记录、非预期来源发起的 MESSAGE、以及 fs_cli 中未授权的 originate 记录。

参考来源