导语：一段 14 秒的终端录屏，300 个 A，root shell。视频在网上传开，401 个赞、52 次转发，评论区吵成一锅粥。可最让人后背发凉的不是这洞怎么进，而是它躺了十年，愣是没人报过。
14 秒，逐帧拆开
视频来自 X 上 @0x0SojalSec 的帖子，我抽帧数了一遍：
第一帧，ssh root@alpine-cloud，密码敲 wrong，回一句 Permission denied, please try again.。正常人的正常失败。
第二帧，密码框里塞进一长串 A，刷过八行，屏幕回一句 Welcome to Alpine!，提示符变成 alpine-cloud:~#。第三帧，id，uid=0(root)。
截图来源：X @0x0SojalSec 演示视频
顺手做了一件没人做的事：把视频里的 A 一个一个数出来。终端宽 47 列，第一行扣掉 root@alpine-cloud's password: 这 30 个字符，剩 17 个 A；接着 6 行整行 47 个；最后一行 1 个。17 + 47×6 + 1 = 300 个 A，不是评论区念叨的 257。
257 是下限——musl 的 sha512crypt 超过 256 字节直接失败，往上到 1024 都有效。而发现者 Özgün Kültekin 主页 sshhole.com 的在线演示，按钮就叫「300 × A」，这视频八成就是拿那个 demo 录的。
十年，它一直躺在那儿
这洞的技术细节不复杂，但存在时间长得很离谱。它长得也不像漏洞：Unix 用 表示「此账号无密码」是老约定，musl 2012 年把 crypt() 的失败返回值改成 ，OpenSSH 2016 年又让「无哈希账号也借盐算一遍」——三个团队、三个时间点，谁都不知道另外两家的写法，像三块石头垒成了洞。
更吓人的是它不需要任何异常操作：crypt() 在口令超长时不报错，返回单个字符 ；sshd 拿它和 /etc/shadow 里的 做字符串比较，相等，放行。没有内存越界，没有暴力破解，就是一次普通登录。
那为什么十年没人报？发现者在复盘里写过一句话，比 CVE 解释更狠：
也许有人发现过。也许有人把错误的东西粘进了密码提示框——半条 Slack 消息，或者一整串 SSH 私钥——然后它就放他进去了。你从来没往密码框里粘错过东西吗？
密码框不回显，没有长度上限提示，粘错了和粘对了在屏幕上长得一模一样。一个管理员手滑把半条命令粘进密码提示符，系统就把他放进去了。他多半以为键盘有毛病，不知自己刚拿到 root。
于是「十年零报告」可能不是「十年没人遇到」，而是十年里没人把「粘错了」和「被入侵」联系起来。测试也抓不到：OpenSSH 在 OpenBSD 和 glibc 上测，musl 这边不测 sshd；大多数发行版走 PAM，PAM 对 * 账号压根不调 crypt。257 这个长度在日志里几乎不出现——没人会统计一个失败的口令有多长。
评论区最热的三个说法，全错
「这不就是经典的缓冲区溢出，撑爆了长度检查」——不是。整条链路上没有任何内存越界、没有越界写、没有内存破坏，全是字符串比较。
「这就是后门，去查查当初是谁提交的」——也不是。后门得有人故意留，这里是石头自己垒成的。
「AI 挖出来的，功劳不能算研究者的」——这条最接近事实，但方向反了。OpenSSH 自己在 10.6 发布说明里写得很清楚：最近收到的大量安全报告，很多来自 AI 模型或 AI 辅助；已看到多个「AI 工具发现的 bug 随后被另一位研究者独立复现」的案例，因此决定更频繁地发版。
研究者本人也不含糊：「哦等等我刚才说『我』？抱歉，我有一大群 agent swarm。」17600 次畸形登录是对着六种编译组合扔的。人没被取代，但探测半径变了。
别照抄视频：你的 Alpine 上大概率不是这个画面
视频里直接 ssh root@alpine-cloud 就进去了。但 Alpine 官方公告写得很清楚：root 从 3.16 前后起在基础镜像里就是 root:*，而 OpenSSH 默认的 PermitRootLogin prohibit-password 把 root 的密码登录挡在门外——只有显式设了 PermitRootLogin yes 才能直接登。那台 alpine-cloud 是研究者的实验机，配置被他动过，照着视频在生产 Alpine 上敲一遍，连密码提示符都看不到。
真实世界里最容易被打的，恰恰是不用改任何配置的那种：Alpine 官方云镜像（AWS/Azure 的 tiny-cloud，3.18.11 到 3.24.3）里那个 alpine 用户，密码位是 *，还带免密 doas。进去是 alpine，出手就是 root。
四个前提条件要同时成立：musl 系统、不走 PAM、PasswordAuthentication yes（默认值）、机器上同时有一个 * 账号和一个 $5$/$6$ 哈希账号。最后一条最反直觉——一个带正常密码的账号就能让所有没密码的账号沦陷，它只提供一把盐。
时间线，和今天该干什么
- 10 月 30 日：OpenSSH 修
pick_salt()，这洞就在那段代码下面四行 - 11 月 3 日前后：研究者找到它
- 11 月 5 日：OpenSSH 10.6p2 发布，Alpine 同步发包
- 11 月 6 日：视频传开
现在要做的：
apk upgrade openssh
rc-service sshd restart # 升级不会自动重启 sshd，漏了这步等于没修来不及打补丁，PasswordAuthentication no 能立刻止血。改完先确认密钥登录还能用，别把会话断手里。
顺手查一遍有没有被登过：
grep "Accepted password" /var/log/messages
grep '^alpine:' /etc/shadowshadow 里密码位是 *，日志里却有它的密码登录成功记录，那就该查了。
收尾
CVE-2026-123158，CVSS 8.1，OpenSSH 10.6p2 修了，暂没没有野外利用报告。但别当成安全保证：这洞不需要爆破、不需要撞库、一次连接直接进门，而 Alpine 是容器和云镜像的顶流底座。
更要紧的是那十年留下的账还没算清——那些粘错过东西的人可能还坐在工位上当管理员，不知自己那次「手抖」是什么。
所以该补的不只是下一个补丁，还有这条日志规则：*当密码位为 的账号出现 Accepted password 记录时，按入侵告警处理，别当配置错误。** 教训不在洞，在没人看的那行日志。
资料来源
- X 平台 @0x0SojalSec 演示视频（2026-11-06）
- sshhole.com：发现者 Özgün Kültekin 的技术复盘
- OpenSSH 10.6p2 官方发布说明与安全公告
- Alpine Linux 官方安全公告（2026-11-05）
版权声明：本文由华盟网原创发布，保留所有权利。漏洞利用仅用于授权测试与防御研究。
暂无评论内容