PHP 漏洞影響我嗎？3 種網站主自查表，LiteLLM 中毒也一起查

💡 核心結論速覽 (TL;DR)

• PHP 漏洞（php2shell）：兩個 9.2 分的洞，不登入就可能被遠端執行程式；修補版是 8.5.12、8.4.27、8.3.36、8.2.35。
• 誰要動手：自管 VPS 今晚升級；租主機的先查版本；用平台的不必碰。
• Python 這條：LiteLLM 1.107.0 在 10/21 晚上掛在 PyPI 1 小時 43 分，裝過就會偷 SSH 金鑰與 AI 工具登入檔。
• 今晚先做：先搜有沒有 cook.pth、別先跑 pip；PHP 8.1 以下直接升到 8.3 以上。

如果你 10 月 21 日晚上剛好在更新 AI 工具，手上又剛好有一個 WordPress 網站，那天你可能同時中了兩槍。

PHP 漏洞影響的是「有在跑 PHP、對外提供網頁」的主機：版本低於 8.2.35、8.3.36、8.4.27、8.5.12 就要更新，Ubuntu、Debian 這類發行版另有自己的版號。

LiteLLM 則只看你在那 1 小時 43 分鐘裡有沒有裝到 1.107.0，裝過就當作金鑰全外洩。

先劃個邊界：用 Wix、Shopify、痞客邦這類平台的人，PHP 這件事輪不到你修；但 LiteLLM 跟你有沒有網站無關，只看電腦裡裝過什麼。

我自己的 3 個網站，1 個走平台型 CMS、2 個跑在 Cloudflare 上，PHP 這次剛好輪不到我修。

真正讓我坐直的是 LiteLLM 那份竊取清單，Claude Code、Codex 的登入檔都在上面。我每天用 AI 超過 10 小時，寫程式時先開 Codex、再交給 Claude Code 細修，這兩個登入檔被拿走，等於整個工作台被搬空。

所以這篇拆成兩半：前半給有網站的人，照你是哪一種網站主對號入座；後半給用 pip 裝過 AI 工具的人，教你不啟動 Python 就先查出有沒有中。你是哪一種？

PHP 漏洞 php2shell 是什麼？不用登入，就能在你的主機上跑程式

PHP 漏洞 php2shell 指的是 CVE-2026-109618 與 CVE-2026-109619 兩個 PHP 核心漏洞，CVSS v4.0 都是 9.2 分，攻擊者不需要帳號密碼，就可能讓你的網站主機執行他寫的程式。

它不是外掛的洞，是 PHP 本身的洞。所以 WordPress 本體和外掛更新得再勤，也補不到它。

PHP 在台灣時間 10/21 晚上 10 點放出修補版，比原訂早了一天，因為 CVE 編號前一天就外流了。

你可以把 PHP 想成網站的爐子：WordPress、Drupal 是食譜和菜單，PHP 負責把火點起來。這次壞的是爐子的開關，食譜換再新，爐子沒換，火還是可能被別人點起來。

兩個洞的原理用白話講：一個是記憶體快用完時，PHP 把處理到一半的請求資料當成正常資料清理；另一個是同一個工作程序接下一個請求時，讀到上一個請求留下、早該釋放的狀態。

發現者之一的 Calif 公開的技術說明寫得更直接：預設設定下就能利用，最早的受影響路徑追到 PHP 5.4.0。

它還確認 WordPress 7.1.2、Drupal 11.4.3、Joomla 6.1.4、Magento 2.4.9 都能在未登入時被打穿。範圍有多大？W3Techs 的統計是，看得出後端語言的網站裡有 69.3% 用 PHP。

攻擊也不是理論。Amazon 的誘捕系統在 10/17 就記到利用嘗試，比公開早 4 天。

watchTowr 和 Cloudflare 從 10/21 起陸續看到攻擊流量，美國 CISA 當天發出警示，要大家先修對外開放的系統。

日本的反應最能說明嚴重程度。資安部落格 piyolog 統計，到 10/23 中午已有 246 個組織停機或緊急維護，名單有厚生勞動省、ANA、樂天、Cygames、pixiv。

