Research
2026-06-30
libssh2曝CVSS 9.2预认证RCE漏洞：攻击面从服务器蔓延至所有客户端
内容摘要
核心要点
libssh2库的ssh2_transport_read函数在处理入站SSH数据包时，未对packet_length字段进行有效性校验。攻击者通过构造一个packet_length为0xFFFFFFFF（约4GB）的恶意数据包，诱导libssh2分配超大的堆内存，触发堆外写（Heap Out-of-Bounds Write）导致内存损坏，最终实现远程代码执行（RCE）。
该漏洞的CVSS 9.2评分源于其无需认证、无需用户交互的攻击特性。攻击者只需运行一个恶意SSH服务器，任何尝试连接该服务器的客户端（如使用curl、git、PHP的ssh2函数）都会在连接建立过程中被攻破。PoC已公开，大幅降低了攻击门槛。
影响版本为libssh2 ≤ 1.11.1，官方已在GitHub发布修复。但真正的威胁在于其广泛且隐形的供应链影响——curl、Git、PHP等核心工具均静态链接了libssh2，导致大量备份软件、文件传输工具、自动化框架、CI/CD平台（如Jenkins的SSH插件）、网络设备固件、Linux嵌入式系统及IoT设备均暴露在攻击面下。
重要性说明
这个漏洞本质上是一次攻击面重划：安全边界从“保护SSH服务器”彻底转向“保护每一个可能连接恶意服务器的SSH客户端”。
防守/合围谁？ 这不是针对某个特定厂商，而是对整个开源SSH生态的一次信任危机。它直接挑战了业界对libssh2作为安全传输库的信任假设。虽然OpenSSH不受影响，但大量依赖libssh2的应用（如curl、Git）构成了一个巨大的、未被充分审计的攻击面。
隐性锁定了什么资产？ 该漏洞绑架了所有SSH客户端的供应链资产。企业CI/CD流水线、自动化运维脚本、备份作业中使用的SSH连接，一旦目标服务器被攻陷或DNS被劫持，整个内网客户端机器都可能被瞬间RCE。
隐瞒了什么物理限制/成本陷阱？ 原文未强调补丁部署的极端复杂性。由于libssh2通常被静态链接，许多老旧或嵌入式应用无法通过简单的包管理器更新修复。企业需要逐项审计所有静态链接libssh2的二进制文件，并重新编译部署。对于嵌入式设备、IoT网关和网络固件，这可能意味着固件升级的漫长周期，甚至部分设备因厂商停止支持而永久暴露。
PRO 决策建议
【厂商】竞争对手（如OpenSSH、Paramiko等替代SSH库厂商）：立即发布安全公告，强调OpenSSH及自家库不受此漏洞影响，并针对libssh2用户推出迁移指南和兼容性测试工具。重点攻击libssh2的静态链接供应链风险，推广动态链接或更轻量的替代方案，抢占其市场份额。
【企业】CIO与架构师：立即启动紧急安全审计。
- 盘点所有资产：使用SBOM（软件物料清单） 工具扫描所有内部应用、CI/CD工具（如Jenkins）、备份软件、网络设备固件，识别哪些组件静态链接了libssh2。
- 实施零信任连接：临时限制所有SSH客户端仅允许连接到受信任的、已知的SSH服务器IP列表。部署SSH连接代理（如Teleport或Boundary）来强制审计和控制所有SSH流量，避免客户端直接暴露于恶意服务器。
- 重新编译与隔离：对无法立即升级的库，考虑将其隔离在容器化沙箱中运行，并监控其内存异常行为。
【投资者】评估开源安全供应商（如Snyk、Aqua Security、Chainguard）的长期价值。此类供应链漏洞事件将极大推动企业对软件供应链安全和SBOM管理的投入。同时，关注Zero Trust Networking和SSH替代方案（如Teleport）的厂商，它们将从这种信任危机中受益。
觉得这篇分析有用？
每周收到3-5条AI基础设施关键信号 →
💬 评论 (0)