OpenSSH 10.5/10.5p1 在2026年8月11日发布，修复了三处安全问题，新增FIDO密钥认证顺序优化和调试用的“ssh -Z”模式，同时把ECC（椭圆曲线密码，含NISTP521曲线）支持列为portable版本的硬性编译要求。这本是一份常规的季度维护公告，但release notes开头一段罕见的官方表态，比三处漏洞本身更值得琢磨：OpenSSH团队说，他们收到的安全漏洞报告里，很大一部分是AI模型生成或AI辅助完成的，而且已经出现过AI先发现、人类研究者后来独立复现同一漏洞的情况。
这意味着，即便某条AI报告在真实威胁模型下被判定“没有实际影响”，也不能掉以轻心——因为不主动报告漏洞的攻击者，很可能已经用同样的工具挖到了同一个洞。基于这个判断，OpenSSH宣布将改为更频繁发版，不再把修复攒到下一个计划版本里批量放出。
三处漏洞：谁报的，卡在哪
本次三处安全修复的报告人身份很杂：独立研究者sn0x-sharma发现了ssh-agent锁定状态与session-bind@openssh.com扩展的交互缺陷——本该只限本地使用的转发身份识别请求，在agent处于锁定状态时反而被拒绝，结果是原本该被限制在本地的操作（比如添加PKCS#11令牌）能被远程执行。
Cognatory的Brian Mingus报告并修复了ssh(1)客户端在特定时序下的realloc use-after-free。中国科学院计算技术研究所的研究者Erichen则发现authorized_keys里的restrict关键字没能正确限制隧道转发——不过隧道转发（PermitTunnel）默认是关闭的，这条漏洞在多数默认配置的生产环境里影响面有限，主要冲击那些主动打开了隧道转发的场景。
值得单独一提的是，Bugfixes一节里还收录了Anthropic研究员Christopher Paul Rohlf的两条建议：把公钥类型校验挪到密钥解析之前，减少预认证阶段的攻击面；以及修复ssh-keygen里的double free。这两条不算独立CVE级安全公告，但一家AI实验室的员工直接参与核心网络基础设施的代码加固，本身是过去几年少见的画面——AI公司和开源安全社区的关系，正在从“工具供应方”悄悄变成“共同维护方”。
强制ECC：谁会被卡住
Portable OpenSSH从10.5开始要求libcrypto必须支持ECC，包括NISTP521曲线。这对绝大多数用户是无感的——OpenSSL、LibreSSL、BoringSSL、AWS-LC的默认编译配置早就带ECC。真正需要留意的是那些用定制或裁剪版libcrypto构建、专门去掉了ECC模块的老旧系统，尤其是部分嵌入式设备和长期不升级的遗留发行版。这类用户接下来要么补上ECC支持重新编译，要么切到--without-openssl的构建路径，这条路不受本次改动影响。
核实这条新闻时，AI先编了个假CVE
写这篇稿子核实事实的过程本身，意外成了最好的注脚。原文release notes从头到尾没有出现任何CVE编号——这三处漏洞目前都没有被分配正式CVE，这在OpenSSH的历史惯例里并不罕见，中低严重度、依赖特定配置或时序才能触发的问题，往往走不到CVE申请那一步。
但联网检索工具在核实过程中，直接给这三处漏洞编造出了几个形如“CVE-2026-XXXXX”的占位编号，还有一个工具因为知识截止时间早于发布日期，判定“8月发布的版本尚不存在”。两种失误性质不同，但结果一样：都在没有真实依据的情况下，制造出了看似确凿的错误信息。
AI能挖出真漏洞，也能编出假编号，甄别力永远是稀缺资源
- 提醒.目前没有任何权威渠道给这三处10.5漏洞分配过CVE编号，网上如果出现“CVE-2026-XXXXX”字样的说法，大概率是检索或摘要工具的编造产物，不宜直接引用。
这恰好就是OpenSSH团队在release notes里想说的那件事：AI产出的信息，无论是漏洞报告还是新闻核实，都需要有经验的人去甄别。区别只在于，前者甄别错了可能漏掉真实漏洞，后者甄别错了只是多写一段更正。
接下来该看什么
OpenSSH这次没有承诺具体的发版频率，只说“会更频繁”。真正值得跟踪的是两件事：这三处漏洞是否会补发正式CVE，以及更密集的发版节奏会不会让下游Linux/BSD分销商和企业运维方感到升级疲劳——毕竟对大多数运维团队而言，“更安全”和“更频繁地被要求升级”常常是同一枚硬币的两面。