日本首相還在 X 上發文，請大家「今晚處理」。在台灣，數位發展部資安署 10/22 發布新聞稿，請機關、學校與企業盤點 PHP 系統、確認版本並儘速修補。

我自己最在意的是另一個細節：這兩個洞是 Calif 跟 OpenAI、Wiz 一起找到的，Calif 說過程用了 LLM 幫忙。

相關的 bug 在 2020 年就有人回報，2024 年的外部稽核也碰過邊，PHP 基金會自己形容這是「結構性的失敗」。

這次的研究團隊在 8/11 就通報 PHP。我算過，從 8/11 通報到 10/21 修補，中間隔了 71 天。

AI 讓找洞變快，修洞的人卻沒有變多，這種「今晚就要處理」的夜晚，我猜以後只會更常見。上次 FortiBleed 外洩的是密碼、等原廠更新救不了；這次剛好相反，更新就是解法。

下一步：先別急著看技術細節，往下對號入座，看你是哪一種網站主。

PHP 漏洞影響我嗎？先看你是哪一種網站主

PHP 漏洞影響你多少，取決於你碰不碰得到伺服器：用平台的人等平台修，租虛擬主機的人要確認主機商修了沒、再把網站切到還有支援的 PHP 版本，自己管 VPS 的人則得親自更新、重開 PHP。

❶ 平台型網站主（Wix、Shopify、Shopline、痞客邦、方格子、Medium）：你碰不到伺服器，就算平台底層用 PHP，修補也是平台的工作。

你能做的是看平台公告，把帳號密碼和兩步驟驗證顧好。

❷ 租虛擬主機或代管主機（cPanel、Plesk 面板、SiteGround、台灣主機商）：PHP 本體由主機商換。

但「網站用哪一版 PHP」常常是你自己在面板選的；選在 8.1 以下，主機商不一定有東西給你。

❸ 自己管主機（VPS、雲端主機、公司機房、NAS 上的網站）：沒有人會替你修。今天就要更新套件、重開所有 PHP 工作程序，CISA 的順序是先修對外開放的那幾台。

以第❷種來說，SiteGround 說它在 PHP 正式釋出修補前就先套了伺服器端緩解，10/21 當天全面更新，客戶不用動作。

這是廠商自己的說法，你的主機商有沒有做到，還是要看公告或直接問。

最常卡住的是這種情況：網站是幾年前請外包架的 WordPress，外包早就不接案了，主機帳號只剩老闆記得密碼，大家都以為「主機商會處理」。

主機商會換 PHP 本體沒錯，但如果網站被設定在 7.4，主機商手上就沒有正式修補可以給你。這種落差，通常要等到出事才被發現。

如果是第❷種，我會先做一件事：進面板看版本，看完再決定要不要往下讀。5 分鐘的事，不要等主機商來信。

還在猶豫要不要從平台搬去自架的人，可以先看我把痞客邦、方格子、WordPress 到自架站攤開比過一輪的取捨，這次的事件剛好是「控制權＝責任」的最好例子。

PHP 版本怎麼查？WordPress、主機面板、VPS 各一招

PHP 版本查詢最快的路是 WordPress 後台「工具 → 網站健康狀態 → 資訊」，展開「伺服器」區塊就看得到；沒有 WordPress 的話，到主機面板找 PHP 版本設定，VPS 則要連套件版本一起看。

❶ WordPress 網站：後台「工具 → 網站健康狀態 → 資訊 → 伺服器」，看 PHP 版本那一行。

網站健康狀態的「狀態」分頁如果跳出 PHP 版本過舊，那是 WordPress 把它當成資安問題在提醒你。

❷ cPanel 或其他主機面板：cPanel 找「MultiPHP Manager」，可以每個網域分開設；有的主機用的是 CloudLinux 的「Select PHP Version」。

Plesk 在網域的 PHP 設定裡，台灣主機商的自家面板搜「PHP 版本」通常就找得到。

❸ VPS 或自己的主機：php -v 看到的是命令列的版本，網站實際跑的可能是另一個 PHP-FPM。

用 dpkg -l | grep php（Ubuntu、Debian）或 rpm -q php 看套件版本更準。

