分析 CVE-2026-20230 中 Cisco Unified Communications Manager 的 SSRF 到任意文件写入及 RCE 漏洞，提供 PoC 推导、检测逻辑与防御指导。

更稳妥的判断应当采用多阶段证据组合：

1. 确认目标是 Cisco Unified CM / Unified CM SME。
2. 确认 WebDialer 服务处于启用状态。
3. 确认能获取目标真实 hostname 或内部服务标识。
4. 确认 SSRF 入口可达，且存在服务端发起内部请求的迹象。
5. 在授权靶场中确认是否能产生受控文件写入证据。
6. 结合服务端日志、文件系统变更、Web 容器日志和告警数据判断是否真正触发。

只有“WebDialer 启用 + 受影响版本 + SSRF 行为成立 + 受控文件写入成立”同时出现时，才应将其判断为高可信可利用。

3. PoC 构造思路

当前公开利用链的核心不是单纯 SSRF，而是 SSRF 与 Axis/Java Web 服务机制、日志写入或部署描述文件处理逻辑之间的组合利用。

整体思路可以概括为：

从链路设计看，hostname 是一个关键点。部分过滤逻辑会拦截 127.0.0.1、localhost 等常见本地地址，但目标真实 hostname 可能被允许进入后续请求流程。因此，PoC 会先从 WebDialer 的 WSDL 信息中提取真实主机名，再将其作为 SSRF 链路中的内部访问前缀。

第二个关键点是 Axis 服务相关逻辑。PoC 并不是直接向 Web 目录上传文件，而是通过内部服务处理链，使服务端组件将攻击者可控内容写入到特定路径。该过程本质上是“服务端内部请求 + 组件配置/日志写入行为 + 路径穿越/路径控制”的组合。

第三个关键点是二阶段写入。第一阶段通常用于建立一个更稳定的文件写入入口，第二阶段再将命令执行脚本写入 Web 可访问目录。这样做的原因是，直接通过 SSRF 一步写入完整命令执行逻辑可能受编码、长度、XML 结构、路径权限和服务端解析行为影响，而二阶段方式更容易把复杂载荷拆开。

本文不提供完整利用报文和 WebShell 内容。防护与验证时只需要理解以下核心特征：

4. hostname 获取逻辑

PoC 首先需要获得目标的真实 hostname，而不是只使用 IP 地址或外部域名。

原因在于 SSRF 过滤逻辑并不一定只判断最终连接目标，还可能对 hostname 字段、URL 字符串、本地地址关键字等进行校验。常见的 127.0.0.1、localhost 等本地地址可能会被阻断，而设备真实 hostname 在某些场景下会被视为合法节点名。

可用于辅助判断的接口通常与 WebDialer WSDL 信息有关。访问该类 WSDL 后，响应中可能包含服务地址、location 字段或其他可解析的主机标识。PoC 会从响应文本中提取 URL 中的 hostname，并将其作为下一阶段 SSRF 的内部访问目标。

这个阶段的判断口径应当是：

1. WSDL 接口是否可访问。
2. 响应内容是否符合 WebDialer / Axis 服务特征。
3. 是否能从响应中解析出真实 hostname。
4. 解析出的 hostname 是否不同于外部访问 IP 或域名。
5. 该 hostname 是否能被后续 SSRF 入口接受。

如果 hostname 解析失败，PoC 可能会回退到目标 IP，但这会显著降低成功率。真实环境中，hostname 解析失败常见原因包括 WebDialer 未启用、接口被访问控制限制、响应被反向代理改写、证书或服务配置不完整。

5. SSRF 触发阶段

SSRF 触发点位于 cmplatform 相关安装状态查询逻辑中。该功能原本用于查询集群节点安装状态，服务端会根据用户提交的节点标识或 hostname 组装内部请求。

漏洞的核心问题在于，攻击者可控的 hostname 参数没有被严格限制为合法节点名或受信任主机，导致该参数可以被构造成更复杂的内部访问路径。服务端随后会代表攻击者向内部接口发起请求。

