跳轉到

組織網站遇到重大漏洞時的確認與應對

公民團體、協會與小型媒體的網站，平常多半由代管服務、主機商或外包工作室維護。網站底下的某個軟體出現重大漏洞時，負責網站的人往往不是工程師，卻要判斷網站有沒有受影響、該找誰處理。

這篇寫給協會的行政、NGO 的專案人員、小型媒體的編輯這類負責網站的人。內容以 2026 年 10 月的 PHP 漏洞為例，事件的日期與版本號集中在下面的方塊，做法也適用於之後類似的情況。

例子：2026 年 10 月的 PHP 漏洞

PHP 是 WordPress 這類架站程式底下負責執行網站程式的軟體。10 月 20 日，兩個漏洞編號（CVE-2026-109618、CVE-2026-109619，CVE 是公開漏洞的統一編號）在預定公開前外洩。PHP 在 10 月 21 日發布 8.5.12、8.4.27、8.3.36 與 8.2.35 修補，兩個漏洞可能讓沒有登入的攻擊者在伺服器上執行程式碼。WordPress.org 的公告說明這不是 WordPress 本身的漏洞，不會為此發布更新，要更新的是伺服器上的 PHP。台灣電腦網路危機處理暨協調中心（TWCERT/CC）10 月 22 日的警訊寫到網路上已出現概念驗證程式（證明漏洞能被利用的程式），Cloudflare 也觀察到攻擊流量。

趕時間的話，先做這三件

  1. 確認網站放在哪裡、底層的軟體由誰更新，做法見下一節
  2. 把漏洞編號寄給負責的人，請對方書面回覆是否已修補、何時修補。主機費由外包商代付時，寄給外包商
  3. 對方確認修補完成後，更換網站後台管理者帳號的密碼，並開啟兩步驟驗證

網站放在哪裡，誰負責哪一層

一個網站大致分成三層，最上面是網站程式，例如 WordPress 與它的佈景主題、外掛。中間是執行網站程式的軟體，例如 PHP，最下面是作業系統與伺服器。漏洞出在哪一層，就要找負責那一層的人。

PHP 漏洞出在中間那一層。WordPress.com 的營運公司 Automattic 的說明寫到，這是執行環境的修補，只更新 WordPress、佈景主題或外掛涵蓋不到。平常在後台按下的「更新」，多半只更新最上面那一層。

網站放在哪裡 網站程式由誰更新 執行環境與作業系統由誰更新
代管服務，註冊帳號就能架站，例如 WordPress.com 業者或你 業者
租用主機（虛擬主機、共用主機），後台多半是主機商提供的管理介面 你或外包商 主機商
雲端主機、自有伺服器，或整套交給外包商 你或外包商 你或外包商

不確定是哪一種時，看每年的主機費付給誰，以及登入網站後台用的是哪一家的帳號。網域註冊商跟主機商不一定是同一家。主機費由外包商代付、組織手上沒有主機帳號時，找外包商，由他們向主機商確認或代為處理。

放在代管服務的網站，看業者的公告就好。以 PHP 漏洞為例，Automattic 的說明寫到放在 WordPress.com 等自家代管服務的網站已經受到保護，管理者不必另外調整設定。這類網站只需要做「修補後的檢查」最後一段的三件事：換後台密碼、檢查管理者名單、開啟兩步驟驗證。租用主機或交給外包商的，接著看下一節。

給主機商或外包商的問題

寄信時附上漏洞編號，對方查起來比較快，並請對方用書面回覆。可以問這五件事：

  1. 網站使用的 PHP 是哪個版本，這兩個漏洞是否已修補、何時修補，更新後 PHP 服務是否已重新啟動
  2. 修補方式是升級到官方的新版本，還是主機作業系統的套件更新（兩種的版本號看起來不同，見下一節）
  3. 修補完成之前，有沒有看到不尋常的存取，能不能協助檢查漏洞消息外洩那天以後的紀錄
  4. 組織這邊需要做什麼，例如更換哪些密碼
  5. 使用的版本還在官方的支援期內嗎，不在的話，升級的時程與費用

對方回覆「已經處理好了」時，請對方補上版本號與修補時間，書面回覆之後可以用來對照。已經有人公開能利用漏洞的程式時，等待的時間越短越好。當天或隔天沒有回覆、或答不出版本號時，本頁建議當成暫時無法修補，看「暫時無法修補時的選項」。

版本號的判讀