看到 8.3.6 先別嚇到：Ubuntu、Debian 會把修補「搬」進自己的版號，比對時要看發行版的安全公告，不要只看前三碼。

Ubuntu 24.04 修好的版本叫 8.3.6-0ubuntu0.24.04.13，數字上比 PHP 的 8.3.36 小一大截，卻是同一批修補。

Debian 12 修好的是 8.2.35-1~deb12u1，Debian 13 是 8.4.27-1~deb13u1。

我實際用 Ubuntu 的 USN-8948-1 公告對照了 4 個 Ubuntu 版本，22.04 用的明明是 PHP 自己已停止支援的 8.1，照樣拿到 8.1.2-1ubuntu2.28 這個修補版。

這就是「升不上去，先問發行版」的底氣。

下一步：把查到的版本號記下來，下一段用表格對照該升到哪裡。

PHP 漏洞修補版本對照：還在 8.1、7.4 怎麼辦？別只升到 8.2

PHP 漏洞的修補版只出在 8.2 到 8.5 四個分支，8.1 以下沒有正式新版，只剩 PHP 團隊給自行編譯者的最小原始碼修補，以及發行版或付費 LTS 廠商的回補。能升級的話，直接升到 8.3 或 8.4。

我算過，從 10/23 到 8.2 停止支援的 12/31 只剩 69 天。現在升到 8.2，等於年底還要再升一次。

• 能升的：選 8.4（支援到 2028/12/31）或 8.3（到 2027/12/31），外掛很久沒更新的站，先在測試站跑一輪再切。
• 暫時升不了：先問發行版或主機商有沒有回補，Ubuntu 22.04 就有；自己編譯的，PHP 團隊在 GitHub 放了 7.4、8.0、8.1 的原始碼修補。
• 沒人敢動的舊系統：CISA 的建議很直接，修好或升級之前先下線。

我帶團隊時最怕的一句話是「那套系統沒人敢動」。這次就是逼你面對它的時候：下線一晚的成本，通常比被植入後門後慢慢清要低。

如果是我，會直接跳 8.4，多 1 年支援，代價是相容性測試要多做一點。

這跟 Windows 10 停更後買 ESU 延命是同一個邏輯：延命是爭取搬家時間，不是解法。想看兩邊怎麼算，可以對照Win10 要撐到 2027 還是直接升級的算法。

今晚升不了級？PHP 漏洞的 3 個暫時止血法，和被入侵的徵兆

PHP 漏洞在升級前能做的只有降低風險：改 php.ini 關掉被點名的功能、把網站放到 WAF 後面、修不好的系統先下線。

PHP 的安全公告講得很白：這些措施不會讓你的安裝變安全，更新才是唯一完整的解法。

❶ 改 PHP 設定：在應用程式改不到的位置（例如 FPM pool 的 php_admin_value）設定下面幾行，改完重開所有 PHP 工作程序。

memory_limit = -1
post_max_size = 8M        ; 需要上傳檔案就設 32M
session.upload_progress.enabled = 0
fatal_error_backtraces = 0   ; 只有 PHP 8.5 需要

上傳進度那一項用 ini_set() 或 .user.ini 改太晚了，沒有用，一定要在伺服器層級設定。

拿掉記憶體上限聽起來很嚇人，所以要搭配容器或 cgroup 的記憶體限制。PHP 特別提醒不要用 RLIMIT_AS、RLIMIT_DATA 代替，那反而會走進有漏洞的路徑。

帶產品帶久了，我聽到任何功能都先問：誰會用、多久用一次。session 的「上傳進度」就是典型，預設開著，但網站沒有大檔上傳進度條的話，關掉它幾乎沒有代價，是這幾刀裡最不心痛的一刀。

❷ 把網站放到 WAF 後面：Cloudflare 的防護規則在台灣時間 10/21 上午 11:02 上線，免費方案自動套用，付費方案要自己確認是封鎖模式。

限制是只擋經過 Cloudflare 的流量，有人直接打你主機的 IP 就繞過了。還沒接過 Cloudflare 的話，我在部落格接 Cloudflare 的加速與防禦清單裡寫過一輪設定，免費方案就夠用。

