在開源 CMS 的世界裡，Drupal 安全是少數幾個公開流程優於平台名聲的領域之一。Drupal 安全團隊按固定的揭露時程運作，用一套有據可查的數值標準為每一份公告評分，並在核心與數以萬計的貢獻專案之間協調修復。

現實中的紀錄配不上這套流程。Drupal 網站確實會被攻破，而原因幾乎從來不是沒有人知道。公告準時發布了，就在某個星期三。修補程式則是隔週才進到正式環境。這篇文章要談的正是那段空檔，而安全強化、防火牆與檔案權限的存在，都是為了讓這段空檔變得撐得過去，或者把它縮短。

決定風險的是你修補的速度，而不是你剛好裝了哪些模組。 核心公告落在每月一次的星期三時段，貢獻專案公告則是每週三，兩者都依據一套公開的標準評為 0 到 25 分。極其嚴重的核心缺陷曾在揭露後數小時內就遭到利用：2014 年那份 SQL 注入公告發布之後，官方指引是把任何在七小時內沒有完成修補的網站直接視為已遭入侵。一個無法在一個工作日內部署核心修補程式的網站，幾乎承擔了全部存在的風險。

Drupal 安全公告流程實際上如何運作

多數經營 Drupal 網站的人從沒讀過這些流程文件，這很可惜：文件明明白白寫著你能得到多少預警、以什麼形式、在哪幾天。

發布時段

安全團隊照行事曆發布。貢獻專案公告每週三發出。核心在每月第一個星期三有錯誤修正與功能發布時段，第三個星期三則是安全發布時段，安全發布時程的文件對此有明確規定。時段並不承諾一定會有東西發布，它存在的意義是讓管理者知道該盯住哪幾天。

偶爾會有事前通知。在一次極其嚴重的核心發布之前，團隊可能會發出一則公共服務公告，通常在星期一。PSA-2026-05-18 就是為 2026 年 5 月 20 日的發布這麼做的，點明了 17:00 到 21:00 UTC 的時段，並要求網站擁有者先把自己所在分支更新到最新的修補版本，好讓升級問題提早浮現。兩天，就是你能拿到的最長預警。

核心公告與貢獻專案公告

這是兩套保證程度不同的機制。核心公告涵蓋受支援的次要分支，一次兩條，最新的一條加上前一條。依照核心發布時程，實際上就是 11.4.x 與 11.3.x，而在 Drupal 10 於 2026 年 12 月 9 日走到生命週期終點之前，10.6.x 仍在涵蓋範圍內。截至 2026 年 9 月初，目前的版本是 11.4.5、11.3.16 與 10.6.15。Drupal 12.0.0 與 11.5.0 預定在 2026 年 12 月 7 日那一週發布，屆時 11.3.x 與 10.6.x 的支援隨之結束。

貢獻專案的涵蓋是自願加入且附帶條件的。只有在安全公告流程與權限政策之下，由維護者主動申請並獲得核准的專案，其受支援主要分支上的穩定版本，才會有公告。處於 alpha、beta 或候選發布版本的模組落在這套體系之外，維護者從未申請過的模組也一樣。網站正常運作時，這兩件事在管理介面上都看不出來。

真正的工作量在於數量。2026 年 8 月 26 日星期三，團隊在一天之內發布了十份貢獻專案公告，全部為中等嚴重。一個跑著六十個模組的網站，一年會被點名好幾次，而這條源源不絕的細流，長期成本高過核心那幾次緊急事件。

風險評分，以及它為何不是 CVSS

每一份公告都帶一個滿分 25 的數字。這套標準以 NIST 的通用誤用評分系統為基礎，也就是 NISTIR 7864，並記錄在安全風險等級說明頁上。六項指標構成輸入：攻擊複雜度、所需認證、機密性影響、完整性影響、是否存在已知的攻擊程式，以及目標分布。分段為：不嚴重 0 到 4，較低嚴重 5 到 9，中等嚴重 10 到 14，嚴重 15 到 19，極其嚴重 20 到 25。

正因為目標分布計入評分，只在少見設定下才會咬人的缺陷，得分會低於它在 CVSS 之下應有的水準。2026 年 6 月 17 日的 SA-CORE-2026-005 是一個以 CVE-2026-55803 追蹤的 PHP 物件注入問題，得 18 分，正是基於這個理由被評為嚴重而非極其嚴重。

