【資安快訊】2026-11月｜Linux 驚爆危機！OpenSSH 「SSHhole」漏洞 CVE-2026-123158 靠超長密碼秒攻破

本文由 耘鼎科技 GERTECH 整理撰寫分享

發布日期：2026/11/06

事件分類：漏洞預警

風險等級：High（CVSS 3.1 為 8.1）

原始來源：OpenSSH 10.6p2 發布說明

本文同時整理 Alpine Linux 2026/11/05 安全公告、iThome 2026/11/06 報導，以及 CVE 紀錄。各項資訊以來源頁面當時的內容為準，見文末免責聲明。

重點整理

• 出了什麼事？ OpenSSH 於 2026/11/05 發布緊急更新 10.6p2，修補一個被稱為 SSHhole 的漏洞，編號 CVE-2026-123158。在特定 Linux 上，沒有設定密碼的帳號（密碼欄是 *）可能被一段很長的任意密碼登入。
• 誰要擔心？ 同時符合這些條件的系統：使用 musl 這個 C 程式庫、OpenSSH 沒有啟用 PAM、SSH 密碼登入還開著。Alpine Linux 是最明確的例子。Debian、Ubuntu、Fedora 用的是 glibc，不在這次範圍。容器裡若沒有在跑 sshd，也不受影響。
• 嚴重程度？ CVSS 3.1 為 8.1（High）。攻擊複雜度被評為高，因為帳號與系統組態要先對上。對上之後，Alpine 寫這不需要猜密碼、也不需要重試。官方雲端映像若有一個名為 alpine、又能用 doas 變成 root 的帳號，登入該帳號就等於拿到整台機器。截至公開說明，還沒有在野攻擊被寫進原廠公告。
• 要做什麼？ ① 更新 openssh 並重新啟動 sshd，只升級套件不會換掉正在跑的服務；② 一時無法更新就先把 PasswordAuthentication 設成 no 再重啟，但要先確認金鑰登入真的能用；③ 到日誌找「沒有密碼的帳號卻出現 Accepted password」。

先搞懂幾個名詞

事件摘要

CVSS 8.1 分是怎麼來的？

8.1 配上 AC:H，讀法是：範圍比「所有 OpenSSH」窄，但對上條件的機器不需要破解密碼。

這個漏洞到底怎麼發生？

沒有設密碼的帳號，shadow 裡的密碼欄是 *。這個符號本來不該等於任何一把真正的密碼。OpenSSH 在沒有 PAM 時，會呼叫系統的 crypt() 把對方輸入的密碼做成雜湊，再和這個欄位比較。

musl 的 crypt() 在密碼超過它接受的長度時，失敗回傳的字串剛好也是 *。比較的兩邊都變成 *，登入就被當成成功。Alpine 寫，對方還需要這台機器上至少有另一個帳號帶著 $5$ 或 $6$ 的正常密碼雜湊；有一個這樣的帳號，所有密碼欄是 * 的帳號就都進得去。已設好正常密碼雜湊的帳號，不會被這招換成「任意長密碼就登入」。

長度在公開說明裡有 1 個字元的差距：Alpine 寫 257 到 1024 位元組，CVE 紀錄寫 256 到 1024 個字元。差別不影響要不要更新。

iThome轉述 Wakefield 的成因，是三個各自合理的修改疊在一起：

1. 2012 年，musl 改了密碼雜湊失敗時的回報，並限制密碼長度，避免超長密碼做成阻斷服務。
2. 2016 年，OpenSSH 7.3p1 為了避免用回應時間分辨帳號是否存在（當時的 CVE-2016-6210），改成即使帳號沒有可用的密碼雜湊，仍去做一次雜湊。
3. 2022 年，Alpine 調整 root 的密碼欄，讓只用金鑰的登入可以正常運作。官方映像後來因此帶著 root:*。

OpenSSH 的發布說明寫，他們認為根因不在 sshd，但攻擊會從 sshd 進來，所以先在 sshd 擋下。10.6p2 是這個擋法。Alpine 的舊版套件則是把同一份修正回補進去，所以版號仍可能是 10.3、10.0 或 9.x。

帳號「沒有密碼」，不等於「密碼登入這條路是關的」。* 是給金鑰登入用的寫法；這次剛好讓一段過長的輸入和這個符號對上。

可能造成什麼影響