❸ 修不好的先下線：無法立即更新、或還在跑 8.1 以下的系統，CISA 建議修好前先移出服務。日本那 246 個組織走的就是這條路。

更新之後，還要回頭看有沒有已經被入侵。資安署與 JPCERT/CC 都提醒修補後要檢查日誌、帳號與憑證；Amazon 講得更具體，建議入侵調查至少從 10/17 看起，修補前那幾天的日誌也要翻。

我會先看這 4 個地方：

• WordPress 使用者清單裡，有沒有你沒建過的管理員
• 上傳資料夾（例如 wp-content/uploads）裡有沒有多出 .php 檔
• 首頁或文章被插了奇怪連結、主機商來信說你在寄垃圾信或 CPU 爆量
• 工程師可以查：PHP 工作程序有沒有啟動 sh、bash、curl 這類程式，這是 CISA 點名的訊號

任何一項有中，就不是升級 PHP 能收尾的事：先從乾淨備份還原，再把主機、資料庫、後台與設定檔裡的金鑰全換掉。

手邊沒有工程師的話，可以找網站資安服務代清。Sucuri 的網站資安方案年費 US$229 起，每個方案都含不限次數的手動清除惡意程式。

我把 US$229 用台銀 10/23 的美元即期賣出價 32.555 換算，約 NT$7,455，攤下來每月約 NT$621，跟我每個月付的 Google AI Pro NT$650 差不多。

對沒有工程師的小網店來說，這筆錢買的是「出事有人接」；如果你有固定合作的工程師，就不一定需要。

👉 查看 Sucuri 網站資安方案與清除服務

給主機商或外包的訊息範本：照抄就能問清楚 PHP 漏洞修了沒

不會自己查 PHP 版本的網站主，最省事的做法是把下面這段直接傳給主機商客服或當初架站的外包，對方只要照實回答 4 個問題，你就知道網站還有沒有風險。

您好，想確認我們網站（網址：＿＿＿＿）對 PHP 漏洞 CVE-2026-109618、CVE-2026-109619（php2shell）的處理狀況：

❶ 網站目前實際使用的 PHP 版本是多少？

❷ 是否已更新到 8.2.35、8.3.36、8.4.27、8.5.12 以上，或已套用發行版的修補？請附套件版本或公告編號。

❸ 如果仍在 8.1 以下，預計何時升級？升級前有沒有暫時措施或 WAF？

❹ 更新後有沒有檢查陌生帳號、可疑檔案與存取紀錄？

問問題要問到對方只能回答數字，這是我帶產品養成的習慣。「我們都有在注意喔」不算答案，「8.3.36，10/22 晚上更新」才算。

收到回覆後，對照上一段的表格：版本在修補版以上，或發行版版號跟公告一致，就放心一半；另一半是上面那 4 個入侵徵兆。

身邊有朋友在經營網店或接案架站的，這段範本可以直接轉給他。

Python 的 LiteLLM 中毒是怎麼回事？裝了不用 import 也會偷

LiteLLM 是一套把 100 多家模型 API 包成同一種寫法的開源 AI 閘道，10/21 被人推上帶竊密程式的 1.107.0，只要裝過，之後每次啟動 Python 都會執行，不需要程式真的 import 它。

很多 AI 工具、Agent 框架和公司內部的模型閘道都用它，LiteLLM 在 GitHub 有 6.19 萬顆星。

它的角色像總機：OpenAI、Anthropic、Google 的金鑰全掛在它身上，它一出事，偷的就是整串鑰匙。

我把 LiteLLM 事故報告裡的 UTC 時間換算成台灣時間：PyPI 上的 1.107.0 從 10/21 晚上 19:39 掛到 21:23，前後 1 小時 43 分鐘。

Docker 映像那邊更久：Docker Hub 的 latest、main-latest、main-stable、v1.107.0 標籤是 19:46 到 22:20，GHCR 則到 21:51。

時間看起來很短，但 Socket 估計 LiteLLM 每週約 2,300 萬次下載，我除以一週 168 小時換算，平均每小時約 13.7 萬次。實際有多少人裝到，LiteLLM 沒有公布。

手法很陰險：套件把 cook.pth、cook.py、sitecustomize.py 三個檔放進 site-packages，Python 每次啟動都會自動載入。