这个阶段的关键不是“能访问一个外部 URL”，而是“能让 CUCM 设备自身访问它内部可达的 WebDialer / Axis 管理接口”。因此，SSRF 的价值来自两个方面：

1. 绕过外部网络访问限制，触达只能由本机或内部组件访问的服务路径。
2. 借助内部服务信任边界，将普通 HTTP 参数转化为内部组件操作。

在授权验证中，不能仅凭 HTTP 状态码判断 SSRF 成功。更可靠的证据包括：

1. 服务端日志出现对内部路径的访问记录。
2. 请求响应内容中出现内部接口特征。
3. 后续 WebDialer services 页面出现新增或异常服务痕迹。
4. 文件系统中出现由服务端进程创建的异常文件。
5. 安全设备记录到 hostname 参数中包含异常路径、编码内容或内部服务路径。

6. Axis 服务写入与任意文件写入思路

公开链路中，SSRF 被进一步用于访问 Axis 相关服务接口，并尝试写入服务部署描述内容。攻击者通过构造特殊的 XML/WSDD 结构，使服务端组件在处理过程中把可控内容写入指定路径。

这一阶段的本质不是传统文件上传，而是滥用服务端组件的处理逻辑：

从安全分析角度看，这里有几个关键点：

1. 写入目标路径通常需要穿越到 Web 容器可访问目录。
2. 写入内容需要满足服务端组件处理格式，否则可能只产生无效文件。
3. 写入文件的属主和权限取决于 Tomcat / CUCM 服务进程。
4. 如果写入位置可被 Web 访问，文件写入就可能进一步转化为脚本执行。
5. 如果写入位置不可执行，也仍然可能造成配置污染、持久化或后续提权条件。

因此，CVE-2026-20230 的高危点并不只是 SSRF，而是 SSRF 能跨越信任边界，进入内部管理/服务部署链路，并最终触发可控文件写入。

7. 二阶段 WebShell 写入逻辑

PoC 设计中通常会采用二阶段写入，而不是一步完成命令执行。

第一阶段用于创建一个简单的文件写入能力。这个阶段的目标是让攻击者可以通过一个 Web 可访问路径向服务器指定位置写入内容。

第二阶段再利用第一阶段写入能力，将命令执行脚本写入到 Web 可访问目录。随后攻击者即可通过 HTTP 参数触发系统命令执行。

二阶段设计的优势是：

1. 降低单个 SSRF 请求中的载荷复杂度。
2. 避免 XML、URL 编码、特殊字符转义导致载荷损坏。
3. 将“部署服务”和“写入最终执行文件”拆开，便于调试。
4. 更容易在不同目标路径上调整落点。
5. 使后续命令执行阶段与 SSRF 阶段解耦。

但从防护角度看，二阶段写入也带来更清晰的检测面：

1. 第一次异常请求通常会尝试创建新服务或写入中间 JSP。
2. 第二次异常请求通常会访问中间 JSP 并携带文件名、文件内容等参数。
3. 第三阶段会访问最终命令执行 JSP，并携带认证口令或命令参数。
4. Web 访问日志中会出现短时间内连续访问 WebDialer、services、axis2-web、platform-services 等路径的行为。
5. 文件系统中可能出现异常 JSP、异常服务名、异常日志文件或新增 Web 资源。

8. 当前 PoC 的完整执行流程

当前 PoC 的流程可以概括为：

1. 解析目标地址。
2. 访问 WebDialer WSDL，尝试提取真实 hostname。
3. 构造 SSRF 请求，目标是内部 WebDialer / Axis 管理路径。
4. 通过内部请求写入 Axis 服务相关内容。
5. 访问 services 页面，检查异常服务是否部署成功。
6. 调用新服务，写入第一阶段文件写入脚本。
7. 访问第一阶段脚本，写入第二阶段命令执行脚本。
8. 访问第二阶段脚本，执行测试命令。
9. 根据 HTTP 响应、文件落地结果和命令输出判断利用是否成功。

