共享主機最怕的劇本——「一個小權限的使用者翻牆變成整台機器的 root」——這次成真了。CISA 將 CVE-2026-54420 列入已知遭利用漏洞（KEV）清單，並要求美國聯邦機構在三天內完成修補。這個漏洞位於 LiteSpeed 的 cPanel 外掛（user-end plugin）2.4.8 之前的版本，CVSS 評分 8.5（High），且已被確認自 2026 年 5 月起在野外實戰利用。對台灣大量使用 cPanel + CloudLinux 共享主機的中小企業網站來說，這不是「下次維護視窗再處理」的等級。
講技術原理。問題出在外掛對「使用者提供的 symlink（符號連結）」處理不當：一個只擁有 FTP 帳號或已被植入 web shell 的低權限使用者，可以在共享主機上佈置惡意 symlink，再串接 cPanel 外掛內部的 API 呼叫，以非預期的方式繞過 CloudLinux CageFS 的隔離邊界，把權限一路拉到 root。攻擊鏈是典型的「本地權限提升（LPE）」：先有立足點 → 濫用 symlink + 內部 API → 跳出 CageFS 沙箱 → 拿下整台主機上的所有網站。對共享主機而言，一個帳號淪陷等於同機所有客戶一起淪陷。
受影響範圍與時間軸要看清楚。受影響的是 2.4.8 之前的 user-end plugin；雖然漏洞不在 WHM 外掛本身，但 user-end plugin 與 WHM 外掛綁在一起出貨，許多環境若沒主動更新仍暴露。時間軸：5 月起已遭實戰利用 → 6 月 1 日釋出修補版 → 6 月 14 日正式指派 CVE → 隨即被 CISA 列入 KEV。從「被打」到「官方編號」之間有一段空窗，意味著可能已有主機在你不知情時被植了後門。
為什麼值得今天就動手：這是「已遭利用 + 共享主機橫向擴散 + 修補已就緒」三條件同時成立的高危組合。下文給出補丁 vs 緩解措施對照、可立即比對的 IOC、以及給 PHP/Laravel/Nginx 環境管理者的具體檢查指令。
技術細節：symlink 濫用 + CageFS 逃逸
漏洞類型是 symlink following / 權限邊界繞過導致的本地權限提升。在 CloudLinux 上，CageFS 本應把每個使用者關在自己的虛擬檔案系統裡；但 LiteSpeed cPanel 外掛在處理某些檔案操作時會跟隨使用者可控的 symlink，加上可被串接的內部 API，攻擊者得以讓特權程序去存取／寫入它本不該碰的路徑，進而取得 root。需要的前置條件只有「一個可寫入的低權限立足點」（FTP 或 web shell），不需要既有的 root 或管理權限——這正是它危險的地方。修補方式直接：升級到 2.4.8 或更新版。
# 檢查 LiteSpeed cPanel 外掛版本（WHM/SSH，需 root）
cat /usr/local/lsws/admin/cpanel/version 2>/dev/null
rpm -q lsws-cpanel 2>/dev/null || ls -l /usr/local/lsws/admin/cpanel/
# 若 < 2.4.8，依官方指引更新後重啟
/usr/local/lsws/admin/misc/cpanel_plugin_update.sh # 視安裝方式而定
systemctl restart lsws
# 稽核可疑 symlink 與近期被改檔（找立足點痕跡）
find /home -maxdepth 3 -type l -newermt "2026-05-01" -ls 2>/dev/null
find /tmp /dev/shm -type f -newermt "2026-05-01" ( -name "*.php" -o -name "*.sh" ) -ls 2>/dev/null三類讀者的立刻行動
- 系統管理員：立刻清點所有跑 LiteSpeed cPanel 外掛的主機，把 user-end plugin 升到 2.4.8+；無法立即升級者，暫時停用該外掛、收緊 FTP 帳號、檢查 web shell。
- 開發者：盤點你維護的網站是否有可被上傳/寫入的目錄與舊版外掛漏洞（成為 web shell 立足點的常見入口）；Laravel 專案確認
storage/與上傳目錄沒有可執行 PHP，Nginx 設定加上location ~* .(php)$的上傳目錄封鎖。 - 接案商／顧問：今天就寄一封客戶通告（範本見下），說明風險、你已採取的動作、以及需要客戶配合的事項——這是把「資安事件」轉成「信任時刻」的機會。
補丁 vs 緩解措施對照
| 情境 | 立即補丁 | 無法立即補丁時的緩解 |
|---|---|---|
| 主機可控、能升級 | 升級 user-end plugin 至 2.4.8+ 並重啟 lsws | — |
| 共享主機、需等主機商 | 催主機商排程升級並索取完成證明 | 停用 LiteSpeed cPanel 外掛、停發新 FTP 帳號 |
| 疑似已遭利用 | 升級後仍須假設已淪陷 | 輪換所有憑證、掃描 web shell、比對 IOC、必要時重建主機 |
| 降低立足點風險 | 修補上傳/舊外掛漏洞 | 上傳目錄禁止執行 PHP、強制 SFTP、開啟檔案完整性監控 |
IOC 與威脅情資
- 可疑立足點：
/home/*/public_html或/tmp、/dev/shm內 2026-05 之後新增的.php／.sh檔（常見 web shell 落點）。 - 異常 symlink：使用者家目錄下指向系統路徑（如
/etc、/usr/local/lsws）的符號連結。 - 權限異常：非 root 程序突然以 root 身分產生檔案；
/var/log/secure或 cPanel 日誌出現異常的外掛 API 呼叫。 - 外連：主機對未知 IP 的不明 outbound（C2 回連），建議比對最近 30 天的防火牆日誌。
不會告訴你的事
- 「升級就沒事」是錯覺。若 5 月起已被植後門，光升級外掛不會移除既有的 web shell 與被竊憑證——已暴露的主機要假設已淪陷，做完整 IR（事件應變）而非只打補丁。
- 共享主機的連坐風險被低估。你自己的網站再乾淨，只要同機另一個帳號被當立足點，整台機器（含你）都可能一起 root 淪陷。這也是「便宜共享主機」對企業客戶的隱性成本。
這代表的更大趨勢
從 5 月實戰利用到 6 月才有 CVE 編號，再次印證「揭露→編號→修補」的時間差正在被攻擊者吃掉。主機層級的權限提升漏洞（cPanel、LiteSpeed、CloudLinux 這類共享主機元件）正成為勒索與供應鏈攻擊的高價值目標，因為一次得手就能橫掃整機數十個客戶。對維運方而言，「定期 patch」已不足，需要的是「24 小時 KEV 應變窗口」。
常見問題 FAQ
我用的是虛擬主機，怎麼知道有沒有受影響？
直接問主機商兩個問題：是否使用 LiteSpeed + cPanel？user-end plugin 是否已升到 2.4.8 以上？要求對方提供升級完成的時間與證明，而不是口頭「應該沒問題」。
我的網站是 Laravel／一般 PHP，跟這個漏洞有關嗎？
漏洞本身在主機外掛，不在你的程式碼；但你的網站若有可被上傳 web shell 的弱點，就可能成為攻擊者的「立足點」。把上傳目錄設為不可執行 PHP、修補舊外掛，是你能做的防線。
升級到 2.4.8 之後就安全了嗎？
修補阻止了「未來」被這個漏洞利用，但若 5 月起已被入侵，必須額外做事件應變：輪換密碼與金鑰、掃 web shell、比對 IOC，必要時重建。
CVSS 8.5 沒到 9 分，需要這麼緊張嗎？
需要。分數不是唯一指標——它已被 CISA 列入 KEV（確認實戰利用），且在共享主機上可橫向擴散，實務危險度高於分數本身。
我的觀點
主流建議是「趕快 patch」。我的逆向判斷是：對共享主機的客戶，光 patch 是最危險的安心。因為這個漏洞自 5 月就被利用、6 月才有編號，許多主機在「無編號空窗期」可能已被植後門；只升級外掛而不做 IR，等於把後門留在原地、卻自以為修好了。真正該做的是「假設已淪陷」的事件應變。對 ScriptWalker 的客戶看護機會很實在：今天就主動寄出客戶通告——說明風險、列出你已執行的檢查、附上「主機商該回答的兩個問題」——把被動的資安事件變成主動的信任時刻，這也是把一次性接案客戶轉成月費維運客戶最自然的切入點。