當一個貢獻模組被標示為不再受支援

安全團隊無法強迫一位志工維護者修好任何東西。當維護者不再回應，記錄在案的程序是在反覆嘗試聯繫之後，把專案標示為不再受支援。專案頁面隨即會提醒網站擁有者：改用一個仍在積極維護的替代品，或者出錢請人修好這個缺陷，讓模組可以重新發布。

這條建議正確，而且昂貴，因為等到一個模組被標示為不再受支援時，它通常已經是承重結構，替換它意味著資料移轉、樣板改動和一整輪迴歸測試。真正便宜的時機是被放棄之前的那一次發布，維護者已經沉默但還沒有任何東西壞掉的時刻，而那時幾乎沒有人在看。

Drupal 7 已終止支援，而延長支援不等於安全

Drupal 7 已於 2025 年 1 月 5 日走到生命週期終點，PSA-2025-01-06 對此做了確認。從那天起，安全團隊停止為 Drupal 7 核心及其貢獻模組與佈景主題提供支援與公告。該公告明確寫道，Drupal 7 的安全問題此後可能在沒有任何協調的情況下被公開揭露，零時差漏洞也可能出現。

商業延長支援市場是存在的。Drupal 協會在延長安全支援供應商計畫之下認證了若干廠商，包括 HeroDevs 與 Tag1 Consulting，它們確實會產出修補程式。這比什麼都沒有要好，但不等同於受支援。廠商按自己的時程，為付費客戶修補核心以及一組它自己選定要涵蓋的模組。你的網站所依賴的生態系其餘部分，不在範圍內。

一個不再受支援的 CMS，在供應商保證問卷上難以交代，事故之後面對保險公司同樣難以交代。我們關於 Drupal 遷移的成本、選項與期限的指南，寫清了退場這條路要花多少錢。

歷史留下的模式：Drupalgeddon 及其後續

三起事件塑造了社群對修補速度的看法。每一起都是核心中的注入或遠端程式碼執行缺陷，每一起都在數小時到數天內引來了大規模的自動化利用。

2014 年 10 月的七小時窗口

最初的 Drupalgeddon 是 SA-CORE-2014-005，發布於 2014 年 10 月 15 日。CVE-2014-3704 是 Drupal 7 資料庫抽象層中的一個 SQL 注入缺陷，匿名使用者即可利用，拿到了滿分 25 分中的 25 分。所有低於 7.32 的 Drupal 7 網站都受影響。

真正讓它成為里程碑的是後續通告。PSA-2014-003 告訴網站擁有者，自動化攻擊在公告發出後數小時內就開始攻陷未修補的網站，並且他們應當假定任何在當天 23:00 UTC，也就是發布後七小時之前沒有完成修補的網站，已經遭到入侵。不是可能遭到入侵，是已經遭到入侵。通告還警告攻擊者可能已經取走全部資料並植入後門，正是這一點把修補的問題變成了事件應變的問題。

Drupalgeddon 2 與 3

發布於 2018 年 3 月 28 日的 SA-CORE-2018-002 即 CVE-2018-7600，是一個橫跨 Drupal 7 與 Drupal 8 多個子系統的遠端程式碼執行缺陷，得 25 分中的 24 分。它影響 Drupal 7.0 到 7.57，以及 8.5.0 之前的各條 8.x 分支，公開的攻擊程式在大約兩週內出現。

四週之後，SA-CORE-2018-004 於 2018 年 4 月 25 日落地。CVE-2018-7602 是相關程式碼裡的另一個遠端程式碼執行問題，得 25 分中的 20 分，而公告明確寫著它已經在實際環境中被利用。教訓在於這段間隔：三月完成修補之後便不再留意的網站，四月又一次暴露。

2026 年 5 月，以及沒有改變的事

這套模式並不是歷史。SA-CORE-2026-004 發布於 2026 年 5 月 20 日：CVE-2026-9082 是一個影響 PostgreSQL 上網站的 SQL 注入缺陷，被評為極其嚴重的 25 分中的 23 分，涵蓋從 8.9 一直到 11.3.9 的所有分支。5 月 22 日 04:30 UTC，該公告被修訂，記錄了在實際環境中偵測到的利用嘗試，從發布到觀察到攻擊不足 48 小時。

