一個漏洞,看出公司有沒有人在看技術

如果公司網站或後台使用 WordPress/PHP,今天先問架站或代管廠商:「我們實際運行的 PHP,有沒有套用 10 月 21 日的修補?誰負責、什麼時候完成?」先取得版本、修補證據與負責人的回覆,再決定下一步。

2026 年 10 月 20 日,PHP 團隊預告重大安全更新,並在 10 月 21 日發布修補。這次被稱為 PHP2Shell 的兩個漏洞,讓平常只在意「網站還能不能開」的公司,多了一個需要回答的問題:當底層軟體出現風險,誰會先發現、確認影響,並把事情做完?

PHP2Shell 跟公司的網站有什麼關係?

依 PHP 官方安全公告,CVE-2026-109618 與 CVE-2026-109619 可能讓未登入的攻擊者遠端執行程式。風險涉及處理網頁請求的 PHP 安裝;WordPress 等建立在 PHP 上的網站,應由維護廠商確認底層環境。

「網站目前開得起來」無法回答是否受影響;更新 WordPress 本身,也不能代替確認主機上的 PHP 修補狀態。不同部署方式、實際套件與供應商回補,仍要逐項核對。這則提醒不代表每個網站都已被入侵。

公司有沒有人在看技術,差在後面這幾步

有負責人的做法,是收到公告後先盤點哪些系統用到 PHP、找到代管或維護窗口、確認修補狀態,再留下處理紀錄。如果平常沒有人負責,消息可能停在群組裡,直到有人問起,才開始找帳號和廠商。

我們有 24 小時 AI agent 監看自己的系統。這次公告當天,我們就完成雲端、網站與程式碼的盤點,確認自己的系統沒有受影響。這是我們此次內部盤點的結果;其他公司的環境仍需要各自確認。

值得建立的是一條有人接手的處理流程:收到提醒 → 查明影響範圍 → 指定處理人 → 驗證完成 → 留下紀錄。AI agent 可以協助追蹤提醒與整理盤點,升級、測試與完成確認,也都要有明確負責人。

三分鐘自查清單:今天先做這六件事

  1. 確認有沒有用 PHP。公司網站或後台是不是 WordPress,或用 PHP 做的?不知道就問原架站、外包或代管廠商。
  2. 確認修補版本與證據。請廠商回覆實際服務網站的 PHP 版本與套件修補狀態;四個系列在 10 月 21 日發布的修補版分別列在下方。若使用供應商回補,請附該套件的安全公告或修補紀錄。
  3. 把修補交給既有維護窗口。不要因為陌生訊息就點「立即修補」的連結或附件,先透過原本的聯絡方式確認。
  4. 寫下負責人與完成時間。代管、外包或公司內部,誰負責確認?誰執行更新與測試?預計什麼時候回覆?
  5. 重啟服務並確認正式環境已換上新版本。只安裝新套件還不夠:請廠商重啟實際處理網頁請求的 PHP 程序(例如 PHP-FPM,或使用 mod_php 的 Apache),再從正式網站實際運行的環境確認 PHP 版本或套件已是修補版,而不是只看主機上的命令列版本。
  6. 留一份完成紀錄。請廠商回覆更新後的版本或套件、完成時間、重啟了哪些服務、重啟後在正式環境確認到的版本,以及基本功能測試結果;若判定不受影響,也要保留判定依據。

要更新到哪一版?請按原本使用的系列確認

PHP 官方在 2026 年 10 月 21 日分別發布:

  • PHP 8.2 系列:8.2.35
  • PHP 8.3 系列:8.3.36
  • PHP 8.4 系列:8.4.27
  • PHP 8.5 系列:8.5.12

不能只問「是不是 8.2.35 以上」:例如 8.3.30 的數字看起來較大,卻仍早於 8.3 系列這次的修補版。請確認自己的系列,或由供應商證明已回補修正。

PHP 8.1 與更舊版本已結束一般上游支援;部分發行版與長期支援供應商提供回補。PHP 安全團隊這次也特別提供 7.4、8.0、8.1 的最小原始碼回補,不能一概寫成舊版完全無修補。請維護廠商核對供應商證據,並安排受支援版本的升級。以上版本與回補資訊依 PHP 官方公告。

可以直接轉給廠商的一句話

請幫我們確認正式網站實際運行的 PHP 系列與版本,是否已套用 2026/10/21 PHP2Shell 修補或供應商回補?請回覆負責人、預計完成時間,完成後請重啟實際提供網站服務的 PHP 程序(例如 PHP-FPM 或 Apache),並附上重啟後在正式環境確認到的版本/套件證據,以及基本功能測試結果。

完成紀錄至少要能回答:哪個系統、誰處理、何時完成、依據是什麼、測試是否通過。不必把密碼、金鑰或客戶資料放進群組,請沿用既有維護管道交接。

公告與攻擊狀態,要分開看

截至 ,我們讀取的 CISA 已知遭利用漏洞清單(KEV)版本為 2026.10.21,尚未列入上述兩個 CVE。另一方面,資安公司 watchTowr 在 我們讀取的頁面上表示,已觀察到針對這兩個 CVE 的主動利用嘗試;這是該公司的觀察,不是 CISA 的判定。未列入 KEV 不代表沒有攻擊,也不構成延後修補的理由。這是具時間點的查核結果;請以 PHP 官方公告與維護供應商的最新資訊處理。

回到部落格