从利用成功率看，最关键的失败点通常集中在：

1. WebDialer 未启用。
2. hostname 解析失败或被过滤。
3. SSRF 请求没有真正进入内部服务。
4. Axis 服务部署失败。
5. 路径穿越落点不适配目标版本。
6. Web 目录不可写或脚本不被执行。
7. 目标已打补丁或使用 Cisco 临时修复包。
8. 代理、WAF、EDR 或文件完整性监控阻断了中间阶段。

因此，该 PoC 在特定受影响版本和默认路径匹配时可利用性较高，但并不是对所有 CUCM 资产都稳定通杀。

9. 成功判断逻辑

CVE-2026-20230 的成功判断不能只看脚本是否跑完。更合理的判断应分为四档。

第一档：目标疑似暴露

条件是：

这只能说明目标存在相关攻击面，不能证明漏洞可利用。

第二档：漏洞疑似存在

条件是：

这种情况下应继续结合服务端日志或授权靶场做验证。

第三档：文件写入确认

条件是：

到这一档时，可以确认漏洞链已经突破普通 SSRF 阶段，进入任意文件写入风险。

第四档：RCE 确认

条件是：

只有这一档才能判断为远程命令执行成立。文件写入成功不必然等于 RCE 成功，但在 CUCM 这类高权限服务环境中，文件写入已经足以构成严重风险。

10. 使用示例

本文不提供可直接用于攻击的 exploit 执行示例。

在授权环境中，建议优先使用“只读式检查”或“非破坏性验证”方式，例如：

建议检查项包括：

1. 目标是否为 Cisco Unified CM / Unified CM SME。
2. WebDialer 服务是否启用。
3. WSDL 是否可访问。
4. services 页面是否暴露。
5. 目标版本是否低于修复版本。
6. 是否存在异常新增 JSP、异常 Axis 服务或异常日志写入痕迹。

不建议在生产系统上执行完整写文件或命令执行验证。即使是授权测试，也应优先在隔离靶场、快照环境或厂商建议的验证流程中进行。

11. PoC 设计中的安全边界

该类 PoC 的安全边界必须明确。

第一，不应默认执行命令。命令执行阶段属于高风险验证，容易造成系统状态改变、日志污染、服务异常或安全设备联动响应。

第二，不应默认写入 WebShell。即使写入的是测试文件，也可能被 EDR、WebShell 查杀、文件完整性监控或合规审计系统判定为真实入侵行为。

第三，不应对公网目标批量探测。该漏洞无需认证，且目标多为企业通信基础设施，未授权扫描和利用风险极高。

第四，检查模式应与利用模式分离。建议将 PoC 拆成两个脚本：一个只用于资产识别和服务状态判断，另一个只在本地靶场或明确授权环境中验证文件写入。

第五，应限制目标范围。PoC 可以加入本地地址、私有网段、白名单域名、授权确认参数等保护机制，避免误打第三方系统。

第六，应默认禁用 RCE 阶段。即使保留研究代码，也应要求用户显式传入授权确认参数后才允许进入文件写入或命令执行验证。

12. 对防护规则编写的启发

从流量检测角度看，不能只匹配某一个固定文件名、固定服务名或固定 JSP 名称。公开 PoC 中的服务名、文件名和路径都可以被修改，单一字符串规则容易漏报。

更合理的检测思路是围绕攻击链阶段提取特征。

第一类：信息获取阶段

重点关注：

如果短时间内外部客户端访问 WSDL 后又访问 cmplatform 安装状态接口，应提高风险级别。

第二类：SSRF 触发阶段

重点关注：

这个阶段的关键是 hostname 参数不再像普通主机名，而是出现路径化、URL 化、编码化和 XML 化特征。

第三类：Axis / WSDD 注入阶段

重点关注：

这些字段同时出现时，应高度怀疑攻击者正在尝试通过 Axis 服务部署描述文件写入可控内容。

