SSH客户端库曝高危0day：libssh2 PoC公开，或影响大量基础设施组件

看雪学苑
看雪学苑

看雪学苑

2026年6月29日 17:59
上海

在小说阅读器读本章

去阅读

近日，SSH客户端库 libssh2 被披露存在高危内存破坏漏洞（CVE-2026-55200），并且已有公开PoC流出。该漏洞允许恶意SSH服务器在客户端建立连接的过程中触发内存破坏，极端情况下可导致远程代码执行。

由于该漏洞发生在客户端侧SSH实现，其影响面远比传统服务器漏洞更隐蔽，也更难排查。

漏洞核心：SSH握手阶段“长度溢出”引发内存破坏

该问题出现在 libssh2 的 ssh2\\_transport\\_read() 处理逻辑中。

• 在SSH握手过程中，程序会解析服务端发送的数据包长度字段 packet\_length，但在早期版本中：
• 仅检查“是否小于1”
• 未限制“最大长度”
• 在后续计算中使用32位整数运算

攻击者可构造极大值（如 0xffffffff），触发整数溢出：

1. 长度计算发生回绕，变成极小值

2. 程序按“很小的长度”分配缓冲区

3. 实际写入却按“真实大包”执行

4. 最终造成堆溢出写入（Out-of-bounds write）

该问题本质属于 CWE-680（整数溢出导致缓冲区溢出），是典型可利用的内存破坏原语，在一定条件下可演化为代码执行。

影响范围：不仅是libssh2，而是整个依赖链

libssh2 并不是一个孤立库，它广泛嵌入在多个基础设施组件中，包括：

• curl
• Git
• PHP
• 以及各类备份工具、固件升级程序、企业中间件等

更关键的是：

大量产品采用“静态编译”方式集成 libssh2

这意味着系统级升级无法自动覆盖漏洞组件

这类“隐藏依赖”往往是企业资产清单中的盲区。

攻击条件：无需账号、无需交互

从安全影响来看，该漏洞危险性主要体现在：

• 攻击发生在SSH连接建立阶段
• 无需任何认证信息
• 无需用户交互
• 只需连接到恶意SSH服务器即可触发

换句话说，只要客户端程序会“主动连接外部SSH服务”，就可能被利用。

PoC已公开，但暂未发现野外攻击

研究人员已在 GitHub “exploitarium” 仓库中公开相关PoC代码，该PoC属于“局部验证级别”：

• 可触发漏洞路径
• 可验证内存破坏
• 部分环境下可实现本地RCE模拟

但要实现稳定远程利用，还需依赖：

• 目标程序的内存布局
• allocator行为差异
• 编译优化与缓解机制
• 不同嵌入方式的实现差异

目前安全机构评估认为，该漏洞尚未出现真实攻击行为。

漏洞时间线

• 6月12日：补丁提交合并（PR #2052）
• 6月17日：漏洞编号正式发布
• 研究人员：Tristan Madani
• 披露机构：VulnCheck
• 当前状态：尚无正式修复版本发布，仅主线修复
• 各发行版：通过回溯补丁方式修复（如Debian测试分支）

同时，英国 NHS Digital 已发布相关安全提示，建议受影响组织尽快排查。

额外风险：同批次还存在其他漏洞

本次披露并非单点问题，还包括：

• CVE-2026-55199：连接客户端可能陷入CPU循环（DoS）
• CVE-2025-15661：SFTP读取导致堆越界读取

说明该代码路径并非首次出现设计缺陷，而是“历史问题的延续”。

安全建议

在官方稳定版本发布前，建议采取以下措施：

1. 全面资产排查

• 查找所有依赖 libssh2 的组件
• 特别注意静态编译版本（无法通过包管理器发现）

2. 及时应用补丁

• 使用包含 commit 97acf3d 的版本或回溯补丁
• 跟踪各发行版安全公告更新

3. 网络层临时缓解

• 限制客户端对外SSH连接目标
• 仅允许可信主机
• 强化DNS与路由防劫持检测

4. 行为监控

• 关注异常大包SSH流量
• 客户端崩溃或握手异常
• 非预期外联行为

libssh2这类底层网络库的问题具有典型特征：它不显眼，但却深埋在大量基础设施之中。一旦漏洞出现在“客户端握手阶段”，其风险往往不是单点系统，而是供应链级别的扩散效应。

资讯来源：公开安全研究披露与漏洞通告整理

球分享

球点赞

球在看