偷完的資料會加密送到仿冒網域 litellm.dev；Linux 和 macOS 上還會留一個每小時回頭拉新程式的常駐程序。

它偷的東西，StepSecurity 的拆解列得很完整：

• SSH、GPG 金鑰，AWS、Azure、Google Cloud 憑證，Kubernetes、Docker 設定
• GitHub、npm、PyPI 權杖，家目錄往下兩層內的 .env 檔
• Chrome、Edge、Firefox 等瀏覽器存的密碼與 cookie
• Claude Code、Codex、Cursor、Gemini CLI 等 AI 工具的登入檔
• LiteLLM proxy 資料庫裡的各家模型 API 金鑰

我每天用的主力是 1 台 Windows 11 桌機，所以特別看了 Windows 的部分。

那個每小時拉程式的常駐程序在 Windows 上跑不起來，但竊取那段照跑，而且很可能每開一次 Python 就再偷一次。

我每個月的 AI 訂閱費光 ChatGPT Pro 加 Claude Max 就是 US$400，用 32.555 換算約 NT$13,022。

被偷走的不是一組密碼，是兩個每月一萬多台幣的帳號，外加所有按量計費的 API 金鑰。

這不是嚇人。Wiz 觀察到攻擊者在資料外洩後約 4.5 小時，就拿偷來的 AWS 憑證測試能不能呼叫 Amazon Bedrock 上的模型，也就是俗稱的 LLMjacking。

按量計費的金鑰被拿去跑模型，帳單是你付；最壞情境有多貴，我在OpenClaw 資安風險那篇算過一天能燒掉多少。

入侵路徑也值得記一筆。LiteLLM 說，攻擊者從一台對外可連的內部部署的日誌裡，撈到 3 位開發者的 GitHub CLI 權杖，拿去改發布流程、指向仿冒的 Berri-AI/litellm 儲存庫。

報告還提到 Claude Code 在特定情況會把 GitHub CLI 權杖放進回應內容，這是 LiteLLM 的說法；但提醒很實際：日誌也是機密。

這也是 LiteLLM 今年第 2 次出事，3 月的 1.82.7、1.82.8 也是惡意版本。

下一步：下一段是不啟動 Python 的自查順序，照著做 10 分鐘內就能判斷。

我有沒有中 LiteLLM？先別跑 pip，5 步自查與要換的金鑰

LiteLLM 自查的第一原則是先不要啟動 Python，連 pip show 都先別跑，因為中毒的環境每開一次 Python 就再執行一次。

先用檔案搜尋找 cook.pth 和 litellm-1.107.0.dist-info，找到就照「已外洩」處理。

❶ 先對時間：台灣時間 10/21 19:39–21:23 之間，你、你的 CI 或伺服器，有沒有跑過 pip install、pip install -U、uv sync 這類會抓最新版的指令？

19:46–22:20 之間有沒有拉過 LiteLLM 的 latest 映像？兩個都沒有，風險就很低。

❷ 用檔案搜尋找可疑檔：Windows 開 PowerShell，先搜使用者資料夾，沒有再搜整個 C 槽：

Get-ChildItem -Path $env:USERPROFILE -Recurse -Filter cook.pth -ErrorAction SilentlyContinue

macOS、Linux 用 find，順便找 1.107.0 的安裝紀錄：

find / -name cook.pth -path "*site-packages*" 2>/dev/null
find / -type d -name "litellm-1.107.0.dist-info" 2>/dev/null

用 Docker 的人跑 docker images --digests | grep litellm，對照 digest 開頭：

主映像是 sha256:1bbcb1443bc9，litellm-database 是 c00f9d92c427，non_root 是 7b00e91cd2fe，對上就是被汙染的那一版。

❸ 先停常駐程序再刪檔：Linux、macOS 用 lsof /tmp/remote_code_loader.lock 找出握著鎖的程序，先結束它。

接著刪掉每個 site-packages 裡的 cook.pth、cook.py、sitecustomize.py，以及 __pycache__ 裡對應的 .pyc。

