--- title: "BIND 漏洞 CVE-2026-94300 自查與修補：DNS 伺服器要升到 9.20.30，9.18 沒有修補版" description: "CVE-2026-94300 是 ISC 於 2026 年 10 月 21 日公開的 BIND 9 高風險漏洞，CVSS 8.1，重放 GSS-TSIG 簽章訊息可能損毀 DNS 伺服器記憶體。沒有緩解措施，要升到 9.20.30 或 9.21.27；9.18 已停止支援、沒有修補版。本文整理自查與升級步驟。" canonical: "https://yotron-ai.com/blog/bind-cve-2026-94300-dns-server-check-patch" published: "2026-10-22" last-updated: "2026-10-22" --- # BIND 漏洞 CVE-2026-94300 自查與修補：DNS 伺服器要升到 9.20.30，9.18 沒有修補版 CVE-2026-94300 是 ISC 於 2026 年 10 月 21 日公開的 BIND 9 高風險漏洞，CVSS 8.1，重放 GSS-TSIG 簽章訊息可能損毀 DNS 伺服器記憶體。沒有緩解措施，要升到 9.20.30 或 9.21.27；9.18 已停止支援、沒有修補版。本文整理自查與升級步驟。 > 文／Laban（優創智能 AI 導入工程師） CVE-2026-94300 是 ISC（BIND 的維護單位）在 2026 年 10 月 21 日公開的 BIND 9 高風險漏洞：攻擊者重放 GSS-TSIG 簽章的 DNS 訊息，可能造成 DNS 伺服器的記憶體損毀，ISC 評估最嚴重可能導致遠端執行程式。結論先講：**自己架 BIND 的公司，要升到 9.20.30 或 9.21.27；還在用 9.18 的，這次沒有修補版可以裝**。 本文寫給有自架 DNS 的 IT 承辦人，以及不確定自己有沒有自架的老闆。本文回答四個問題：你有沒有用到 BIND、要升到哪一版、9.18 怎麼辦，以及要不要繼續自己架 DNS。本文不分析漏洞的程式細節，那是 DNS 管理者看 ISC 原文就好的事。 --- ## 一、已知事實：ISC 公告說了什麼 以下整理自 [ISC 公告 CVE-2026-94300](https://kb.isc.org/docs/cve-2026-94300)（2026-10-21 公開，2026-10-22 查詢）： | 項目 | 內容 | | --- | --- | | 問題 | 重放 GSS-TSIG 簽章的 UDP 訊息，可能造成 `named` 記憶體損毀；搭配對攻擊者自控網域的特製查詢，可能導致遠端執行程式 | | 嚴重度 | 高，CVSS 3.1 分數 8.1；不需登入、不需使用者操作，但攻擊複雜度為「高」 | | 受影響版本 | BIND 9.11.0–9.18.50、9.20.0–9.20.29、9.21.0–9.21.26（另含對應的 Supported Preview Edition） | | 修補版本 | **9.20.30**、**9.21.27**、9.20.30-S1（付費支援客戶） | | 緩解措施 | 無已知做法 | | 已知攻擊 | ISC 不知道有任何實際攻擊 | | 發現者 | ISC 內部測試發現；OpenAI 的 Dave Aitel 也獨立發現並回報 | GSS-TSIG 是用 Kerberos 驗證 DNS 動態更新的機制，常見於 BIND 和 Active Directory 或 Samba 網域整合的環境。攻擊者要先取得一則有效的簽章訊息，並在金鑰還有效時重放，所以門檻不低；但**沒有緩解措施，代表能做的只有升級**。 同一天，ISC 也公開另外三個 BIND 漏洞（CVE-2026-19630、CVE-2026-96888、CVE-2026-97313），依 ISC 各公告，CVSS 都是 7.5，都可能讓 BIND 消耗過多資源或停止運作（[CVE-2026-19630](https://kb.isc.org/docs/cve-2026-19630)、[CVE-2026-96888](https://kb.isc.org/docs/cve-2026-96888)、[CVE-2026-97313](https://kb.isc.org/docs/cve-2026-97313)；另見[加拿大網路安全中心 AV26-1072](https://www.cyber.gc.ca/en/alerts-advisories/isc-bind-security-advisory-av26-1072)）。升到 9.20.30 會一次處理這四個問題。 --- ## 二、你有沒有用到 BIND？先分三類 大部分中小企業不是 BIND 使用者，但「不是」要查過才算。 | 你的狀況 | 有沒有在跑 BIND | 你要做的事 | | --- | --- | --- | | 網域 DNS 交給主機商、網域註冊商或 Cloudflare 等代管服務 | 你沒有自己跑 | 請服務商確認處理狀況，不需要自己升級 | | 公司有 Linux 伺服器跑 `named`，或 IT 外包商替你架了內部 DNS | 有 | 照第四節查版本並升級 | | 用 Samba 架網域控制站，並搭配 BIND 提供 DNS | 有，而且通常會用到 GSS-TSIG | 優先處理 | | 用 Windows Server 網域控制站內建的 DNS | 沒有，Windows DNS 不是 BIND | 不在這次公告範圍，但 Windows 本身的更新仍要照常裝 | **判斷方法只要問一個問題：「公司的 DNS 伺服器是誰架的、裝在哪台機器上？」** 答案是「主機商」，就把問題轉給主機商；答案是「我們自己」或「外包工程師」，就要往下查。答不出來，代表這台機器可能多年沒人管，更要查。 --- ## 三、還在用 BIND 9.18？這次沒有修補版 這次公告列出 9.18.50 受影響，修補版本卻只有 9.20.30 與 9.21.27。原因是 **BIND 9.18 已在 2026 年 6 月停止支援**：ISC 在 [2026-06-23 的 bind-users 公告](https://lists.isc.org/pipermail/bind-users/2026-June/110654.html)說明 9.18.50 是最後一版，之後不再維護或修補，並建議使用者盡快升到 9.20。 這和 [PHP 8.1 以下拿不到 PHP2Shell 修補](/blog/php2shell-sme-website-check-patch)是同一件事：**停止支援不會讓系統立刻壞掉，而是下一個漏洞出現時，沒有修補可裝**。停在 9.18 的 DNS 伺服器，從這次公告起就是已知有漏洞、又沒有官方修補的狀態。軟體版本的保存期限，可以參考[PHP 版本更新為什麼重要](/blog/php-version-update-importance)的整理，道理相同。 唯一的例外是發行版套件。Ubuntu、Debian、RHEL 等發行版有自己的支援週期，可能把修補移植到它們提供的 9.18 套件。這要看各發行版的安全公告，不能假設已經修好，也不能假設一定沒修。 --- ## 四、5 步驟自查與修補 BIND ### 步驟 1：確認 BIND 版本與來源 在 DNS 伺服器上執行 `named -v`，看到的就是目前的 BIND 版本。同時確認 BIND 是怎麼裝的：用 `apt`、`dnf` 等發行版套件裝的，還是從 ISC 官方原始碼或 ISC 套件庫裝的。來源不同，下一步要看的公告也不同。 ### 步驟 2：對照正確的修補依據 - **ISC 官方版本**：版本低於 9.20.30（9.20 系列）或 9.21.27（9.21 系列），就要升級；9.18 以下要跨版本升到 9.20。 - **發行版套件**：版號不會照 ISC 的編號走，`named -v` 顯示 9.18.x 不代表沒修，是否已修要以發行版公告為準。要查該發行版針對 CVE-2026-94300 的安全公告（例如 Ubuntu 的 USN、Debian 的 DSA、Red Hat 的 RHSA），確認修補套件的版本。 ### 步驟 3：升級並重啟 named 升級前先備份設定檔（通常是 `named.conf` 與區域檔）。升級後要**重啟 named 服務**，只更新套件但沒重啟，跑的仍是舊程式。重啟後再執行一次 `named -v`，並用 `dig` 查幾筆公司網域，確認解析正常。 ### 步驟 4：檢查 GSS-TSIG 與動態更新設定 在設定檔中找 `tkey-gssapi-keytab`、`tkey-gssapi-credential` 或 `update-policy` 裡的 Kerberos 規則，確認哪些伺服器有啟用 GSS-TSIG 動態更新。這不是用來決定要不要升級（答案都是要），而是用來排優先順序：**有啟用的機器先升，並確認只有內部網路能送動態更新到這台伺服器**。 ### 步驟 5：排好每月更新與 9.18 的退場日期 ISC 在同一則 [9.18 停止支援公告](https://lists.isc.org/pipermail/bind-users/2026-June/110654.html)中建議使用者調整流程，盡可能每月更新 BIND。把 DNS 伺服器加進每月的修補清單；還在 9.18 的機器，訂好升到 9.20 或改用代管服務的日期，並指定負責人。 --- ## 五、要繼續自己架 DNS，還是改用代管？ 這次漏洞也是重新檢視架構的時機。對外網域的 DNS 和內部網路的 DNS，判斷不一樣： | 用途 | 建議做法 | 理由 | | --- | --- | --- | | 對外網域（官網、Email 的 DNS 紀錄） | 優先交給代管 DNS 服務 | 服務商負責修補與備援，你不必每月追 BIND 更新 | | 內部網域控制站（Samba AD、內部主機名稱） | 保留自架，但列入每月修補 | 內部系統依賴它，不易外移；重點是有人負責更新 | | 多年沒人碰、不知道誰架的 DNS 伺服器 | 先盤點用途，能移就移，不能移就升級並指定負責人 | 沒人管的伺服器，就是下一個事故 | **判斷方法：「下次 BIND 再出高風險漏洞，誰會在一週內幫我升級？」** 答不出來，就代表這台 DNS 伺服器需要換人管，或換架構。[Zeabur 結束營運的事件](/blog/zeabur-shutdown-security-incident-enterprise-lessons)也提醒同一件事：基礎設施要事先指定誰負責，不能等出事才找人。 --- ## 六、不確定公司的 DNS 是誰在管？ 如果你不確定公司網域的 DNS 放在哪裡、內部有沒有自架 BIND，或外包商是否已經升級，歡迎[填寫諮詢表單](/contact)。請在表單留下公司網域與目前的 IT 維護單位，我們會先盤點 DNS 架在哪裡、版本與負責人，再建議升級、改用代管或整併哪一條路最省事。 **驗收標準**：讀完本文後，你應該能回答三個問題——公司的 DNS 由誰架設與維護、目前的 BIND 版本是否已修補 CVE-2026-94300、9.18 的機器在哪一天前退場。三題都有答案，這次漏洞就處理完了。 --- **參考來源** - ISC，〈CVE-2026-94300: Concurrent GSS-TSIG messages corrupt memory〉，2026-10-21：https://kb.isc.org/docs/cve-2026-94300 - 加拿大網路安全中心，〈ISC BIND security advisory (AV26-1072)〉，2026-10-21：https://www.cyber.gc.ca/en/alerts-advisories/isc-bind-security-advisory-av26-1072 - ISC bind-users 郵件列表，〈BIND 9.18 is now END of LIFE, bind-esv repos are changing〉，2026-06-23：https://lists.isc.org/pipermail/bind-users/2026-June/110654.html - ISC，CVE-2026-19630、CVE-2026-96888、CVE-2026-97313 公告，2026-10-21：https://kb.isc.org/docs/cve-2026-19630 、https://kb.isc.org/docs/cve-2026-96888 、https://kb.isc.org/docs/cve-2026-97313 --- ## 相關推薦與延伸閱讀 - [PHP2Shell 漏洞自查與修補：中小企業官網今天就要做的 5 件事](/blog/php2shell-sme-website-check-patch)：PHP2Shell 是 PHP 官方 2026 年 10 月 21 日修補的兩個核心漏洞，不用登入就可能被遠端接管伺服器。官網用 WordPress 或虛擬主機 - [Cloudflare 推出代理就緒度分數：用四大維度檢查你的網站對 AI Agent 是否準備好](/blog/cloudflare-agent-readiness-score-guide)：Cloudflare isitagentready.com 用四大維度替網站的 AI agent 就緒度打分。本文解析評分邏輯與官方歷史樣本，說明採用率為何不等 - [Cloudflare AI Gateway 免費層：替 AI API 加上觀測與成本護欄](/blog/cloudflare-ai-gateway-free-observability)：用 Cloudflare AI Gateway 的免費核心功能集中管理 AI 請求，實作 logging、cache、rate limiting 與 GEO 查