用 WordPress 的網站，WordPress.org 的公告寫到可以在後台英文介面的「Tools > Site Health > Info > Server」看到 PHP 的版本，中文介面的選單名稱本頁沒有核對。不是 WordPress 的網站，請主機商或外包商提供版本號。

PHP 的版本號由三段數字組成，前兩段是系列。官方修補版本要對照同一系列，例如 8.4 系列要 8.4.27 以上、8.3 系列要 8.3.36 以上，才是已經修補的官方版本。

主機作業系統的套件常把修補移植到原本的版本，版本號維持舊的號碼。例如 Ubuntu 24.04 修補後的 PHP 套件是 8.3.6-0ubuntu0.24.04.13。其中的 8.3.6 是另一個版本號，不能拿來跟官方的 8.3.36 比，直接對照會誤判成沒有修補。看到比官方修補版本小的數字時，要以主機商或外包商的書面回覆為準。

版本號最直接的用途，是確認有沒有過了支援期。依 PHP 官網的支援版本頁，8.1 以下已經結束支援，官方不再提供更新。8.2 會在 2026 年 12 月 31 日結束支援。

PHP 的公告也提到，部分作業系統與長期支援的業者會替舊版提供移植的修補。例如 Ubuntu 22.04 的 PHP 8.1 套件就有修補版，舊版有沒有修補同樣要以書面回覆為準。PHP 團隊另外替 7.4、8.0、8.1 提供了原始碼修補，對象是自行從原始碼建置 PHP 的人，租用主機的組織用不上。

版本過了支援期的網站要列入升級計畫，升級可能影響網站程式的相容性，時程與費用請主機商或外包商估算。

暫時無法修補時的選項

主機商還沒修補、版本過了支援期而且主機商也沒有舊版的修補，或外包商聯絡不上時，有三種做法可以選。

第一種是暫時停止網站，任何組織都做得到，但要有人有權限關站。韓國網路振興院（KISA）10 月 22 日的企業應對守則建議，無法更新、也無法套用暫時設定時，考慮切斷外部連線或暫停服務。WordPress.org 的公告也引述英國國家網路安全中心（NCSC），建議無法立即修補時考慮讓系統離線。代價是讀者、會員或捐款人暫時找不到網站，本頁建議由組織負責人決定，並在社群帳號說明是預防措施、預計何時恢復。

第二種是網站前端的防護服務，前提是網站原本就接在 Cloudflare 這類服務後面，不確定的話問外包商。Cloudflare 10 月 21 日的部落格寫到，對應的網站應用程式防火牆（WAF，過濾攻擊流量的規則）從當天起對免費與付費客戶預設啟用。同一篇文章也提醒，有防火牆規則仍然要修補 PHP。

第三種是調整伺服器的設定。PHP 的公告列出幾項設定，可以縮小部分攻擊路徑，但公告也寫明只有更新能完整解決。改設定需要伺服器的權限，要交給主機商或外包商。

走了這三種做法的網站，修補完成後仍然要做下一節的檢查。

修補後的檢查

KISA 的守則建議，更新後至少檢查漏洞資訊外洩那天以後的紀錄，PHP 漏洞的外洩日是 10 月 20 日。修補前一直對網際網路開放的伺服器，守則建議更換資料庫密碼、外部服務的連線金鑰（API 金鑰，網站跟其他服務連線用的密鑰）與伺服器的管理者密碼。

守則也提醒，更新後要重新啟動所有執行 PHP 的網站服務，否則記憶體裡的舊版本會繼續執行。台灣數位發展部資通安全署 10 月 22 日的新聞稿內容也包含，更新後要檢視系統日誌與異常存取紀錄，發現可疑活動時進一步確認帳號與憑證的安全。KISA 的守則也寫明，紀錄查不到異常不代表安全，更新與更換密碼要一起做。

上面這些多半要主機商或外包商處理，「給主機商或外包商的問題」的第一、三、四題就是為了這一步。KISA 守則寫的是伺服器的管理者帳號、資料庫與連線金鑰，沒有提到 WordPress 這類網站後台的帳號。負責網站的人自己能做的是更換網站後台管理者的密碼、檢查使用者名單裡有沒有不認得的管理者，並開啟兩步驟驗證，這三件是本頁的建議。換密碼要等修補確認之後，漏洞還在時換的密碼一樣可能被取走（見 密碼管理器入門）。

發現異常時

