Pi-hole（pi-hole/pi-hole）是 GitHub 上累積 61,341 顆星標的開源 DNS 過濾服務，以自架 Linux 主機為整個網路提供廣告與追蹤器攔截。該專案於 2026 年 10 月 17 日同步發布 Core v6.5 與 FTL v6.8，兩者合計修補 14 項安全公告，其中 5 項被評為高危，CVSS 分數介於 7.3 至 7.8 之間，問題類型集中在以 pihole 服務帳號為跳板的本機提權與任意檔案覆寫。對於部署在路由器旁、長期無人看管的家用與小型辦公室節點而言，這是自 v6 系列發布以來安全密度最高的一次更新。
Pi-hole v6.5 是什麼？
Pi-hole v6.5 於 2026 年 10 月 17 日發布，修補 5 項安全公告並改良 gravity 資料庫結構，須搭配 FTL v6.8 才能完整修復。
Pi-hole Core 是整個系統的安裝與管理層，負責 DNS 服務初始化、封鎖清單下載（gravity）、命令列工具與升級流程；實際的查詢解析、快取與統計則由以 C 語言撰寫的 FTL 引擎處理。這次 Core v6.5 與 FTL v6.8 在同一天發布，正是因為部分修補需要兩邊配合，例如以 file:// 形式載入的本機封鎖清單，必須由 Core 傳遞來源網址給 FTL 的解析函式，才能避免檢查與實際讀取指向不同檔案。
從版本節奏觀察，Core 上一版 v6.4.3 發布於 2026 年 7 月 6 日，相隔約三個半月；FTL 的 v6.7.1 落在 2026 年 9 月 19 日，間隔不到一個月。這次 FTL 直接跳過 v6.7.2 而以 v6.8 命名，維護團隊在發布說明中解釋，因為可見的行為變更數量足夠多，用修補版號會低估改動幅度。
為什麼這次更新被列為高優先級安全修補？
14 項公告中有 5 項屬高危，全部涉及本機使用者提升為 root 權限或由 root 寫入任意路徑，取得 pihole 帳號或網站控制權即可奪取主機。
高危項目分布在兩個儲存庫。Core 一側有四項：以特製 PID 內容觸發指令執行（GHSA-cf36-4hhc-8398，CVSS 7.8）、寫入版本檔時跟隨符號連結而由 root 覆寫任意檔案（GHSA-xch2-4qxw-g5vj，7.8）、/opt/pihole 對 FTL 服務不再可寫（GHSA-j8vh-6fp9-cjcx，7.8），以及 root 依設定檔提供的路徑寫入檔案（GHSA-mff6-cjc4-5wq9，7.3）。FTL 一側則有一項，網站根目錄可透過 Teleporter 匯入或符號連結被搬移（GHSA-2h7g-g549-hf74，7.7）。
這些問題的共同前提是攻擊者已能在主機上以 pihole 帳號執行指令，或已取得網頁介面的工作階段。對於只在家用網段開放 53 與 80 埠的節點，直接從外部利用的門檻較高；但對於把 Pi-hole 網頁介面暴露到網際網路、或同時執行其他服務的共用主機，風險顯著上升。值得注意的是，本次多項公告的發現者包含 KimiSecurityTeam 等安全研究團隊，顯示這類自架基礎設施已進入系統化稽核的範圍。
這些漏洞的實際風險有多高？
風險取決於暴露面：家用內網節點屬中等，網頁介面公開或與其他服務共構的主機則屬高風險，因為提權成功即代表 root 權限與整台主機的資料外洩。
最具代表性的案例是 CVE-2026-41489 修補的繞過。該編號原先修補的是 PID 檔內容未經驗證的問題，做法是把路徑固定為 /run/pihole-FTL.pid，並以 expr "${FTL_PID}" : "[^[:digit:]]" 檢查內容。這個正規表示式只比對開頭第一個字元是否為非數字，任何以數字起首的字串都會原樣通過，隨後被送入 bash 的算術比較 [[ "$pid" -eq "-1" ]]。
bash 在算術上下文中會遞迴展開陣列下標，包括命令替換，因此把 1+a[$(id > /tmp/PWNED-ROOT-PROOF)] 寫入 PID 檔後，執行 pihole reloaddns 這類需要 root 的子命令便會以 root 身分執行攻擊者指定的指令。研究者在官方容器中完成端到端驗證，證明 pihole 使用者可藉此建立內容為 uid=0(root) 的檔案。這類問題的嚴重性不在於單一指令，而在於它把「低權限服務帳號」直接等同於「主機管理員」。
另一項值得留意的低危項目是 file:// 封鎖清單的檔案讀取檢查與 curl 實際解析可能指向不同檔案（GHSA-g63w-24cr-p3w6，CVSS 2.2）。單獨看影響有限，但它與 FTL 的 file:// 內容回顯問題（GHSA-667h-gpmh-7gxc，6.5）組合後，可構成資訊洩漏路徑，因此兩個版本被要求同步升級。
Pi-hole FTL v6.8 同時修補了哪些問題？
FTL v6.8 修補 9 項公告，涵蓋網站根目錄搬移、file:// 清單內容回顯、唯讀工作階段可讀密碼雜湊與 TOTP 密鑰、API 緩衝區越界與 EDNS(0) 資料外洩。
除高危的網站根目錄問題外，FTL 的中危項目包括 file:// 封鎖清單解析時回顯本機檔案內容（6.5）、唯讀工作階段仍可讀取密碼雜湊與雙因素驗證密鑰（6.5）、API 的 TXT 緩衝區越界寫入（5.9），以及 EDNS(0) 資料在不同客戶端查詢之間洩漏（4.2）。其中唯讀工作階段一項特別值得企業注意，因為它意味著原本設計為展示用的低權限介面，實際上仍能取得足以離線破解或重播的憑證材料。
低危項目則有無密碼安裝狀態下的跨站請求與 DNS 重新綁定（GHSA-322h-f873-hp54）、格式錯誤的 POST 正則陣列導致崩潰（2.7）、刪除 DHCP 租約時的競爭條件（2.2），以及清單重載期間搜尋網域造成崩潰（2.2）。最後兩項雖屬可用性問題，但在封鎖清單自動更新頻繁的環境中，崩潰即代表 DNS 解析中斷，對整個網路的影響往往比單一檔案洩漏更直接。
除了安全修補，v6.5 與 v6.8 還有哪些效能改進？
即時日誌改為環形緩衝區，每筆快取回應的 CPU 成本大幅下降；長期統計改為先分組再連接名稱表，並移除兩個未使用的記憶體索引，每百萬筆查詢節省約 22 MB。
FTL 的即時日誌原本在每新增一行時搬移整個緩衝區，查詢量大的節點因此付出可觀的 CPU 成本；v6.8 改為環形緩衝區（ring buffer）後，寫入成本與緩衝區長度脫鉤。長期統計的查詢則改為先在群組層級聚合，再與名稱表連接，並移除兩個未使用的記憶體索引，官方給出的數字是每百萬筆查詢節省約 22 MB 記憶體，對於執行在單板電腦上的節點屬於實質改善。
Core 一側的調整集中在 gravity 子系統。v6.5 為 junction 資料表加上 WITHOUT ROWID、新增群組查詢索引並簡化觸發程序，既有資料庫在升級時會自動遷移到結構版本 21；listsCache 目錄也改為存放在 gravity.db 旁邊，不再固定寫入 /etc/pihole。此外，國際化網域現在改用 libidn2 轉為 punycode 後封鎖，而非直接視為無效項目，這對使用中文或歐語網域的封鎖清單是行為層面的改變。
管理員應如何安全地完成升級？
先備份 /etc/pihole 與自訂封鎖清單，再執行 pihole -up 或重拉映像；升級後驗證版本檔權限、gravity 結構與 DNS 解析，並避免公開網頁介面。
由於本次多項漏洞的前提是本機帳號或網頁工作階段外洩，升級之外的收斂措施同樣重要。建議把網頁介面限制在內網或 VPN 之後，為管理介面啟用密碼與雙因素驗證，並確認 pihole 服務帳號無法寫入自身執行檔目錄。對於以 Docker 部署的節點，映像標籤若固定在小版本，需主動拉取新標籤才會取得修補；使用 latest 標籤的節點則應在更新後確認容器內 FTL 版本為 v6.8。
實務上可透過 pihole -up 一次完成 Core 與 FTL 的更新，或使用官方 Docker 映像重新拉取。升級後應檢查三件事：/etc/pihole/versions 是否為所有使用者可讀、/opt/pihole 是否已對 FTL 服務轉為唯讀、以及 gravity 資料庫是否已遷移至結構版本 21。若節點曾手動調整過 logrotate 設定，需注意 v6.5 已把 Pi-hole 納入系統的 /etc/logrotate.d，重複設定會導致日誌被輪替兩次。
Pi-hole 在 2026 年的生態位置如何？
Pi-hole 仍是自架 DNS 過濾的事實標準，Docker 映像累積近 10 億次拉取，並衍生出多個社群前端與同步工具，但其定位正面臨加密 DNS 與瀏覽器內建防護的擠壓。
官方 Docker 映像在 Docker Hub 累積 997,484,681 次拉取與 2,964 顆星標，這個量級說明它早已超出「樹莓派愛好者玩具」的範圍，成為許多家庭實驗室與小型辦公室的標準元件。生態周邊亦相當完整，包括第三方網頁前端、多節點同步工具、與路由器韌體的整合，以及針對 container 環境的維護分支。
壓力同樣明顯。瀏覽器逐步預設啟用加密 DNS，使部分查詢繞過本地解析器；行動作業系統的Private Relay 類服務也讓使用者離開自架 DNS 的覆蓋範圍。Pi-hole 的回應是把 FTL 的效能與管理介面持續現代化，v6 系列重寫的網頁介面與 API 正是這個方向。對於需要全網路可視性與統一封鎖策略的環境，它仍是最低成本的選擇；對於只追求個人裝置安靜瀏覽的使用者，瀏覽器擴充功能已能覆蓋多數需求。
專案數據呈現怎樣的維護規模？
儲存庫累積 61,341 顆星標、3,325 次複製、265 位貢獻者與 127 個版本，自 2014 年創立至今以 Shell 為主要語言，採 EUPL 授權，待處理議題僅 37 個。
待處理議題僅 37 個，對於一個擁有 61,341 顆星標的專案而言屬於極低水位，反映維護團隊對議題分類與清理的紀律。貢獻者總數 265 位，核心維護者規模不大，這也是本次安全公告高度集中在少數幾位審核者身上的原因。授權方面，Pi-hole Core 採用歐盟公共授權（EUPL），與常見的 MIT 或 Apache 不同，企業在再散布或修改後發布時需要確認條款相容性。
出處連結有哪些？
主要出處為 pi-hole/pi-hole 與 pi-hole/FTL 儲存庫，v6.5、v6.8 發布說明及安全公告，官方文件站 docs.pi-hole.net。
本文數據取自專案公開資料，包括 Core v6.5 與 FTL v6.8 的發布說明、GitHub 安全公告頁面、儲存庫統計與 Docker Hub 映像指標。讀者如需核對個別公告的技術細節，可依下列連結前往原始來源。
- Core 儲存庫：https://github.com/pi-hole/pi-hole
- FTL 儲存庫：https://github.com/pi-hole/FTL
- Core v6.5 發布說明：https://github.com/pi-hole/pi-hole/releases/tag/v6.5
- FTL v6.8 發布說明：https://github.com/pi-hole/FTL/releases/tag/v6.8
- 官方文件：https://docs.pi-hole.net
總結：Pi-hole 值得部署嗎？
值得，但前提是把管理介面收在內網並及時升級。它以極低成本提供全網路層級的 DNS 過濾，代價是必須像對待任何 root 服務一樣對待它。
這次更新揭示的重點並非某個單一漏洞，而是自架基礎設施的長期風險模型：一個安裝在路由器旁邊、由社群維護、以 root 執行部分子命令的服務，只要其中一環的輸入驗證鬆動，整台主機的權限邊界就跟著鬆動。CVE-2026-41489 的修補被單一字元比對繞過，正是這類風險的典型樣態。
對於已經部署的節點，升級到 Core v6.5 與 FTL v6.8 是必要動作，難度不高且可透過既有命令完成。對於正在評估的環境，Pi-hole 仍以 61,341 顆星標、近 10 億次映像拉取與 265 位貢獻者的規模，提供無可替代的成本效益；但部署決策應同時包含網路隔離、管理介面收斂與固定升級節奏，否則省下的廣告攔截成本，可能以主機淪陷的形式償還。