❹ 重建環境、鎖版本：虛擬環境或映像直接砍掉重建，比原地清乾淨可靠；LiteLLM 釘在 1.106.2 或更早的明確版本。

❺ 把那台電腦碰得到的祕密全部換掉：各家模型 API 金鑰、雲端金鑰、SSH 與 GPG 金鑰、GitHub／npm／PyPI 權杖、瀏覽器存的密碼都要換。

Claude Code、Codex、Cursor 這類 AI 工具登出再重新登入，帳號後台有「登出所有裝置」就一起按；跑 LiteLLM proxy 的，連 master key、virtual key 和資料庫密碼一起換。

找不到檔案也不代表沒事，只要那段時間裝過就照換。瀏覽器密碼被整包拿走的情況，可以照個資外洩的 5 步自救流程一個帳號一個帳號收回來。

換完記得補上兩步驟驗證，5 分鐘就能把重要帳號鎖好。

沒有直接裝 LiteLLM，也可能被別的套件帶進來。我實際用 PyPI 的 API 跑了 9 個常見 AI 套件在 10/23 最新版的依賴寫法，有 5 個沒有把 litellm 擋在 1.107.0 之前：

這是 10/23 的最新版寫法，你裝的舊版可能不同。Aider、OpenHands 雖然鎖死版本，但你如果另外手動升級過 litellm，一樣要查。

最準的還是第❷步：直接找電腦裡的檔案。

順手更新 certifi：同一週憑證機構 eMudhra 的金鑰出包，Python 常用的根憑證套件 certifi 在 2026.10.19 版移除了 emSign ECC Root CA – G3。

確認環境乾淨之後，再把 certifi 更新到 2026.10.19 以上。

下次別再被打到：鎖版本、金鑰不落地、主機交給誰顧

PHP 漏洞和 LiteLLM 中毒教的是同一件事：別讓「最新版」和「明文金鑰」自動進到你的電腦，也別讓網站處在沒人負責更新的狀態。我會把它拆成 3 個設定。

❶ 套件晚一週再裝：用 uv 的話，在 pyproject.toml 加一行，上架不到一週的版本就不會被裝進來。

[tool.uv]
exclude-newer = "1 week"

這次存活不到 2 小時的 1.107.0，根本進不了你的環境。用 pip 的就把版本寫死，再加 --require-hashes 驗證雜湊。

我自己寫程式是先用 Codex、再交給 Claude Code 細修，2 個工具都會依指示幫我裝套件，「誰在什麼時候裝了什麼」比以前更難追。

供應鏈攻擊的其他真實案例，我在Gemini CLI 那篇的供應鏈攻擊避雷清單整理過 3 起。

❷ 金鑰別再放明文：這次竊取清單第一個就是整個 ~/.ssh 資料夾。1Password 的 SSH Agent 讓私鑰不離開 1Password App。

API 金鑰則可以用 1Password CLI 的 op:// 參照取代 .env 裡的明文，執行時再用 op run 帶進去。

它不是萬靈丹：1Password 的文件也寫，同一個使用者底下的程序可能讀得到彼此的環境變數，已經中毒的電腦照樣危險。

它解決的是「平常就躺在硬碟裡的明文」，再替 API 金鑰設用量上限，被偷時損失才有天花板。

這點我自己踩過。用 AI Agent 架副站那陣子，為了少被問幾次「要不要允許」，我幾乎全部按允許，後來想追哪一支金鑰被哪個工具碰過，根本對不起來。

換金鑰最痛的從來不是「換」，是你不知道自己有幾支、各放在哪。先把清單建起來，下次出事才換得完。

還沒用過密碼管理器的人，可以先看1Password、Bitwarden、LastPass 該怎麼選；要幫整個團隊換金鑰的，團隊版的成本我幫你算過。

👉 查看 1Password 方案與 SSH Agent 功能

❸ 想清楚網站該交給誰顧：PHP 漏洞這種事，真正的風險不是洞本身，是「沒人負責更新」。我會這樣分：

