CoreDNS 自訂傳輸層繞過驗證，恐當機或遭竄改記錄
GitHub Security Advisory · 2026-09-17
CoreDNS 的 DoH、DoH3、DoQ 與 gRPC 這四種自訂傳輸層，長期繞過了標準 UDP／TCP 監聽器原本套用的封包驗證函式，讓未經任何身分驗證的請求就能觸發記憶體耗盡，或是把偽造的 UPDATE 指令轉發給上游 DNS 伺服器竄改紀錄。CoreDNS 專案於 2026 年 9 月 17 日同時發布兩份公告 GHSA-mrg3-qvqr-jw29（CVE-2026-82399）與 GHSA-9gm5-9rfh-m6vx（CVE-2026-86003），CVSS 皆為 7.5，修補版本統一為 v1.14.7。
漏洞機制
問題出在解析順序。標準 UDP／TCP 伺服器（底層用 miekg/dns）在真正解析封包前，會先用 dns.DefaultMsgAcceptFunc 檢查固定 12 位元組表頭：只允許 QDCOUNT 剛好為一，其餘區段數也有上限，不合規就直接拒絕。但 CoreDNS 自己實作的 DoH/DoH3 解碼器、DoQ 串流處理與 gRPC 查詢處理，全部直接呼叫 dns.Msg.Unpack，略過了這一層檢查。
第一個漏洞（CVE-2026-82399）的攻擊者利用 DNS 名稱壓縮技巧，讓一個 65,533 位元組的請求在展開後配置超過 10 MiB 記憶體；由於解析發生在 plugin chain 之前，外掛層級的流量限制完全攔不住這波配置，同時送出多筆這類請求就能把 CoreDNS 記憶體耗盡到程序被系統終止。
第二個漏洞（CVE-2026-86003）則是同一個缺口的另一種利用方式：CoreDNS 只看訊息裡的 Zone 問題來路由，並未檢查 opcode，於是 RFC 2136 的 UPDATE 訊息（opcode 5）也能通過這四種傳輸層，被 forward/proxy 外掛原封不動轉發給上游伺服器。只要上游只信任 CoreDNS 的來源位址或連線本身、而非要求端對端 TSIG 簽章，攻擊者就能借道 CoreDNS 新增、替換或刪除上游的 DNS 紀錄，完全不需要通過任何驗證。
兩份公告都附上可重現的概念性驗證程式：CVE-2026-82399 的 PoC 針對 CoreDNS v1.14.6 起的 DoH 伺服器，在設有記憶體限制的 Docker 容器內重現配置暴增到程序被砍掉的過程；CVE-2026-86003 的 PoC 則另外啟動一個標準函式庫寫成的模擬上游 DNS 服務，驗證一筆未經 TSIG 簽章的 UPDATE 訊息，經由 DoH 送進 CoreDNS 後，會被 forward 外掛原封不動轉送到那個模擬上游並寫入紀錄。這代表兩個漏洞都不是理論推導，而是有實測可重現的攻擊路徑。
| 項目 | CVE-2026-82399 | CVE-2026-86003 |
|---|---|---|
| CVSS 3.1 | 7.5（C:N/I:N/A:H） | 7.5（C:N/I:H/A:N） |
| 影響 | 記憶體耗盡、程序終止 | 上游 DNS 紀錄遭新增／竄改／刪除 |
| 受影響傳輸層 | DoH、DoH3、DoQ、gRPC | DoH、DoH3、DoQ、gRPC |
| 是否需要驗證 | 否 | 否（另需上游不驗 TSIG） |
兩者的根因寫法幾乎一致，可以用下面的簡化流程對照：
// 修補前：自訂傳輸層直接解封包
msg := new(dns.Msg)
msg.Unpack(rawBytes) // 沒有表頭檢查，任何 opcode／區段數都放行
// 修補後：套用與 UDP/TCP 相同的請求政策
if _, err := dnsutil.UnpackRequest(rawBytes); err != nil {
return errReject // 先跑 dns.DefaultMsgAcceptFunc 同等檢查
}
msg := new(dns.Msg)
msg.Unpack(rawBytes)受影響版本
兩份公告的受影響範圍與修補版本完全相同：github.com/coredns/coredns（Go module）<= 1.14.6 皆受影響，修補版本為 1.14.7。修補提交為 530b0a5ff2ad68cc0421f10dd93568945cc671c9，對應 release 為 v1.14.7。
值得注意的是攻擊面的前提：這兩個漏洞只打得到有開啟 DoH、DoH3、DoQ 或 gRPC 這些非傳統傳輸層的部署。多數 Kubernetes 叢集透過 kubeadm 或 CNI 安裝的預設 Corefile，通常只在 53 埠監聽標準 UDP／TCP，不會自動開啟這幾種擴充協定；但只要維運者為了服務網格、內部 DoH 閘道或 gRPC DNS API 而額外加了對應的 server block，就落在受影響範圍內，而且攻擊者不需要任何認證即可觸發。
修補與緩解
最直接的做法是把 CoreDNS 升級到 1.14.7 或更新版本。自架 CoreDNS 的維運者（包含許多自建 Kubernetes 叢集直接管理 coredns deployment 映像檔的團隊）可以直接替換映像檔版本；使用受管 Kubernetes 服務、CoreDNS 由雲端供應商代管的使用者，則需要等供應商推送更新後的映像檔，短期內無法自行修補二進位檔。
在等待升級的期間，若叢集確實開啟了 DoH/DoH3/DoQ/gRPC 監聽器，可以先評估是否能暫時關閉這些非必要的傳輸層 server block，回退到標準 UDP／TCP；若上游支援 RFC 2136 的 UPDATE，也應該確認上游有要求端對端 TSIG 簽章，而不是只靠信任 CoreDNS 的來源位址或連線本身。