1. 登入不該接受密碼的帳號：對方要知道帳號名稱，並連得到 SSH 埠。Alpine 寫，條件齊了之後一次連線就會成功。
2. 從雲端映像的 alpine 帳號變成 root：官方 tiny-cloud 映像（qcow2、VHD、AMI）在 3.18.11 到 3.24.3，內建 alpine 帳號，密碼欄是 *，而且 doas 免密碼。映像第一次開機時還沒有 $6$ 雜湊，這時還沒有第二個條件。一旦有人設了主控台密碼，或 cloud-init 加了一個帶雜湊的使用者，alpine 就可以被登入，再用 doas 成為 root。
3. root 本身通常還有一層預設保護：OpenSSH 預設 PermitRootLogin prohibit-password，所以 root:* 不會單靠這次的密碼繞過被登入。若有人把這項改成 yes，root 就進入範圍。
4. 金鑰登入的帳號、以及目錄服務來的帳號：用 adduser 建了人卻沒設密碼、或 usermod -p '*'，都是 *。透過 musl 的 nscd 進來、自己沒有 shadow 的目錄帳號，Alpine 也列在裡面。

以上是漏洞在這些組態下做得到的事。原廠公告沒有說已經發生入侵。

風險評估：到底多危險？

目前仍待確認的三件事

1. 有沒有人已經登入：原廠沒有公布受害清單。判斷方式是查自己的 sshd 日誌，不是等新聞點名。
2. OpenWrt、postmarketOS、Buildroot、Yocto 的預設映像：iThome 與部分報導把它們和 Alpine 列在一起，因為它們常使用 musl。預設 SSH 若是 Dropbear，就不適用。各家有沒有改裝 OpenSSH，公告沒有逐一測試，要看設備上實際跑的是哪一個程式。
3. CVE 編號出現的時間：Alpine 11 月 5 日的公告寫，當時還沒有 CVE 編號。現在的編號是 CVE-2026-123158。查資產時用這個編號，不要只搜尋「sshole」。

修補版本

上游：OpenSSH 10.6p2（2026/11/05）。

Alpine 回補的套件版號如下。3.21 已於 2026/11/01 結束一般支援，Alpine 仍往回發布到 3.16。

含修補套件的發行版切點：3.21.10、3.22.8、3.23.8、3.24.4，以及更新的版本。較早的 point release 做出來的雲端映像，開機之後仍要自己更新。

只拿「是不是 10.6p2」掃描，會把已經裝上 10.3_p1-r2 的 Alpine 3.24 誤判成沒修。要對的是上表這一欄。

自己檢查：我的機器有沒有問題？

在 Alpine 或你懷疑的那台主機上執行。下面是在查組態與日誌，不是在測試登入。

apk info openssh
sshd -T | grep -i passwordauthentication
awk -F: '$2 == "*" { print $1 }' /etc/shadow
awk -F: '$2 ~ /^\$[56]\$/ { print $1 }' /etc/shadow

• apk info 的版號低於上表：套件還沒換上修補。
• passwordauthentication yes，而且第一個 awk 有印出帳號、第二個 awk 也有印出帳號：Alpine 公告裡的條件齊了。
• 第一個 awk 沒有輸出：這台機器沒有密碼欄為 * 的帳號，這條繞過沒有對應的目標。
• 第二個 awk 沒有輸出：沒有 $5$ 或 $6$ 雜湊，Alpine 寫這時條件不成立。

日誌在 Alpine 上看 /var/log/messages。其他系統若把驗證寫到 auth.log，改查那個檔。

grep "Accepted password" /var/log/messages

出現 Accepted password for alpine、Accepted password for root，或其他你知道沒有設密碼的帳號，就當成可能已經被這條漏洞登入，進一步看該帳號的 doas 使用、新建的使用者與 authorized_keys。沒有這行，只表示日誌裡沒留下這種成功登入，不能代替更新。

Debian、Ubuntu、Windows、macOS： 不需要為 SSHole 做這個檢查。前兩者不是 musl；後兩者不是這次的 OpenSSH 伺服器組態。

處置建議

第一階段：正在聽 SSH 的 Alpine（P0）

1. 先留著現在這條連線。若等一下要關密碼登入，先用另一個視窗確認金鑰登入成功，再關掉舊的。
2. 更新並重啟。Alpine 寫，只升級套件不會換掉正在跑的 sshd。

apk upgrade -U -a
rc-service sshd restart
apk info openssh

3. 一時更新不到，先關密碼登入。3.19 以後會讀 sshd_config.d：

mkdir -p /etc/ssh/sshd_config.d
printf 'PasswordAuthentication no\n' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication

最後一行應是 passwordauthentication no。3.18 與更舊的 Alpine 不會讀這個目錄，要改 /etc/ssh/sshd_config 本體。關密碼登入和更新，Alpine 寫兩條路都可以把洞關上；更新仍是完整修補。

4. 日誌裡若已有不該出現的 Accepted password，先把日誌拷走，再把這台機器視為可能已被登入。更新與改設定不能證明對方已經離開。能 doas 或曾是 root 的帳號被登入時，用可信的映像重建，不要只改密碼。

第二階段：映像與其他 musl 設備（P1）

1. tiny-cloud、AMI、VHD 若是 3.24.3 或更早的 point release，每一台正在跑的機器都要更新或關閉密碼登入。新機器改用 3.21.10、3.22.8、3.23.8、3.24.4 或更新的映像。
2. 自建容器若在裡面執行 sshd，重建映像，並確認程序有重啟，不是只換了檔案。
3. 嵌入式設備先確認 SSH 行程是 sshd 還是 dropbear。是 Dropbear 就不是這次的 OpenSSH 漏洞。是 OpenSSH 再查 PAM 與密碼登入。

第三階段：避免掃錯、也避免再打開（P2）

1. 弱點掃描用 Alpine 的套件版號，不要只寫「小於 10.6p2 就有洞」。
2. 雲端使用者資料不要在關密碼登入之後，又把 PasswordAuthentication yes 寫回去。
3. 只用金鑰的帳號，維持 PasswordAuthentication no。* 是給金鑰帳號的寫法，不是一道獨立的鎖。

耘鼎觀點

這次容易被漏掉，是因為名字掛在 OpenSSH 上，實際中彈的卻是「musl、沒有 PAM、密碼登入還開著」這一小塊。用 Debian 或 Ubuntu 的人若把全公司 SSH 都升級一輪，忙的是不受影響的機器；真正該先看的 Alpine 雲端映像、CI 裡的輕量容器、設備上的 OpenSSH，往往不在同一份作業系統清單裡。

另一個落差是版號。上游叫 10.6p2，Alpine 3.24 的修補仍叫 10.3_p1-r2。掃描器只認上游版號，會把已經修補的主機一直報成有洞，也會讓人以為「還沒有 10.6 就算了」。再加上只升級套件、沒有重啟 sshd，畫面上的套件是新的，連線進到的仍是舊行程。

• 先問三件事：是不是 musl、PAM 有沒有開、密碼登入是不是 yes。三個不是同時成立，就不是這次的對象。
• 套件版號對照 Alpine 分支表，不要對照 10.6p2 單一數字。
• 更新之後一定重啟 sshd，並用 sshd -T 看正在生效的設定。
• alpine 這類預設帳號若能提權，優先處理。它比一台普通的金鑰帳號更容易從登入走到 root。

若雲端帳號裡的 Alpine 映像和機房清單對不起來，耘鼎科技 GERTECH 可以協助清查哪些主機在聽 SSH、以及是哪一種伺服器。musl 與密碼登入這兩項，沒有導入服務也可以自己查。

參考資料

• OpenSSH｜10.6p2 發布說明（上游公告，2026/11/05）
• Alpine Linux｜openssh-server password authentication bypass（發行版公告，2026/11/05）
• oss-security｜sshole: password authentication bypass（郵件清單轉述，2026/11/05）
• GitHub Advisory｜GHSA-4fcc-vm97-gx3x／CVE-2026-123158（CVE 紀錄，2026/11/05 發布，CVSS 3.1 為 8.1）
• iThome｜OpenSSH 發布緊急更新，修補 SSHole（媒體報導，2026/11/06）
• Wakefield｜SSHole 說明網站（漏洞通報者的說明頁）

延伸閱讀

• 【資安快訊】2026十一月 Linux 核心 TCP 重大 CVE-2026-98432 漏洞警報！（2026-11-05）
• 駭客利用 CVE-2026-58115 接管 Node-RED 事件解析（2026-11-04）

---

本文依據 OpenSSH 10.6p2 發布說明、Alpine Linux 2026/11/05 公告、CVE 紀錄與 iThome 2026/11/06 報導整理。修補版號以 OpenSSH 與 Alpine 最新公告為準。glibc 發行版不在這次漏洞的影響範圍。

© Gertech 耘鼎科技 資安情資分享

想進一步討論這個主題？

歡迎來電 02-2748-8522，或填寫諮詢表單，由耘鼎顧問與您聯繫。

預約諮詢 →