這些都不是在批評安全團隊。他們給了兩天預警，在宣布的時段內出貨，並在情況改變時更新了公告。失效的一端在維運方：從公告到一個完成修補的正式網站之間，沒有一條演練過的路徑。

Drupal 安全在實務上真正失守的地方

核心拿走了所有標題，卻是其中最小的一環。在我們稽核的網站裡，真正要緊的發現很少是一個未修補的核心版本，因為核心更新會出現在管理介面上，總有人會注意到。風險敞口在別處。

沒有人擁有的模組清單

一個典型的中型 Drupal 網站跑著四十到八十個貢獻模組，每一個背後是不同的維護者與不同的節奏。幾乎沒有人能當場回答的問題是：其中哪些仍有活躍的維護者，哪些受公告政策涵蓋，哪些已經兩年沒有一次提交。這份清單，做出來要花上一個下午。

沒有人認領的自訂模組

最常見的嚴重發現，是一個由已經離開的外包人員寫下的自訂模組。它通常做著整合性質的事：一條 CRM 資料流、一個客製的表單處理器、一個金流回呼。它是對著更舊的 API 寫的，沒有測試，團隊裡沒有人說得清它到底驗證了什麼。自訂程式碼按定義就在公告體系之外：不會有哪封星期三的信件告訴你它含有 SQL 注入，而狀態報告會把一切顯示為最新。它需要與其他軟體開發工作同樣的審查紀律。

Drupal 底下的那一層

Drupal 是 PHP，而 PHP 版本按自己的時程走到生命週期終點。一個網站完全可以在 CMS 層面修補齊全，卻跑在一個一年前就停止接收安全修正的 PHP 版本上，因為主機環境從來沒有被納入維護的對話。關於檔案權限與擁有權的指引，立足於一條原則：網頁伺服器不得能夠寫入它自己執行的檔案。然而許多網站仍以可寫入的程式碼目錄運作，只因為這樣讓某個部署指令稿更省事。

一個 Drupal 網站本該如何修補

答案很無聊，這正是它遲遲沒有被落實的原因。沒有任何工具能免去一條從公告到正式環境的演練過的路徑，而把它建起來一次，比第一次緊急事件便宜。

Composer 工作流程

Drupal 8 之後的一切都是 Composer 專案。連同相依套件一起更新核心套件，然後套用資料庫更新並重建快取：

1composer update "drupal/core-*" --with-all-dependencies
2drush updatedb
3drush cache:rebuild

Drush 可以換成 update.php。前後都檢查一次狀態報告。重要的不是這幾條指令，而是它們先在正式環境之外的某個地方跑過。

真的是一份複本的預備環境

預備環境只有在它映照正式環境時才有用：同一套模組、同一個 PHP 版本、一份近期的去識別化資料庫。一個陳舊的預備網站給出的綠色結果毫無意義，那比沒有預備環境更糟，因為它製造信心。

順序是：把正式環境拉到預備環境，套用更新，執行資料庫更新，走一遍那些讓網站具備商業價值的頁面與表單，然後部署。有一條能用的管線，這需要 45 到 90 分鐘。沒有的話，是一天半。

自動化，以及它的限度

自動化相依更新最有幫助的地方，是貢獻模組這條數量大、嚴重度低的細流。一個機器人為每次模組更新開一個拉取請求，並對每一個都跑一遍測試，就把每月一次的手工清掃變成了一條審查佇列。核心也在往同一個方向走：自動更新的工作建立在 Package Manager 模組之上，該模組隨核心一同發布，但仍處於實驗階段。

現實的時間預算

一個被認真維護的 Drupal 網站，例行模組更新大約每月花掉半天，再加上每一次適用的核心安全發布所需的一到三小時。還要為一年裡那一兩次必須當晚完成的極其嚴重發布留出餘裕。這就是多數內部團隊從未編入預算的那個數字，也是這項工作總被往後推的原因。

修補之外的安全強化

安全強化不能取代修補。它減少的是已公開漏洞中在你這套安裝上真正可被利用的數量，並在修補程式無法立即發布時爭取時間。那些 Drupal 特有的動作都很便宜，而且一勞永逸。

