Arista曝出四个OpenSSH漏洞：最高危问题藏在客户端

Arista Networks于2026年8月25日发布 Security Advisory 0147，确认多款产品所含的OpenSSH 10.4之前版本受到四个漏洞影响。按该公告采用的CVSS 3.1评分，最高的是9.4分的CVE-2026-60002：问题仅存在于SSH客户端，可能造成客户端进程崩溃或代码执行。

这项客户端漏洞要求受影响设备主动连接恶意或已失陷的SSH服务器，并由服务器在密钥重新交换期间更换主机密钥。因此，只通过管理ACL限制外部地址访问设备的SSH服务，只能收缩服务端风险，不能阻断管理员、自动化任务或设备组件发起的不可信出站SSH连接。

四个漏洞对应四条不同攻击路径

OpenSSH 10.4发行说明 记录了这四类修复：SFTP客户端可能把下载文件保存到意外位置；SCP在两个远程目的地之间复制时可能把文件写入目标目录的父目录；sshd在部分路径中未执行最低认证延迟；SSH客户端则可能在服务器重新交换主机密钥时发生释放后使用。

• CVE-2026-59995：攻击者控制的SFTP服务器可影响下载文件的本地落盘位置。利用需要用户主动下载，后果包括文件进入预期目录之外的位置。
• CVE-2026-59996：当SCP操作涉及两个远程目的地时，恶意服务器可能把文件写入预期目标目录的父目录。该问题同样需要用户主动发起相关操作。
• CVE-2026-60001：服务端sshd没有在所有路径中执行最低认证延迟，未经认证的攻击者可能加快密码猜测或用户名枚举；绕过延迟本身不会直接取得登录权限。
• CVE-2026-60002：SSH客户端在密钥重新交换期间处理服务器主机密钥变化时可能发生释放后使用。攻击面位于出站连接一侧，而不是设备对外提供的sshd端口本身。

9.4分问题为何不能靠入站ACL解决

CVE-2026-60002影响OpenSSH 10.4之前的客户端。Red Hat漏洞记录 确认释放后使用仅发生在客户端，并显示该问题已通过安全公告在RHEL 9、RHEL 10和OpenShift Container Platform 4.22中处理，说明它来自被不同厂商集成的上游OpenSSH代码，而非Arista独有实现。

在EOS平台上，SSH客户端默认可用，但触发漏洞仍需操作员主动建立出站连接。NDR还会使用SSH进行集群内部通信、连接堡垒机，以及在离线场景中获取升级和内容；在这些环境中，失陷的堡垒机、恶意或错误的DNS服务以及被错误引流的管理路径，都可能把客户端带到不可信对端。

入站ACL控制“谁能连接设备的sshd”，严格主机密钥检查和出站策略控制“设备会连接谁”。前者能够降低CVE-2026-60001的暴露面，却不会验证出站服务器的身份，也无法覆盖SSH、SFTP和SCP客户端中的三个漏洞。

受影响范围覆盖EOS、CloudVision及多款平台软件

四个漏洞共同影响EOS 4.36.2F及以下的4.36.x、4.35.5M及以下的4.35.x、4.34.7M及以下的4.34.x、4.33.10M及以下的4.33.x，以及更早版本。DMF部署还需核对随版本捆绑的EOS镜像：控制器版本未命中范围，不代表其管理的EOS交换机同样安全。

CVE-2026-60002还影响CVA 7.0.x至7.2.x、DMF 8.10.0及更早版本、MCD 8.10.0及更早版本、CCF 6.2.5及以下的6.2.x、NDR 5.4.10及以下，以及CloudVision Portal 2026.2.0及更早版本。CVE-2026-60001另行影响特定Wi-Fi接入点、CVA、DMF、MCD、CCF和NDR版本，资产筛查不能只围绕最高分漏洞进行。

CloudVision as-a-Service、CloudVision CUE、CloudVision AGNI、运行MOS的Arista 7130 Systems，以及NetVisor OS等被列为不受这四项漏洞影响。实际判断必须同时核对产品、软件版本和运行角色；关闭公网SSH并不能证明设备没有客户端侧风险。

升级前需分别约束入站服务和出站客户端

针对CVE-2026-60001，应将SSH管理入口限制在可信源地址，并优先使用密钥认证。CVA、DMF、CCF和MCD在删除允许全部IPv4及IPv6来源的默认规则前，需要先添加可信地址并验证连接，避免把合法管理员锁在系统之外。

针对CVE-2026-60002，应只连接已知服务器，并在接受连接前核对主机密钥指纹。EOS可以启用hostkey client strict-checking；没有出站SSH需求时，可通过RBAC限制bash和SSH命令。CloudVision Portal没有完整的纯配置缓解方案，需要避免节点连接不可信系统，并通过周边网络控制把出站SSH限制到必要目的地。

SFTP和SCP也要独立处理：只使用可信文件服务器，核对SFTP下载后的实际落盘位置，并检查SCP远程到远程复制的目标目录。没有相应业务需求时，可用RBAC禁止相关命令。这些措施补的是客户端信任边界，不能由入站管理ACL替代。

日志只能提供线索，不能单独证明利用

CVE-2026-60001没有唯一的入侵指标。短时间内异常密集的密码认证失败，可能意味着最低认证延迟被绕过；认证日志、LOGIN_FAILED记录和AAA计数器可用于发现异常，但普通扫描和错误凭据也会产生相似现象。

对于CVE-2026-60002，EOS上的SSH客户端异常终止以及/var/core/目录中的核心转储值得调查。CloudVision Portal的崩溃记录可能显示/usr/bin/ssh以SIGSEGV或SIGABRT终止；其他平台的默认日志通常不会完整记录客户端重新交换密钥的细节，因此命令审计只能证明连接被发起，不能证明服务器更换了主机密钥。

SFTP和SCP路径问题也没有专用告警。更直接的线索是文件出现在非预期目录，或远程复制的文件落入目标目录的父目录；调查时应把文件位置、操作账号、连接目的地、DNS解析结果和命令审计记录结合起来。

目前明确列出的修复版本仍有限

公告当前仅明确列出CVE-2026-60002的两个EOS修复分支：4.35.x需升级到4.35.6M或更高版本，4.34.x需升级到4.34.8M或更高版本。其余EOS分支、其他Arista产品以及另外三个漏洞尚未获得同等完整的修复版本矩阵，后续版本发布后清单还会更新。

这意味着“确认受影响”与“已有公告列明的修复版本”是两种状态。运行其他EOS分支、CloudVision、DMF、MCD、CCF或NDR的团队仍需等待适用版本信息；在完成升级前，应同时保留入站访问限制、出站目的地控制、严格主机密钥检查以及客户端命令权限约束。