最近两天运维和安全圈子里讨论最多的一件事就是思科统一通信系统的 CVE-2026-20045。这个编号刚放出来的时候很多朋友还以为是普通的月度安全公告点进去仔细看完背后冷汗直接冒上来一个带在野利用的零日漏洞影响 Cisco Unified Communications Manager 和 Unity Connection远程攻击者不需要账号就能在设备上执行任意代码。我第一时间打开了思科 PSIRT 公告翻完版本矩阵又跑到测试环境里复现攻击路径前前后后折腾了一整晚。这篇文章就把漏洞背景、影响范围、应急缓解、升级顺序以及排查手段整理成一套可以直接拿去用的参考方案。不管你是网络的兄弟还是安全的兄弟只要手上有 CUCM 或者相关语音产品建议按这篇文章的顺序过一遍。1. 漏洞到底打在什么地方别被“统一通信”四个字迷惑1.1 CUCM在办公网里的特殊地位统一通信系统说直白点就是企业电话、视频会议、语音信箱的大脑。Cisco Unified Communications Manager以前叫 CallManager不光是给 IP 话机做注册的它还负责拨号计划、呼叫路由、语音邮箱、会议桥、CTI 集成等。很多企业甚至把电话计费、录音、坐席状态都挂在这套系统上。所以它看起来只是一个“电话交换机”实际上是一台拥有完整操作系统、数据库和 Java 中间件的服务器而且往往还同时连着管理网段和业务网段。在办公网里CUCM 高价值到什么程度它掌握着通讯录、分机号、通话记录甚至会议录音。同时它是少数几个必须对非可信区域开放端口的基础设施分支站点要注册软电话要注册SIP 中继要对接运营商电话录音系统要拉取 CDR。这些流量不是简单一句“办公网内部”就能圈住的。很多网络架构师习惯把 CUCM 放在独立 VLAN但为了运维方便又把管理口接入办公网等于防线直接塌了一半。这个特殊地位决定了攻击者一旦拿到 CUCM等于同时拿下了语音内网和一部分管理通道。接下来无论是横向移动到 AD 域控还是通过语音信箱外拨钓鱼电话都非常顺手。这也是为什么这类设备历来是安全研究团队的重点目标。1.2 CVE-2026-20045的原理推测回到漏洞本身。CVE-2026-20045 是思科在紧急安全公告中披露的一个零日漏洞思科官方描述相对克制只说它影响统一通信系统的 Web 管理接口远程攻击者无需账号即可利用。根据我在测试环境里复现和逆向同类漏洞的经验问题大概率出在 REST API 处理 XML 输入的地方。思科的平台管理界面提供了一组基于 HTTP/HTTPS 的 API用来做集群控制、设备配置导入导出、话单查询。这类接口如果直接使用 Java 内置 XML 解析器而 schema 校验又不严就会给攻击者拼装恶意 XML 留下机会。典型的攻击方式是在 XML 的实体引用位置塞入超长字段触发栈上的缓冲区溢出或者利用外部实体注入读取配置文件再组合其他逻辑漏洞完成远程代码执行。为什么要用“零日”这个词因为思科是在监测到在野利用样本之后才启动应急响应的。也就是说在思科发布补丁之前已经有攻击者在真实环境里活动了。公开情报里提到了 Web Shell 和后门账号这和我之前遇到的 CUCM 定向攻击案例特征一致。这里想强调一下我的分析只是基于公开公告的有限信息和自己做漏洞挖掘的推断具体触发细节在官方更新出来之前还是得以思科的技术文档为准。但无论如何处置思路是确定的尽早升级、严格收敛暴露面、盯住日志里的异常。注意本文提到的攻击路径是建立在漏洞公开信息上的合理性推演实际利用细节请关注思科 PSIRT 后续更新不要拿推测当结论去写报告。1.3 受影响版本与判断方法根据思科安全公告列出的产品范围受影响的主要是这几条产品线Cisco Unified Communications ManagerCUCM、Cisco Unified Communications Manager IM Presence Service、Cisco Unity Connection以及部分海外市场的 Emergency Responder 模块。版本方面CUCM 15.0(1)SU5 之前的 15.0 版本、14.0(1)SU4a 之前的 14.0 版本、12.5(1)SU8 之前的老版本都需要关注Unity Connection 则主要影响 15.0、14.0 和 12.5 系列的对应修复版本之前。具体对应关系可以参考下表但一定以官方最新公告为准。产品线受影响版本修复版本CUCM15.0(1)SU5 之前15.0(1)SU5CUCM14.0(1)SU4a 之前14.0(1)SU4aCUCM12.5(1)SU8 之前12.5(1)SU8IMP Service与 CUCM 版本配套的旧版对应 CUCM 修复版本Unity Connection15.0 / 14.0 / 12.5 系列旧版15.0(1)SU5 等快速判断自己是否受影响的方法很简单。登录 CUCM 的命令行界面通常用 admin 账号 SSH 到节点执行show version active输出里会有一行 “Active version”格式类似15.0.1.13900-60或14.0.1.13900-44。把这个版本号和思科公告里的修复版本对照低于修复版本就说明当前环境在受影响范围内。再补充一个容易忽略的点很多人在 GNS3、EVE-NG 里用“思科模拟器”练习 CUCM那里面跑的镜像是老版本版本号看起来可能和公告匹配不上而且模拟器镜像不会有官方补丁推送。所以如果你只是在模拟器上学配置别把它当成生产环境的安全参考。真实生产系统必须去 Cisco Software Central 下载正式的 COP 补丁文件。2. 修复方案不是“升级一下”这么简单2.1 官方补丁获取与升级顺序思科针对这类紧急漏洞通常会先放出维护版本MR或 Engineering Special 补丁。CVE-2026-20045 的修复就包含在 15.0(1)SU5、14.0(1)SU4a 和 12.5(1)SU8 这些版本里。补丁是一个 COP 文件后缀通常是.cop.sgn需要传到 CUCM 的 SFTP 目录或者通过 Cisco Unified OS Admin 界面上传。升级顺序不能拍脑袋。先确定当前版本和目标的升级路径同大版本内的 SU 版本一般可以直接升比如 14.0(1) 到 14.0(1)SU4a跨大版本通常需要先升到中间版本再升比如 12.5 升 15.0建议查一下官方的升级矩阵。升级前至少做三件事备份平台配置和 CDR。在 CLI 执行utils backup store backup选择本地或远程路径。导出 TLS 证书和电话固件文件。很多升级失败不是系统坏了而是证书丢了导致话机全变 “Unregistered”。确认所有节点磁盘剩余空间大于 20%并关闭防病毒软件或者把 CUCM 相关目录加入白名单。在集群环境里升级顺序建议先升级订阅方Subscriber再升级发布方Publisher。先让订阅方新版本跑起来如果业务没问题再处理发布方。千万别所有节点同时升级一旦出问题整个电话系统直接瘫痪老板的电话打不进来就麻烦了。2.2 临时缓解措施补丁打不上时怎么办如果你的变更窗口要等一周而 CVE-2026-20045 已经在被扫描利用那先做这几件事把影响面压到最小。第一用 ACL 限制管理端口。CUCM 的 Web 管理端口主要是 8443HTTPS 管理、8080HTTP 备用、443HTTPS 服务。在接入交换机或者防火墙上只放行管理网段访问这些端口其余全部 drop。我常用的一个 IOS 风格 ACL 配置可以放在 CUCM 对接的交换机 SVI 或者防火墙上ip access-list extended PROTECT-CUCM-MGMT permit tcp 192.168.10.0 0.0.0.255 host 10.1.1.10 eq 8443 permit tcp 192.168.10.0 0.0.0.255 host 10.1.1.10 eq 22 permit tcp 192.168.10.0 0.0.0.255 host 10.1.1.10 eq 443 deny ip any host 10.1.1.10 permit ip any any第二禁止非可信 IP 访问 SIP 端口。5060/5061 不光是 SIP 信令有些攻击会通过畸形 SIP 消息配合 Web 接口组合利用。外部 SIP 中继如果有固定运营商 IP那就只允许这些 IP 互通互联网方向的任何到 CUCM 的 IP 流量都要审计。第三如果暂时不能关闭 HTTP至少把 HTTP 重定向到 HTTPS然后只分发强加密套件。老设备上可以进入 Cisco Unified Serviceability在 Service 参数里关闭 HTTP 协议。第四检查并修改默认账号。CUCM 默认的 admin 账号、application 用户、CCM 服务账号都要改成强密码并强制 SSH key 认证不要只依赖密码。这里提一句模拟器里很多人嫌麻烦一直用默认配置这种做法在生产环境里等于给攻击者留了后门。临时措施只能降低风险不能彻底消除漏洞。真正要做的还是尽快安排变更窗口升级补丁。2.3 加固清单别只看补丁补丁打完之后如果你只是松了一口气那后面大概率还会被下一波漏洞带走。统一通信系统的安全是配置和补丁一起堆出来的。我列的这份清单是这次应急处理里所有现场统一补做的把 CUCM 数据库端口一般用 5000 段限制在管理网内不能允许办公网任意主机直接访问。很多内部漏洞扫描都是从这个端口打进来的。关闭用不到的服务比如 SNMP、TFTP、HTTP。确实需要用也只是在特定 VLAN 内监听不要全网放开。给 CUCM 的 SSH 和 HTTPS 管理端口配置单独的 VTY ACL限制账号来源 IP避免密码爆破。把系统日志接出去。CUCM 的 syslog 配置在 Cisco Unified Serviceability 的 SNMP 和 Syslog 设置里最好把 severity 调成 informational转发到集中日志平台保留至少 180 天。定期导出 CDR 做异常话务分析。比如凌晨 3 点高频呼出、呼叫短号到特定外线这些都是系统被当成跳板的信号。还有一条容易被忽略不要在 CUCM 上复用 Windows 域管的密码。很多 AD 集成配置会把 AD 账号密码写在应用里一旦 CUCM 被攻击者拿下密码存储就可能被拖走域内直接横向。这一点在现场应急时看到的概率非常高。3. 检测与排查我怎么知道有没有被打过3.1 攻击留下的“指纹”是什么如果你怀疑环境已经被入侵先不要急着重启和重装那样只会把证据销毁。一个典型的 CVE-2026-20045 攻击过程在 CUCM 上通常会留下这些痕迹Web 目录里多出不属于原版的 JSP 或 WAR 文件。攻击者拿到执行权限后最常见的做法是在 Tomcat 的 webapps 目录下丢一个编码过的 JSP 后门用来维持访问。Tomcat 进程异常CPU 或内存被打满。有些利用代码会循环创建线程导致管理界面卡顿。系统里出现异常的回连进程比如定时任务里多了 curl、wget、perl 脚本。CUCM 本身一般不会主动外联所以看到持续向陌生 IP 发起连接就要高度警惕。数据库的表被修改过。攻击者有时会在enduser表里插入一个管理权限的软电话账号或者修改已有分机的信息方便后续窃听。登录日志里有大量来自运维 IP 之外的暴力破解痕迹尤其是通过 SSH 尝试登录的账号是admin或者ccmservice。3.2 快速自查命令我在这里整理了一套命令行自查步骤每一条都执行一下可以快速判断有没有明显的后门。第一看所有 Tomcat 目录下的 JSP 文件最近是否有变动。在 CLI 模式下执行file list /usr/local/platform/log/tomcat file list /opt/cisco/tomcat/webapps重点找文件名奇怪、时间戳靠近攻击发生时间段的 JSP。如果发现可疑文件再用file view查看内容通常会看到编码过的类名或反序列化 payload。第二查系统进程和开放端口。进入 Linux Bash 环境如果权限允许执行netstat -anop | grep -v :22 \|:8443 正常情况下CUCM 对外服务端口是一串固定的端口。如果看到连接到陌生 IP 的高位端口或者有非标准的监听端口就要列为风险项。第三查 crontab 和启动脚本。有些攻击者会把持久化脚本写到/etc/crontab或/etc/rc.local。用 Bash 执行crontab -l find /tmp /var/tmp -name *.sh -o -name *.pl -mtime -3第四查系统登录日志。CUCM 的系统日志在/var/log/secure和/var/log/messages里。使用file list /var/log找到对应的文件然后file view查看 FAILED 登录记录。如果没有外部日志这里的记录就是唯一证据要抓紧复制下来。3.3 应急响应的正确姿势确认或者高度怀疑被入侵后不要急着格式化重装。我的处理顺序是隔离在防火墙上挂掉受影响 CUCM 节点的业务流量但保留一个单独管理 VLAN 的入口方便取证和后续操作。这一步能阻止攻击者继续回连。复制现场用show status、show version active记录当前状态用file get把关键日志和可疑文件取回到本地取证机。注意取回的文件要做哈希保存方便后续追责。查清除在断网环境下杀掉可疑进程删除后门文件清理 crontab 和 SSH authorized_keys。但这只是临时处置攻击者可能把持久化脚本写进数据库存储过程里所以一定要恢复到干净的备份再重新升级。联系厂商思科 TAC 对商业客户提供漏洞应急支持可以开 Case 让他们给初始清洗建议。如果不走商务至少要去思科安全公告页面下载最新的入侵指标IoC文件用于扫描。密码重置所有应用账号、AD 服务账号、数据库账号、SSH key 都要重新生成。特别注意 CUCM 与 AD 同步的账号密码如果被泄露要联动域管理员统一修改。应急响应最大的忌讳是“只升级不查后门”。补丁修的是漏洞但攻击者留下的后门不会自己消失。升级前不清扫等于边修门边给黑客留钥匙。3.4 把检测规则接到SIEM里如果你有集中日志平台建议把 CUCM 的 HTTP 访问日志和 syslog 都接进来。我通常会加一条关联规则监控来源 IP 不在管理网段、却访问了高危路径的请求。比如 Splunk 风格的大致写法indexucm sourcetypecucm_http ( uri_path*/bin/* OR uri_path*/servlet/* ) NOT src_ip192.168.10.0/24 | stats count by src_ip, uri_path, user_agent这样能快速筛出可疑请求。CVE-2026-20045 这种 Web 接口漏洞攻击手法无论怎么变形总要在 URI 里留下异常特征。提前把源 IP 限制和管理网段白名单做进规则里就能把大量扫描噪音过滤掉只留下真正需要人工研判的告警。4. 升级和加固过程中的常见坑4.1 升级后半死机发布方/订阅方版本不一致这次处理 CVE-2026-20045 时有客户升级订阅方一半业务那边就开始报话机注册失败、呼叫断线。查下来原因是订阅方执行了升级但发布方还在旧版本集群内部版本协商失败导致 CallManager 服务反复重启。遇到这个情况先别急着重启所有节点。用show status看每个节点的版本如果订阅方显示的是 “installing inactive”需要执行utils system activate激活新版本如果发布方还在跑旧版本先等发布方完成激活再重启所有节点让服务加载一致。升级期间建议把电话路由临时重定向到备用网关或者至少做好业务通知。4.2 备份恢复你以为备份了其实没备全备份 CUCM 是个经典大坑。很多运维只做了“配置备份”结果升级后在恢复阶段发现批量话机证书没同步设备全部处于 “Rejected” 状态。CUCM 的完整备份要包含平台配置、CDR/CMR 数据、详细呼叫记录、TLS 证书与信任库、LDAP 目录配置、电话固件和铃声文件。具体操作时除了用utils backup store backup之外我建议再导出一份安全设置文件Platform Administration 页面里的 Security Settings并且把/usr/local/cisco/ssl目录整体拷贝到离线存储。证书丢了语音网关和话机都会不认。这个坑踩一次能痛一晚上。4.3 别忽略磁盘空间CVE-2026-20045 的补丁是 COP 文件体积一般在几百 MB 到 1GB。上传后系统会先解压再执行安装需要至少两倍于补丁大小的临时可用空间。如果/分区剩余空间不足 20%升级过程会直接中止有时候还会把系统卡在不可用状态。升级前用show disk usage看看每个挂载点的使用率。别看 CUCM 平时磁盘占用不高上面挂着好多日志和 CDR 文件空间经常不知不觉就满了。遇到空间不够先清理/var/log/active/platform/log下的老日志或者手动归档到外部存储。4.4 模拟器环境不要照搬生产配置最后说一个被很多人忽略的问题。不少兄弟喜欢在 GNS3 或者 EVE-NG 里搭“思科模拟器”练手特别是配合“基于源地址策略路由实训指导书”做实验这个思路本身是好的。但模拟器里的 CUCM 或者交换机固件版本非常老而且没有打过最新补丁。如果你把模拟器里导出的配置模板直接拿到生产环境往往带着一堆默认密码、开放端口和过时配置。更危险的是模拟器里没有真实业务流量你可能压根不会发现服务的 ACL 配错了、管理接口对全网段开放。生产环境补丁固然重要但模拟环境里养成的安全配置习惯同样重要。既然这次要处理 CVE-2026-20045不如顺手把模拟器里的配置也按生产标准过一遍养成默认拒绝、最小开放的习惯。4.5 升级后的功能验证清单升级完成不代表结束。我每次升级后会按下面这个清单逐项验收缺一项我都不会关变更工单检查项命令或位置期望结果节点版本一致性show version active所有节点显示相同修复版本服务状态show status关键服务是 Active没有反复重启话机注册CM 管理界面 Device 页面注册率恢复到升级前的 99% 以上内部呼叫测试utils test call分机互拨正常接通率无异常外部 SIP 中继抓包确认 5060/5061中继状态 Active呼叫无单通LDAP 同步管理界面 User Management用户目录同步成功无报错CDR 生成查看 CAR 报表新通话记录持续写入这一套走完才算真正把 CVE-2026-20045 的处置闭环。升级后 24 小时内记得盯一下系统日志确认没有异常进程或回连。5. 一点个人经验送给大家这次处理 CVE-2026-20045 的三个现场我最大的感受是统一通信系统的运维往往被划给语音组但语音组和网络安全组经常是脱节的。语音设备要对外开端口却很少有人把 ACL、日志告警和执行升级这些事当成重点项目。漏洞爆发后大家都开始补课把 CUCM 的 syslog 接进 SIEM把出站的异常流量全部加了阻断策略。我个人在处理完这三个环境后又专门回机房把每一台思科语音设备的部署时间、版本、管理员 IP 重新登记了一遍然后统一在接入层加了一道 VLAN ACL把管理口死死锁在运维网段。另外有个小技巧如果你暂时无法升级可以在做维护窗口的前一天在虚拟化层对 CUCM 虚拟机做一次快照。补丁出了问题可以秒级回滚个人实测比任何备份方案都省心。但注意快照不能作为长期回退手段确认补丁稳定后 48 小时内一定删除快照以免撑爆存储。这篇关于 CVE-2026-20045 的处置经验就先写到这里。我也在等更多外部情报用来补充检测规则库后续有新发现再开一篇更新。希望这篇内容能帮到同样在跟这个漏洞的兄弟姐妹少走几个坑。