信任的主機與檔案系統

設定信任主機樣式。Drupal 使用 Symfony 的信任主機機制，透過 settings.php 裡的 trusted_host_patterns 設定，寫成比對網站對外回應網域的正規表示式。帶有其他 Host 標頭的請求會被以 400 拒絕。少了它，攻擊者可以用偽造的標頭汙染密碼重設連結與被快取的絕對網址。

任何不該被公開讀取的東西都放進私有檔案系統，並確保 PHP 不能在公開檔案目錄內執行。Drupal 內附一份 .htaccess 檔案，在 Apache 之下阻止執行，但 nginx 沒有對應的放進去就生效的檔案，規則必須手動寫進伺服器設定。多年前從 Apache 搬到 nginx 的網站，常常在無聲無息中丟掉了這層保護。

接著套用擁有權模型：目錄 750，程式碼檔案 640，檔案目錄只對網頁伺服器可寫，settings.php 只對擁有者可讀。

權限、管理路由與一次審查

限制管理路由。一個編輯人員只在三個辦公室工作的網站，其登入與管理路徑沒有任何理由要對整個網際網路開放，一份 IP 允許清單或一個帶認證的代理伺服器，就能去掉一整類憑證攻擊。

接著稽核權限矩陣。它隨著每裝一個模組而長大，而發現的問題幾乎總是同一個形狀：一個能管理文字過濾器的編輯角色，或者一個能執行任意 PHP 的角色。兩者都會把一組被竊的編輯密碼變成遠端程式碼執行，於是一封釣魚信件就成了伺服器淪陷。

在爭論其他任何事情之前，先跑一遍 Security Review 模組。它把那些手動做起來很煩的檢查自動化了：檔案系統權限、不安全的文字格式、內容裡的 PHP 或 JavaScript、錯誤報告外洩、上傳副檔名、失敗登入、危險權限，以及信任主機設定。2026 年 1 月發布的 3.1.3 版，除了 Drupal 11 之外也支援 Drupal 10.3 以上。

防火牆能買到什麼，又買不到什麼

網頁應用程式防火牆是一種虛擬修補，Drupal 協會正是這樣定位它與安全團隊共同營運的付費服務 Drupal Steward 的。它為某些極其嚴重的核心漏洞提供網路層的緩解，在公告與部署之間的空檔裡保護網站。公開的定價是：每月處理 100 萬次 HTTP 請求的網站低於 20 美元，超過 1000 萬次的低於 100 美元。

限制由專案自己說明：並非每一個問題都能用這種方式緩解，而且這套機制只涵蓋透過對網頁伺服器的請求被利用的漏洞。防火牆對一組被竊的管理員密碼、一次惡意的模組更新，或者你自己程式碼裡的一個缺陷，什麼都做不了。把它當成修補時間窗的保險，而不是把這個窗口拉長的理由，這也是我們在 WordPress 安全強化檢查清單裡持有的看法。

一次入侵的代價，以及復原是什麼樣子

從一次 Drupal 入侵中復原不是打個修補程式。一旦攻擊者取得程式碼執行，工作假設就是檔案被寫入、憑證被取走、持續存活機制被安裝，這正是安全團隊在 2014 年告訴 Drupal 7 網站擁有者的話。原地清理一個被攻破的網站，是披著修復外衣的猜測。

站得住腳的做法是：從版本控制在一台新主機上重建程式碼庫，只在檢查之後還原內容與上傳的檔案，輪替網站持有過的每一份憑證，並保全而不是刪除被攻破的磁碟映像。最後這一步是人們在壓力之下最常跳過的，而它是關於發生了什麼的唯一證據。

商業代價很少來自重建本身，而是來自停機、鑑識工作、客戶溝通與法遵流程。事件條件下的一次重建，通常是 5,000 到 20,000 英鎊的工程量，往往是總帳裡最小的一項。

英國的資料保護義務

如果個人資料已被或可能已被存取，UK GDPR 的時鐘從你意識到的那一刻開始走，而不是從你查清楚的那一刻。ICO 的資料外洩指引要求，應通報的外洩必須毫不遲延地通報，且不得晚於意識到之後的 72 小時，若耗時更久則必須說明理由。當外洩很可能對個人的權利與自由造成高風險時，你還必須毫不遲延地通知這些個人。

