Black Hat USA 2026 上獨立研究員 Malcolm Stagg 在 8 月 6 日公佈的 NatJack 是這輪議程裡影響面最廣的一個——不是特定廠商的實作漏洞，而是 NAT 這個協定家族自 RFC 定義起就寫死的信任假設出問題。研究團隊測了 32 個產品、95 種配置，包含 Linux Netfilter、Windows Hyper-V NAT、macOS、以及路由器、防火牆、雲端 NAT 閘道與容器平臺，全部在至少一種攻擊路徑下失守。Linux 這條線拿到 CVE-2026-63913（CVSS 8.2）、Windows 那條是 CVE-2026-56181（CVSS 8.3）、Cisco 跟 Apple 則直接表態不認定為漏洞。
問題不在程式碼寫錯，而在假設本身：「共用同一份 NAT 對映表的主機之間可以互相信任、不會惡意去動別人的連線狀態」。這個假設在 1994 年 RFC 1631 定義 NAT 時是合理的，當年家用網路裡蹲的都是自己的裝置。但 2026 年一份 NAT 對映表底下，可能同時坐著雲端多租戶的 VM、Kubernetes Pod、CI 執行器、共用 CGNAT 出口的無關住宅用戶，這種混編下的攻擊面已經跟三十年前完全不同。
NAT 對映表這件事，30 年來假設得太樂觀
NAT 的核心資料結構是 connection tracking table——每筆對外連線都會佔一個 5-tuple 條目：來源 IP、來源埠、目的 IP、目的埠、通訊協定。Linux 這條線的實作是 Netfilter 的 conntrack 模組，同樣的邏輯在 Windows、BSD、Cisco IOS、雲端 NAT 閘道裡各有一份，但演算法邏輯高度雷同。
conntrack 記的是每條連線該把回程封包轉譯回誰。任何能寫進這張表的操作——新增、修改、佔滿——都可能被拿來影響同表底下其他人的連線。NatJack 攻的就是這個介面：只要攻擊者能自己送出封包觸發 NAT 對映建立、又能推斷或控制對映的分配方式，就有機會在合法連線之上覆蓋、搶佔、或耗盡資源。
四條攻擊路徑
第一條是 TCP 連線劫持。攻擊者送出精心構造的封包，讓 NAT 把某個既存連線的對映條目換成攻擊者控制的內部端點。從此該連線後續回程封包會被轉到攻擊者身上。TLS 能擋內容外洩，但 TCP 層的中斷、reset、以及未加密路徑——沒走 HTTPS 的內網服務、明碼 SMTP、部份物聯網控制協定——會直接被讀取或改寫。
第二條是 DNS 汙染。攻擊者搶在受害者送出 DNS 查詢時去干預 NAT 對映，讓合法的 DNS 回應被導向攻擊者，攻擊者再送一份偽造回應回受害者。這是傳統 Kaminsky 攻擊的變種，差別在攻擊面在 NAT 層而非解析器層——就算解析器有 DNSSEC 驗證，受害端只要沒開 DoT/DoH 或不強制驗證，照樣中招。
第三條是 對外埠揭露。攻擊者可以查詢 NAT 表推斷其他租戶對外映射的埠號，這對於後續的目標式攻擊、fingerprint、以及 P2P 打洞繞過都是好用的前置。
第四條是最直接的 NAT 表耗盡 DoS。攻擊者用偽造流量塞滿對映表，讓合法客戶端無法建立新連線。雲端環境裡一個 NAT 閘道常常共享給整批 VM，一位租戶被打就全部人斷線。
Linux conntrack 修到什麼程度
CVE-2026-63913 是 Microsoft 為了保護 Azure Kubernetes Service 反向要求 upstream 修的。修好的 kernel 版本包含 5.10.259、5.15.210、6.1.176、6.6.143、6.12.93、6.18.35、7.0.12、7.1。翻查 changelog 可以看到修改集中在 conntrack 的 helper 邏輯以及 tuple 分配的隨機化——把攻擊者猜測、佔用對映條目的成本提高到不切實際。
要注意的是，這個 patch 不會把 NatJack 徹底堵死，因為根源在 RFC 層——只要 NAT 的信任模型維持不變，就永遠有下一組繞過方式。Synack 的通稿裡明確定調 patch 只是把攻擊難度拉高、不會關掉底層的設計空隙。對系統管理員來說，這是一個「打上 patch 但不能就此鬆手」的情境。
VPS、雲端與容器環境的暴露面
租一臺 VPS 的用戶最常忽略的一件事是，同一個 hypervisor 底下的鄰居租戶跟自己共用機房出口的 NAT 表。IaaS 的多租戶隔離做得再好，NAT 這一層是共享資源。惡意鄰居租戶只要能觸發足夠的連線建立，理論上就能對同機房其他 VM 打 NatJack 那組攻擊——這是 Malcolm Stagg 在 talk 裡點出的最尖銳情境。
Kubernetes 的暴露面更直接。iptables/nftables 模式的 kube-proxy 會在節點上維護大量 conntrack 條目，惡意 Pod 只要有辦法從節點對外送出流量，就能對同節點其他 Pod 動手。這也是 Microsoft 一路把 patch 推進 upstream 的原因——AKS 是這條路徑最典型的暴露場景，EKS 跟 GKE 邏輯上共用同一套 kernel 也逃不掉。
Docker 單機的情況相對輕，因為預設 bridge 網路的 NAT 只影響同主機容器。但只要跑了 socket 對外暴露的服務、或用了 Swarm、Compose 的多節點模式，攻擊面就會拉回上述情境。
CGNAT 這條路徑在原始通稿裡沒有明確定調，但邏輯上一定受影響——住宅寬頻的 CGNAT 出口對映表底下可能同時坐著幾千戶用戶，攻擊者只要拿到 ISP 這條路徑上的一個立足點，就能對同 CGNAT 池的其他用戶動手。這對在住宅網路後架服務、依賴埠對映的自架玩家是實際威脅，也是為什麼獨立 IPv4 位址在這波之後價值更明顯。
等不到根本修的期間該怎麼收
短期最有效的四個動作。第一，內網流量也一律加密。TLS、SSH、WireGuard 都能擋 TCP 劫持攻擊者讀寫內容，就算對映被搶了對方也只拿到密文。這也是為什麼 Zero Trust 那套 assume-breach 的思維在 NatJack 之後看起來更務實。
第二，DNS 走 DoT 或 DoH，且強制驗證。單純把解析器指到 1.1.1.1 或 8.8.8.8 沒用——路徑加密才擋得住 NatJack 的 DNS 汙染。搭配 DNSSEC 是最紮實的做法。
第三，限制單一租戶的最大 conntrack 條目數。Linux 上是 net.netfilter.nf_conntrack_max 加上 per-source hash limit，雲端 NAT 閘道通常也有對應設定。這能擋 NAT 表耗盡 DoS。研究團隊給的參考數字是每客戶端上限壓在一萬條以下。
第四，關掉 loose connection tracking。Linux 上是 net.netfilter.nf_conntrack_tcp_loose = 0。這個設定原本是為了讓 NAT 對 mid-stream 加入的封包也保持追蹤，但這也正是 NatJack 借力的機制之一。
有需要的話再把不受信任的租戶用 VLAN、VRF 或獨立 NAT 池切開——這是根治，但架構改動比較大，適合有明確合規需求或雲端多租戶服務商的情境。
RFC 級的設計缺陷該怎麼看
NatJack 揭穿的是「基礎設施協定裡看不見的預設信任」這個更大命題。BGP、DNS、NAT、ARP 都有類似結構——設計時預設一個受信任的封閉圈子，實際部署時把圈子拆開，攻擊面才浮現。BGP 的 RPKI、DNS 的 DNSSEC 走了 20 年才有意義的普及，NAT 這條線大概也是一樣的節奏。
務實的判斷是：接下來 12 到 24 個月會有更多繞過 patch 的變種被發表。認真跑生產服務的團隊值得把上面那組 mitigation 當標準組態一次上齊，並在網路架構層考慮把 NAT 依賴度往下壓——雙堆疊部署裡的 IPv6 走 end-to-end 就不需要 NAT，這在 NatJack 之後多了一個明確的資安動機。
自架服務跑在 VPS 上、又依賴機房共用 NAT 出口的架構值得重新評估。NCSE Network 在臺灣是方電訊機房提供 IPv4/IPv6 雙堆疊、獨立 IP 段的 IP Transit 服務，可依需求申請避開共用 NAT 池的獨立線路配置。前往 ncse.tw 了解 IP Transit 與 VPS 方案的細節。
