一句话结论
OpenSSH 修复 *sshole 漏洞，特定 musl 环境下超长密码可绕过无密码账户认证，高危风险需紧急更新。
关键要点
- CVE-2026-123158 评级 8.1，2026 年 11 月 5 日由 OpenSSH 10.6p2 正式修复，漏洞潜伏约十年。
- 触发前提：账户无密码（/etc/shadow 标记为 *）、启用 PasswordAuthentication，且系统使用 musl libc。
- 利用方式无需真实密码或私钥，输入 257～1024 字节任意超长字符串即可通过认证。
- 常规 glibc 系统（Ubuntu、Debian、Fedora）及 Dropbear 服务端不受影响，Alpine Linux 及衍生镜像风险最高。
- 截至 11 月 6 日未确认公开利用案例，但公网暴露的受影响服务应立即部署 10.6p2 或禁用密码认证。
背景与事实
OpenSSH 团队于 2026 年 11 月 5 日发布 10.6p2 紧急更新，修复了研究人员 Özgün Kültekin 发现的严重逻辑缺陷。该漏洞被命名为 *sshole，对应编号 CVE-2026-123158，在 CVSS 评级中达到 8.1 分的高危级别。相关代码片段最早可追溯至 2016 年，这意味着该缺陷在多个主流发行版中存在了约十年而未被察觉。
在标准的 Linux 安全模型中，/etc/shadow 文件中的星号 * 代表该账户没有有效的密码哈希值，因此无法通过传统的密码比对流程进行验证。对于这类账户，无论用户输入何种密码，SSH 服务端都应拒绝登录。然而，在采用 musl libc 的系统（如 Alpine Linux）中，其底层密码处理函数 crypt() 在处理超过 256 字节长度的输入时，会因处理失败而直接返回星号 * 作为错误标识。
漏洞的核心在于 OpenSSH 服务端与 musl libc 之间的逻辑交互错误。当攻击者提交一个长度为 257 到 1024 字节的任意字符串时，musl libc 的 crypt() 函数返回 * 表示错误，而 OpenSSH 在此特定上下文中错误地将两个星号 *（账户哈希与函数返回值的匹配）判定为“密码验证成功”。这种状态混淆导致原本应被拒绝的无密码账户被非法登录。值得注意的是，该漏洞仅影响未设置密码的账户；对于已配置有效密码哈希的账户，攻击者仍需提供正确的密码，此场景下漏洞无法利用。
Alpine Linux 由于广泛使用 musl libc 且常用于 Docker 容器及轻量级云服务，成为此次事件的主要关注点。研究人员特别指出，部分 Alpine 官方云镜像中的默认账户配置了免密执行 doas 的权限，这意味着一旦攻击者通过 *sshole 漏洞成功登录，即可直接提升权限至 root 级别，完全控制系统。Alpine Linux 官方已为多个版本分支提供修复补丁，包括部分已结束常规支持周期（EOL）的旧版本，以确保不同环境下的用户均可获取安全更新。
影响分析
对于中文开发者及运维从业者而言，此次漏洞的影响主要集中在容器化部署与边缘计算领域。鉴于 Alpine Linux 在 Docker 基础镜像中的高渗透率，使用非官方或基于 Alpine 构建的定制镜像进行微服务部署的团队面临直接的横向移动风险。分析判断，未关注底层 libc 差异而直接复用国内主流企业发行版（如 CentOS、Ubuntu）安全基线的团队，在引入 Alpine 组件时可能忽略了 PasswordAuthentication 的配置收敛。对于直接暴露在公网且未实施 SSH 密钥强制登录策略的服务器，此次事件构成了即时的高危暴露面。
进一步分析表明，该漏洞强化了“最小权限原则”在身份验证层面的重要性。技术细节的公开使得自动化扫描工具能够迅速构建检测探针，通过发送超长随机字符串并监控认证响应来识别易受攻击的主机。对于企业内网而言，即便没有互联网暴露，若存在内部跳板机或 CI/CD 节点运行受影响的 OpenSSH 版本，供应链内部也可能成为攻击跳板。建议团队立即对库存资产中的 Alpine 及 musl 系系统进行版本审计，并将“禁用密码认证”作为生产环境 SSH 服务的默认强制标准，而非可选配置。
适用边界
本结论不适用于使用 glibc 作为默认 C 库的主流发行版，包括 Ubuntu、Debian、Fedora 及 RHEL 生态；这些系统的 OpenSSH 实现未包含该逻辑错误。同时，采用 Dropbear 作为 SSH 服务端的嵌入式设备或轻量级系统不受此 CVE 影响。若目标账户在 /etc/shadow 中拥有有效的密码哈希值（非星号标记），则无论系统是否使用 musl libc，该漏洞均无法被触发。此外，如果 SSH 服务端配置已显式禁用 PasswordAuthentication，或强制要求使用 PAM 且 PAM 模块未出现相同状态混淆，则即使存在 musl 环境，攻击路径亦被阻断。
孤本观察
本次事件再次印证了基础组件逻辑交互被低估的风险，musl 与 OpenSSH 的耦合缺陷潜伏十年未现，暴露出上游社区对非主流 libc 生态的测试盲区。
来源：小众软件（https://www.appinn.com/openssh-sshole-cve-2026-123158/）
常见问题
CVE-2026-123158 的 CVSS 评级和正式修复版本号是多少？
CVSS 评级为 8.1，由 OpenSSH 10.6p2 于 2026 年 11 月 5 日修复。
利用该漏洞绕过认证的具体触发条件有哪些？
账户在 /etc/shadow 标记为 *（无密码），启用 PasswordAuthentication，且系统使用 musl libc。
攻击者输入多长字符串即可通过认证？
输入 257 至 1024 字节的任意超长字符串即可通过认证。
哪些常见 Linux 发行版或 SSH 服务端不受该漏洞影响？
使用 glibc 的 Ubuntu、Debian、Fedora 及 Dropbear 服务端不受影响。
哪些账户类型不受此漏洞影响？
已配置有效密码哈希值的账户，即 /etc/shadow 中非星号标记的账户。
来源：小众软件