第四类：文件写入阶段

重点关注：

攻击流量中如果出现大量 ../、URL 编码路径穿越、JSP 扩展名和 Tomcat WebApp 路径，应判定为高危。

第五类：命令执行阶段

重点关注：

从规则设计角度看，建议采用分阶段检测：

1. WebDialer 信息获取：低危或中危告警。
2. cmplatform SSRF 异常 hostname：高危告警。
3. Axis/WSDD/LogHandler 组合特征：严重告警。
4. JSP 文件写入或命令执行参数：严重告警。
5. 多阶段关联命中：直接升级为入侵事件。

13. 排查与取证建议

应急排查时建议重点检查以下位置和现象：

1. WebDialer 访问日志中是否存在异常 WSDL 和 services 枚举。
2. cmplatform 访问日志中是否存在 installClusterStatusExecute 异常请求。
3. hostname 参数是否包含 URL 编码、路径穿越、Axis、WSDD、LogHandler 等内容。
4. Web 目录下是否出现异常 JSP 文件。
5. Axis services 页面或配置中是否出现异常服务名。
6. Tomcat 日志、平台服务日志中是否出现异常部署描述、XML 解析错误或路径写入记录。
7. /tmp、WebApp 目录、日志目录中是否出现测试文件或未知文件。
8. 是否存在短时间内由同一源 IP 发起的多阶段连续访问。
9. 是否出现异常系统命令执行痕迹、进程创建记录或 shell 相关行为。
10. 是否存在 root 权限相关异常文件、计划任务、启动项或持久化痕迹。

如果怀疑已被利用，应优先隔离管理面访问，保留日志和文件系统证据，再进行补丁升级、WebShell 清理、异常服务清理和账户/凭证轮换。

14. 修复与缓解建议

根本修复方式是升级到 Cisco 官方修复版本或应用官方提供的临时修复包。

通用处置建议如下：

1. 立即确认 Unified CM / Unified CM SME 版本。
2. 检查 WebDialer 服务是否启用。
3. 如果业务不需要 WebDialer，立即禁用该服务。
4. 升级到 Cisco 官方修复版本。
5. Release 15 环境如暂时无法升级，应根据 Cisco 指引应用对应 COP 文件。
6. 限制管理面和 WebDialer 相关服务的访问来源。
7. 在边界设备、WAF、IDS/IPS 上增加针对 cmplatform、WebDialer、Axis/WSDD 异常请求的检测。
8. 检查是否已经出现异常 JSP、异常 Axis 服务或未知文件。
9. 对已暴露系统进行日志回溯，重点覆盖 2026 年 6 月 3 日之后的访问记录。
10. 如果发现文件写入或命令执行证据，应按主机失陷处理，而不是只做补丁升级。

15. 总结

CVE-2026-20230 的关键不在于单个接口暴露，而在于 CUCM WebDialer、cmplatform 安装状态查询逻辑、内部 Axis 服务处理和文件写入能力之间形成了可串联的信任边界失效。

这条链路可以概括为：

实际可利用性取决于 WebDialer 是否启用、目标版本是否受影响、hostname 过滤是否可绕过、路径落点是否匹配、Web 容器是否执行写入文件，以及目标是否已应用补丁。

从防守角度看，不能只依赖“是否存在某个 JSP 文件”来判断攻击。更稳妥的方式是围绕多阶段链路进行关联检测：WSDL 信息获取、cmplatform 异常 hostname、Axis/WSDD 特征、路径穿越写入、JSP 落地访问和命令参数访问。只要其中多个阶段在短时间内由同一来源连续出现，就应按高危入侵事件处理。

References

• Cisco Security Advisory: Cisco Unified Communications Manager Server-Side Request Forgery Vulnerability
• NVD: CVE-2026-20230
• SSD Secure Disclosure: Cisco Unified Communications Manager Arbitrary File Write to RCE
• Cisco Unified CM / Unified CM SME 官方升级与 COP 修复说明