OpenSSH 15年漏洞：一个逗号拿下root权限
一个逗号，15年，root权限
2026年4月，数据安全公司Cyera的研究人员向OpenSSH项目报告了一个漏洞。他们在测试证书功能时发现了一个”看起来不对劲”的行为——当证书主体名称中包含逗号时，OpenSSH的解析逻辑出现了异常。
20分钟后，他们拿到了测试服务器的root shell。
这个漏洞编号为CVE-2026-35414，严重程度评分CVSS 8.1。它存在于过去15年发布的几乎所有OpenSSH版本中。攻击者只需要一个由受信任证书颁发机构（CA）签发的、主体名中包含逗号的证书，就可以在存在漏洞的服务器上以root身份进行身份验证。
最可怕的是：这种攻击在日志中完全不可检测。服务器会认为这是一次完全合法的认证，不会记录任何失败尝试。
漏洞的技术根源：代码复用的代价
要理解这个漏洞，需要先理解OpenSSH的证书认证机制。
SSH证书是一种比传统公钥认证更灵活的机制。与TLS证书类似，SSH证书由CA签发，包含主体的身份信息（principals）——也就是证书持有者可以用于认证的用户名列表。服务器通过检查证书中的principals列表，决定是否允许认证。
CVE-2026-35414的问题出在principals的解析逻辑上。
OpenSSH代码库中有一个函数，原本用于处理密码和密钥交换列表协商。这个函数在密钥交换期间会比较以逗号分隔的密码列表，并按逗号进行拆分。如果其中任何一个片段与主体的值匹配，就会允许认证。
这个函数后来被复用到证书principals的验证逻辑中。但证书principals的处理逻辑与密码列表完全不同——principals应该是一个完整的字符串，而不是逗号分隔的列表。
结果就是：如果一个证书包含主体deploy,root，OpenSSH会按逗号拆分，得到deploy和root两个值。然后认证逻辑会检查这些值是否与服务器允许的用户名匹配。如果服务器允许root登录，攻击者就会获得root权限。
Cyera的研究人员这样描述：”该漏洞源于代码复用错误，意外地使解析器将证书主体中的一个普通逗号解释为列表分隔符，从而将低权限身份转变为root凭证。”
这是一个典型的代码复用陷阱——一个函数被设计用于场景A，后来被用于场景B，但场景B的假设与场景A不同，导致安全漏洞。
为什么15年没被发现？
15年。从OpenSSH的某个早期版本到2026年4月，这个漏洞一直存在。为什么这么久才被发现？
首先，SSH证书的使用相对小众。 大多数SSH部署仍然使用传统的公钥认证（~/.ssh/authorized_keys）。证书认证通常用于大规模企业环境，需要部署CA基础设施。使用证书的人少，发现漏洞的概率就低。
其次，逗号在主体名中不常见。 大多数SSH证书的主体名是简单的用户名，如alice、bob、deploy。包含逗号的主体名（如deploy,root）在正常场景下几乎不会出现。这意味着即使有人审查代码，也很难想到要测试这种边缘情况。
第三，漏洞的表现形式具有欺骗性。 当攻击者利用这个漏洞时，OpenSSH服务器会认为这是一次完全合法的认证。没有错误日志，没有异常提示，没有任何迹象表明发生了攻击。安全团队依赖日志检测威胁，但在这个漏洞面前，日志是沉默的。
第四，代码复用错误难以通过静态分析发现。 这个漏洞不是简单的缓冲区溢出或SQL注入，而是业务逻辑错误。静态分析工具很难理解”这个函数在场景A下是正确的，但在场景B下是错误的”这种语义层面的问题。
Cyera的研究人员从发现”看起来不对劲”到成功利用漏洞，只花了20分钟。但找到这个”不对劲”的地方，可能需要多年的安全研究经验和对OpenSSH代码的深入理解。
不可检测的攻击
CVE-2026-35414最危险的特点，不是它能获取root权限，而是它无法被日志检测。
在传统的暴力破解攻击中，安全团队可以通过分析认证失败日志发现异常——大量的失败尝试、来自异常IP的请求、非正常的登录时间。但在CVE-2026-35414攻击中：
- 攻击者持有由受信任CA签发的有效证书
- 证书通过所有密码学验证
- 认证过程完全符合协议规范
- 服务器记录的是一次成功的root登录
从日志的角度看，这与正常的管理员登录没有任何区别。攻击者甚至不需要隐藏自己的IP地址——因为日志中记录的是合法认证，没有人会去调查。
这意味着，如果一个组织的服务器运行了存在漏洞的OpenSSH版本，攻击者可能已经在内部潜伏了很长时间，而安全团队对此一无所知。
影响范围与修复
OpenSSH是全球使用最广泛的SSH实现，部署在数十亿台服务器上。从云服务器到嵌入式设备，从超级计算机到家用路由器，OpenSSH无处不在。
CVE-2026-35414影响过去15年发布的OpenSSH版本。这意味着：
- 大量长期未更新的服务器存在漏洞
- 企业内网中可能运行着旧版本OpenSSH
- 物联网设备和嵌入式系统的更新周期更长
- 某些关键基础设施可能无法立即打补丁
OpenSSH 10.3版本已于4月初发布，修复了这个漏洞。但对于许多组织来说，升级OpenSSH并不是一件简单的事——需要测试兼容性、协调维护窗口、更新配置管理脚本。
在此期间，攻击者有一个窗口期。
防御建议
对于运行OpenSSH的组织，以下措施可以降低风险：
立即审计SSH证书使用。 检查组织中哪些服务器配置了证书认证，哪些CA被信任，哪些主体名被允许。如果不需要证书认证，考虑禁用它。
升级OpenSSH。 尽快升级到10.3或更高版本。如果无法立即升级，考虑限制证书认证的使用范围，仅允许特定IP地址使用证书登录。
监控异常登录。 虽然CVE-2026-35414攻击在认证层面不可检测，但可以通过其他方式发现异常——如登录后的行为分析、命令审计、文件完整性监控。如果root账户突然开始执行异常命令，可能表明已被入侵。
审查CA签发策略。 确保证书颁发机构不会签发包含逗号的主体名。在证书模板中添加验证规则，拒绝包含特殊字符的主体名申请。
实施多因素认证。 即使攻击者利用漏洞获取了root权限，如果服务器配置了多因素认证（如YubiKey、TOTP），攻击者仍然需要第二因素才能完成认证。
更深层的思考
CVE-2026-35414是一个关于复杂性的警示。
OpenSSH是一个经过广泛审查的开源项目，由安全专家维护，遵循最佳实践。但即便如此，一个代码复用错误仍然潜伏了15年。这不是因为开发者不专业，而是因为软件系统的复杂性已经超出了人类能够完全理解的范围。
当我们谈论”安全”时，我们往往关注于补丁、防火墙、入侵检测系统。但CVE-2026-35414提醒我们，真正的安全威胁可能藏在最基础的代码逻辑中——一个逗号的解析错误，就能让15年的安全假设崩塌。
在软件工程中，有一个概念叫技术债务。这个漏洞是技术债务的利息——15年前的一个设计决策（复用函数），在15年后以安全漏洞的形式偿还。
对于依赖OpenSSH的数十亿台设备来说，这个利息的账单已经到期了。
信息来源