在當前的雲端運算與遠端伺服器管理生態中，SSH 協定是維繫企業基礎設施安全傳輸的核心。然而，近期在廣泛應用的開源 SSH 函式庫 libssh2 中，爆發了一項高危害等級的安全漏洞，CVSS v4 高達9.2 ，迅速引發全球資安社群的高度關注。這項追蹤編號為 CVE-2026-55200 的漏洞，允許未經身分驗證的遠端攻擊者透過建構惡意封包，在無需任何使用者互動的情況下，直接在受影響的系統上執行任意程式碼。不但如此，還有幾天前的編號 CVE-2026-55199 的漏洞，預先身分驗證階段的阻斷服務問題。
隨著美國國家漏洞資料庫正式揭露相關資訊，我們得強化全球供應鏈安全相關的措施，務必對現有生產環境與測試環境做盤點，看套件用到的相關套件與系統是否有釋出更新。
libssh2 受影響版本：所有 1.11.1 及更早的 libssh2 版本。
CyberQ 觀察，根據 NVD 官方說明頁面 的技術資料指出，該漏洞的根源在於 libssh2 函式庫內部的 ssh2_transport_read() 函式。在處理傳入的網路封包時，系統未能對封包長度欄位執行嚴格的上限邊界檢查。遠端攻擊者可以刻意發送帶有異常巨大長度數值的 SSH 封包，迫使系統在記憶體中進行超越邊界的寫入動作。這種堆疊或堆積記憶體損毀的弱點，最終會讓攻擊者成功劫持系統控制流，進而達成遠端程式碼執行。在通用漏洞評分系統最新標準下，該漏洞被賦予了高達 9.2 的 CVSS v4 臨界嚴重性評分，不能輕忽喔。
為了準確評估實質的威脅程度，CyberQ 進一步檢查了當前的災情與實際攻擊現況。根據美國網路安全暨基礎設施安全局所參考的資安協調指標，目前該漏洞在外面的實際利用狀態尚標示為「無」，且尚未被列入已知遭利用漏洞清單。
但是呢，雖然理論上的概念驗證或攻擊技術可行，目前也還沒有大規模的駭客組織將其轉化為現役的攻擊武器，不過我們還是得注意防範，且各大廠已經陸續展開修補工作，因為太多套件會用到 libssh2 了。
CyberQ 指出，由於 libssh2 被大量整合於知名網路工具如 curl，以及眾多企業級的遠端管理軟體中，包含 Debian、Ubuntu 和 SUSE 在內的主流 Linux 發行版都已緊急啟動應變機制。許多知名網路工具、開發套件及資安排查工具（例如 curl 的 SCP/SFTP 擴充支援、libgit2、Nmap 等）皆高度依賴 libssh2 作為底層通訊元件，此漏洞將對全球供應鏈及 IoT/嵌入式設備的下游生態系引發衝擊。
與此同時被揭露的還有追蹤編號 CVE-2026-55199 的漏洞（CVSS 8.2），它屬於預先身分驗證階段的阻斷服務問題，惡意伺服器能透過異常的擴充套件計數，讓用戶端陷入超過一分鐘的 CPU 耗盡迴圈，造成服務組段。這兩個同時被修正的瑕疵，對於各家公司的管理者來說就得忙一陣子。
CyberQ 觀察，由於現代軟體開發高度仰賴第三方開源元件，一旦底層基礎函式庫出現裂縫，其造成的破壞將如同骨牌效應般蔓延至上層的商業軟體。我們除了聚焦於第一線作業系統或大型應用程式的更新檔修補外，類似像 libssh2 這類隱藏在底層、默默執行的相依元件更需要注意，國際合規標準對於軟體物料清單 (S-BOM) 的要求逐年趨嚴，目的正是為了解決這類深埋在供應鏈之中的結構性問題。當發生此類高風險威脅時，唯有具備完整相依性資產盤點能力的企業，才能在第一時間判定自身是否受到波及。
針對這起潛在風暴，libssh2 的開源社群與維護團隊已經推出了對應的程式碼修正。開發者與系統管理團隊應立即檢視內部所有產品與伺服器環境，確認是否使用了 1.11.1 或更早版本的 libssh2，並透過原廠管道或更新相依性套件來應用修補程式。
影響範圍與實務建議
CyberQ 建議，可以在 Linux 系統或專案套件庫中清查哪些軟體使用了 libssh2（例如在 Fedora/RedHat 下執行 dnf repoquery --whatrequires libssh2，或在 Debian/Ubuntu 確認 apt list --installed | grep libssh2）
各大 Linux 散佈版（如 Ubuntu、Debian、Red Hat、SUSE）正緊急將上述 commit 回移植（Backport）至其官方套件庫中。請密切留意並在第一時間執行 apt-get update && apt-get upgrade 或 yum update 進行核心安全庫修補。
Ubuntu尚未修補，官方顯示 Needs evaluation，所有版本（24.04 / 22.04 / 20.04 等）都還在評估階段，沒有 USN。至於 Rocky Linux 尚未修補目前沒有對應的 RLSA（Rocky Linux Security Advisory）。Rocky 與 RHEL 相容，Red Hat 也尚未釋出 libssh2 的更新
如果是開發者且需要套用原始碼更新（Backport Patch），可以將官方儲存庫中的修補 Commit 合併到自己系統現有的組建中：
- CVE-2026-55200（RCE patch）： GitHub Commit: 7acf3df (或 PR #2052)。
- CVE-2026-55199（DoS patch）： GitHub Commit: 1762685
CyberQ 認為，雖然 CVE-2026-55200 被評為 Critical RCE，但目前公開資訊顯示其主要攻擊面為使用 libssh2 的 Client 端程式，攻擊者通常需要控制或偽裝成 SSH/SFTP Server 才能觸發漏洞，因此實際風險應依組織是否存在大量 SSH Client、SFTP 同步或自動化部署工作流程而定，而非所有啟用 SSH 的系統皆直接暴露於風險之中。
我們在實作上，可以優先過濾外連的 SSH/SFTP 連線目標，限制內部自動化腳本只能存取通過嚴格信任審查的外部伺服器，從源頭切斷惡意伺服器發動反向程式碼執行的路徑。針對開發團隊的工作站，應提醒工程師暫時避免連線至不明的第三方代管平台或測試環境。在全面盤點資料的過程中，若發現關鍵系統具備極高的風險，亦可考慮下載 libssh2 官方已釋出的最新安全修補原始碼，採取手動編譯與最佳化的方式提前完成修補。
如果手邊有自動化的資產掃描工具，也可定期對執行環境中的二進位檔案進行合規性檢查，確保任何含有已知缺陷的基礎元件都能在被駭客利用前遭到淘汰。
我們也會持續追蹤相關消息，再提供給大家資訊。
