在Linux 或 WSL 環境中，透過建立兩個模擬主機node1與node2來建立底層的路由網路，在上面建立 VXLAN 介面 掛載至Bridge，實現跨主機的 Layer 2 Overlay ，就是兩個L2的Bridge打隧道串起來，VXLAN 是一種MAC-in-UDP的隧道機制，開一條UDP隧道，跟L2一樣IP對MAC
很疑惑，九月寫十月就被開採，是有人看了這篇那個模擬注入的腳本去開採了CVE2026-92542
更新到Docker Engine 29.8.2 透過引入 Linux iptables 的 socket 模組（xt_socket）來修補此漏洞，藉此精準區分「Kernel 原生封裝的流量」與「User-space 應用程式偽造的流量」。
在 Linux 網路堆疊中，由使用者空間（如 Python 腳本或本地 Socket 行程）發出的封包，在核心中會帶有明確的 Socket 結構關聯；而由 Kernel 內部的虛擬網路介面（如 Docker Swarm 建立的 vxlan 介面）進行 L2 二次封裝後發出的底層封包，則不屬於任何特定的 User-space Socket。
以下是修補前後在 iptables mangle 表 OUTPUT 鏈中的具體規則差異：
修補前（受影響版本）的寬鬆規則
在存在漏洞的舊版 Docker Engine 中，防火牆規則僅單純匹配協定與連接埠：# 只要是送往 UDP 4789 埠的封包，一律打上 IPsec 加密標記 (fwmark)
iptables -t mangle -A OUTPUT -p udp --dport 4789 -j MARK --set-xmark 0x1234
這種「無差別標記」導致主機上的非特權行程只要向外送出特製的 UDP 封包，就會被該規則捕捉，隨後被本機的 XFRM 子系統無條件套用 ESP 加密。
修補後（29.8.2）的嚴格規則
修補後的版本利用 -m socket（或 ! -m socket 反向匹配）來修補來源身分的驗證缺口。Docker 會加入排除條件，確保只有核心本身發出的 VXLAN 流量才會被加密：# 做法 1：新增前置規則，若封包有關聯的本地 User-space Socket，則直接跳出（RETURN），不予標記
iptables -t mangle -A OUTPUT -p udp --dport 4789 -m socket -j RETURN
# 做法 2：直接在加密標記規則中，排除帶有 Socket Context 的來源
iptables -t mangle -A OUTPUT -p udp --dport 4789 ! -m socket -j MARK --set-xmark 0x1234
防禦生效的底層機制
加入 ! -m socket 條件後，當攻擊者執行稍早討論的 Socket 注入腳本時，核心防火牆會比對出該封包源自一個活躍的本地 Socket 行程。因為不符合標記條件，該封包無法獲得觸發加密所需的 fwmark。失去這個標記後，偽造的 VXLAN 封包就會以「明文 UDP」的型態離開主機網卡。當它抵達目標節點時，接收端的 IPsec 策略資料庫（Security Policy Database, SPD）預期該網段的 VXLAN 流量必須受到 ESP 加密保護；面對這個未加密的明文 UDP 4789 封包，接收端的核心會直接將其丟棄（Drop），從而徹底粉碎了這條注入攻擊鏈。