• 只寫文章、做形象站：平台或靜態網站就夠。我 2 個網站跑在 Cloudflare 上，純靜態的第二年帳單可以是 0，也沒有 PHP 要修。
• 需要 WordPress 外掛或開網店：選會替你更新伺服器的代管主機，但 PHP 版本仍要每年自己看一次；換主機前先看清楚虛擬主機第二年的續約價會漲幾倍。
• 有工程師、要客製：VPS 最自由，前提是有人訂閱資安通報、每週更新，不然它就是下一台卡在 7.4 的主機。

猶豫 WordPress 還是其他架站工具的，我把Webflow 和 WordPress 的安全性、價格拆開比過。

平常就靠 AI 工具寫程式的，Codex、Claude Code 的安全與成本 5 大坑也值得一起看。

FAQ 常見問題

PHP 漏洞要不要先把網站關掉？

看版本和能不能馬上更新。已在 8.2.35、8.3.36、8.4.27、8.5.12 以上，或發行版已套修補，就不用關；還在 8.1 以下或今晚無法更新，CISA 建議修好前先下線。Cloudflare 能多擋一層，但不能取代更新。

只更新 WordPress 和外掛，能擋住 PHP 漏洞嗎？

擋不住。php2shell 是 PHP 本身的洞，WordPress、主題和外掛再新都補不到，必須更新伺服器上的 PHP。WordPress 能幫的是告訴你版本：「工具 → 網站健康狀態 → 資訊 → 伺服器」看得到。

PHP 要升到 8.3 還是 8.4？

我會選 8.4，它的安全支援到 2028 年底，比 8.3 多 1 年；代價是相容性風險高一點，外掛很久沒更新的站先在測試站跑一輪。不要選 8.2，它 2026 年 12 月 31 日就停止支援。

LiteLLM 換回 1.106.2 就安全了嗎？

套件本身安全了，但那段時間裝過 1.107.0 的話，金鑰可能早被送出去，換回舊版收不回來。順序是停常駐程序、刪檔、重建環境，再把金鑰全換掉。只接 1、2 家模型的人，直接用各家 SDK 能少一層風險。

沒裝 LiteLLM，只用 Claude Code、Codex、Cursor，也要換金鑰嗎？

電腦裡找不到 cook.pth、也沒有 1.107.0 的安裝紀錄，就不用為這件事換。要注意「沒有直接裝」不等於沒有，DSPy、CrewAI 這類框架可能把它帶進來，照上面的方法搜一次最保險。

結論：PHP 漏洞看版本，LiteLLM 看時間，兩件都在考「有沒有人管」

PHP 漏洞這次的解法很單純：查版本、升級、檢查有沒有被入侵。LiteLLM 則是先對時間、不開 Python 找檔案、換掉所有金鑰。

兩件事真正暴露的，是很多網站和電腦都處在「以為有人在管」的狀態。

我常說「AI 沒有讓人更清閒，反而讓我更忙了」。這次是另一個版本：AI 讓找漏洞變快，也讓需要連夜修補的晚上變多。

與其每次被新聞追著跑，不如今天就把版本鎖好、金鑰收好，把網站交給一個真的會更新的人。

想在下一次「今晚就要處理」的事件裡少花時間找資料，可以訂閱我的部落格，有這類需要立刻動手的整理時，你會不定期收到信。

我是夜羽凌，做過工程師與數據分析，現在在遊戲業工作，平常用 AI 架網站、寫程式；想知道我怎麼用這些工具，可以看關於我。

參考資料

• PHP：Security advisory: Critical remote code execution vulnerabilities, update now
• PHP：Supported Versions
• CISA：Critical Vulnerabilities in PHP Require Immediate Patching
• 數位發展部資通安全署：PHP 釋出緊急安全更新，資安署呼籲儘速完成修補
• TWCERT/CC：軟硬體漏洞警訊
• Ubuntu：USN-8948-1 PHP vulnerabilities
• Debian Security Tracker：CVE-2026-109618
• Calif：php2shell 技術說明
• Tenable：php2shell 常見問題
• piyolog：PHP 兩個嚴重漏洞整理（日文）
• LiteLLM：Security Incident Oct 21, 2026
• StepSecurity：litellm 1.107.0 Compromised on PyPI
• Help Net Security：LiteLLM hit by second supply chain attack this year
• WordPress.org：Site Health screen
• 1Password Developer：SSH Agent