ICO 說得很清楚：掌握的情況不完整，不是錯過期限的理由，先通報你知道的，隨後補充。在應當通報時未通報，可能招致最高 870 萬英鎊或全球營業額百分之二的罰鍰。

這個時鐘正是鑑識問題為何要緊的原因。一個沒有紀錄檔、也沒有留下當時跑的是哪個版本的網站，說不清哪些資料被存取過，於是最後只能按最壞情況通報。這就是應當在事故之前而不是之後做一次網站安全稽核的理由。

一份 Drupal 安全維護合約該包含什麼

一份只承諾套用更新的維護合約不值得買，因為套用更新是容易的那一半。你真正付錢買的，是極其嚴重公告落地那天的應變路徑，而證明它有效的交付物是一次演練。

值得付錢的範圍包括：針對你確切模組清單的公告監控；帶預備環境、測試與回復方案的月度修補週期；針對極其嚴重核心發布、事先約定好的非上班時間應變時段；每季一次的被放棄模組審查並給出替代方案的估價；PHP 與平台版本追蹤；以及一年一次的設定審查。

在英國，只做監控的安排大致是每月 250 到 450 英鎊。包含預備環境、測試與部署、面向中型網站的維護合約，則更接近每月 600 到 1,500 英鎊，隨模組數量與自訂程式碼的體量而浮動，因為這兩者決定了每個週期需要多少迴歸測試。對照 600 到 900 英鎊的開發公司日費率，這個區間的上端大約買到兩個工程師日。我們那篇關於 Drupal 開發者費率與甄別的文章裡有具體數字。

關上那道空檔

Drupal 給你的預警與結構，比幾乎任何可相比的平台都多。公告按時程發出，極其嚴重的發布帶著兩天預警抵達。可這一切都幫不了一個要花兩週才能部署一行修補的網站。

Mecanik 把 Drupal 的修補與安全強化，當作網站安全稽核與持續軟體開發工作的一部分來處理。第一次合作通常是一次盤點而不是一次修復，因為多數網站說不出自己的模組裡還有哪些仍受支援。如果你還在權衡平台本身，我們的 2026 年 Drupal 網站開發指南談的正是那個問題。

常見問題

Drupal 多久發布一次安全更新。 貢獻專案公告每週三發布，Drupal 核心則在每月第三個星期三有一個安全發布時段，不過時段並不保證一定會有發布。極其嚴重的核心發布之前，通常會提前大約兩天發出一則公共服務公告，點明日期與時間時段。

Drupal 安全風險評分 25 分中的 20 分是什麼意思。 Drupal 用一套以 NIST 通用誤用評分系統為基礎的方法，為每一份公告打出 0 到 25 分，綜合考量攻擊複雜度、所需認證、機密性與完整性影響、是否存在已知的攻擊程式，以及受影響網站的數量。凡是落在 20 到 25 之間的都屬於極其嚴重，意味著當天就要完成修補。

2026 年還能安全地運行 Drupal 7 嗎。 不能。Drupal 7 已於 2025 年 1 月 5 日走到生命週期終點，Drupal 安全團隊不再為其核心、貢獻模組或佈景主題發布公告，因此缺陷可以在沒有協調修復的情況下被公開揭露。商業延長支援按廠商自己的條件涵蓋一組限定的程式碼，它在遷移期間有幫助，但不等同於受支援。

攻擊者利用一個 Drupal 漏洞有多快。 最壞的情況是幾小時之內。2014 年 10 月那份 SQL 注入公告之後，Drupal 安全團隊告訴網站擁有者，應當假定任何在七小時內沒有完成修補的網站已經遭到入侵。2026 年 5 月，針對一個極其嚴重的核心 SQL 注入的利用嘗試，在發布後不到兩天就在實際環境中被偵測到。

有了網頁應用程式防火牆，Drupal 還需要修補嗎。 需要。像 Drupal Steward 這樣的防火牆，為某些透過網頁請求被利用的極其嚴重核心缺陷提供虛擬修補，從而在部署時間窗裡爭取時間。它幫不了被竊的管理員密碼、被汙染的模組或你自己程式碼裡的缺陷，所以它降低的是這段空檔的風險，而不是把空檔關上。