本頁整理的常見跡象有幾種：後台出現不認得的管理者帳號或文章、首頁的內容被換掉、訪客被導到別的網站，或主機商通知網站有異常。看到這些跡象時，本頁建議先截圖、記下時間，並請主機商或外包商保留伺服器的紀錄。可疑的檔案不要自行刪除，留給處理的人判斷。

KISA 的守則針對疑似被入侵的伺服器，建議先只切斷外部連線，不要關機或重新啟動。重新啟動會清掉記憶體裡的攻擊痕跡，所以要在更新與重新啟動之前先保全證據。

資安署 2026 年 7 月發布的《資安事件應變處理行動指引》寫給中小企業的非技術人員，涵蓋的六種情境不含網站被入侵，其中帳號被盜的處理、檢核清單與對外聲明的範本可以參考。同一份指引列出的通報管道是 TWCERT/CC 的線上通報，涉及犯罪時向所在地的警察機關報案。TWCERT/CC 的一般資安通報頁寫的受理身分是「一般企業」，公民團體是否適用頁面沒有寫明。

網站裡有會員、捐款人或連署者的個人資料時，還要考慮《個人資料保護法》。目前生效的第 12 條規定，違反個資法致個人資料被竊取、洩漏、竄改時，要查明後以適當方式通知當事人。2025 年 11 月 11 日公布的修正條文改成知悉外洩就要通知當事人，符合一定範圍時還要向個人資料保護委員會（修正後的個資法主管機關）通報。

到 2026 年 10 月 22 日，修正條文的施行日期還沒定。條文以全國法規資料庫為準，修法的背景見 台灣個資法 2025 修法。

平時的準備

下面五件事可以平常先做，都是本頁的建議：

  • 列一張網站清單，寫下每個網站放在哪裡、誰負責、合約上的聯絡窗口與後台帳號放在哪裡。辦活動時架的網站與舊網站最容易被忘記
  • 寫下每個網站存了哪些人的個人資料，例如會員、捐款人、連署者，出事時才知道要通知誰
  • 跟外包商約定重大漏洞公開時，多久內要回覆與處理
  • 確認網站有定期備份，而且備份可以還原
  • 網站後台的管理者帳號開啟兩步驟驗證，密碼不跟其他服務共用

不同處境的差異

組織裡有懂伺服器的人時，這一頁的問題可以改成內部的檢查清單，由那位成員直接對照作業系統的安全公告。全靠外包商的組織，重點是「給主機商或外包商的問題」與書面回覆，合約裡最好事先寫好重大漏洞的處理時限。網站由一位志工維護的組織，風險在於那位志工聯絡不上，後台帳號與主機帳號至少要有第二個人知道放在哪裡。這一節是本頁的建議。

台灣的脈絡

PHP 漏洞公開後，TWCERT/CC 10 月 22 日發布漏洞警訊。資安署同一天的新聞稿寫到，已透過資安警訊、國家資安資訊分享與分析中心（N-ISAC）與 TWCERT/CC 通知各機關與企業。N-ISAC 2026 年 7 月修訂的會員規章列出的會員是政府機關、關鍵基礎設施的主管機關、國家型電腦緊急應變團隊與資安業者，依條文，民間團體不在其中。

民間團體查得到的公開管道，是 TWCERT/CC 的漏洞警訊公告頁、資安新聞的 RSS 與每月一期的資安情資電子報，電子報趕不上緊急的漏洞。TWCERT/CC 另有需經審核的會員制度「台灣資安聯盟」，規章列出的成員包含公協會與法人團體。小型公民團體是否符合資格、要不要費用，頁面沒有寫明。資安署 2026 年 4 月的新聞稿提到可以免費註冊 TWCERT/CC 會員接收威脅警報，是否就是台灣資安聯盟，新聞稿沒有寫明。

資安署另有給中小企業的基本資安防護指引與自檢表，以及與經濟部中小及新創企業署合作、在馬上辦服務中心提供的資安諮詢專線。這些資源的對象都寫中小企業，非營利組織能否使用頁面沒有寫明。

本頁的範圍

  • 只處理你自己組織的網站。檢查或探測別人的網站需要對方的授權，本頁不涉及
  • 不提供漏洞的利用方式與偵測規則，技術細節以官方公告為準
  • 不提供法律意見。涉及個人資料外洩時的通知與通報義務，需要諮詢律師或主管機關
  • 例子的數字與版本號會隨時間過時，遇到新的漏洞以當時的官方公告為準

求助管道

相關閱讀