CVE-2026-72054 patches a capability-gating gap in the kernel's VTI tunnel handling where the RTNL changelink authorization was validated against dev_net(dev) while the actual tunnel modification could mutate state in t->net — a spatial mismatch between where authorization occurs and where the operation takes effect. The vulnerability is an 8.8 CVSS but carries an EPSS score of only 0.00164, which reflects the significant existing access required to exploit it rather than reduced severity. For defenders, the practical risk is container escape: an attacker who already has non-privileged container access can use this to pivot across namespace boundaries, which is precisely the privilege class that matters in multi-tenant environments.
The fix — replacing the authorization check with rtnl_dev_link_net_capable() — is significant not because it's clever, but because it represents an admission that authorization must travel with the operation's actual scope. This matters beyond VTI. The same capability-checking mismatch has appeared in tun/tap, bridge, bonding, and other network device operations that inherently span two namespace contexts while gating on only one. Each instance has been found individually, but there's no systemic rule requiring cross-namespace capability checks when an operation can affect a namespace other than the caller's. The low EPSS score obscures the real threat model: this isn't a vulnerability you exploit remotely — it's a precision tool for lateral movement once you're inside the container boundary.
Audit your kernel for other tunnel types that may carry the same gap. vti6, ip6tnl, and older GRE variants predate modern namespace semantics and may have exited active development cycles where they'd receive security review. The question isn't whether VTI was the only instance — it's whether the kernel is systematically reverse-engineering its namespace authorization model from individual failure cases rather than codifying a rule that should have existed from the start.