CVE-2026-31692

What it actually does

CVE-2026-31692 is a Linux kernel rtnetlink authorization flaw in rtnl_newlink(). When creating paired network devices such as veth, vxcan, or netkit, the kernel failed to verify that the caller had CAP_NET_ADMIN in the target peer network namespace. A local unprivileged user who can create or enter a user namespace may gain CAP_NET_ADMIN only inside that user namespace, then use netlink to create network interfaces inside another namespace, including the initial host network namespace. This can allow unauthorized network namespace manipulation and may be used to disrupt host or container networking, create unexpected interfaces, interfere with routing or filtering assumptions, or serve as a container/namespace isolation bypass primitive. The assigned impact is primarily local availability impact, with low attack complexity and no user interaction required.

Why it matters to the business

Systems that allow unprivileged user namespaces, container workloads, build sandboxes, CI runners, or multi-user Linux access may be exposed to unauthorized manipulation of network namespaces. The most likely business impact is service disruption from unexpected network interfaces or namespace state changes, especially on container hosts, Kubernetes nodes, shared compute platforms, and developer infrastructure. This vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no reported public exploit maturity, so it is lower urgency than actively exploited kernel flaws; however, it should still be remediated through normal kernel update cycles because local namespace bugs are often chained with other issues.

How an attack unfolds

An attacker first obtains local code execution as a low-privileged user on a vulnerable Linux system, or runs code inside a container or sandbox where user namespaces are available. The attacker creates or uses a user namespace where they appear to hold CAP_NET_ADMIN. They then open a netlink socket and send an RTM_NEWLINK request to create a paired network device type such as veth, vxcan, or netkit. By supplying a peer network namespace attribute, such as a namespace file descriptor or namespace identifier, the attacker targets a namespace where they do not actually have CAP_NET_ADMIN, potentially the host initial network namespace. Because the vulnerable kernel checks capability in the caller context but not correctly in the peer namespace, the kernel creates the peer interface in the unauthorized namespace. The attacker can repeat this to populate namespaces with unexpected interfaces, disrupt networking, influence namespace topology, or build a stepping stone for broader container-host isolation bypass techniques. Successful exploitation requires local access and user namespace capability; it is not a remote network attack by itself.

How to fix it

Upgrade to a Linux kernel build that includes the upstream rtnetlink fix adding netlink_ns_capable() validation for CAP_NET_ADMIN in the peer network namespace. Use vendor-supported kernel packages from the relevant Linux distribution, cloud image, appliance vendor, or container host platform. No exact fixed package versions were provided in the input, so consult the applicable vendor advisory for the corrected kernel version and reboot into the updated kernel after installation. As mitigation until patching is complete, restrict unprivileged user namespace creation where operationally feasible, limit local shell access, avoid running untrusted workloads on shared hosts, harden container runtime profiles, and reduce CAP_NET_ADMIN exposure in containers and sandboxes. Consider disabling or constraining workloads that can create user namespaces on high-risk multi-tenant systems.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated by checking the active kernel version after reboot. Validate against vendor advisories or kernel changelogs for the rtnetlink fix that adds the missing netlink_ns_capable() peer namespace CAP_NET_ADMIN check. On container hosts and multi-user systems, verify whether unprivileged user namespaces are enabled and whether untrusted workloads can open network namespaces or create virtual network devices. Exposure validation should include testing that an unprivileged user with only user-namespace-scoped privileges cannot create veth, vxcan, or netkit peer interfaces in a namespace where they lack CAP_NET_ADMIN. Also inventory hosts that run containers, CI jobs, developer shells, or sandboxed workloads, because those are the most relevant exposure points.

Typical attack path

1. Gain local execution as an unprivileged user, container process, sandboxed workload, or CI job on a vulnerable Linux kernel.
2. Create or enter a user namespace where the process has namespace-scoped CAP_NET_ADMIN.
3. Identify or obtain a handle to a target peer network namespace, potentially including the initial host network namespace.
4. Send an rtnetlink RTM_NEWLINK request to create a paired device such as veth, vxcan, or netkit with peer namespace attributes.
5. Exploit the missing CAP_NET_ADMIN check in the peer namespace so the kernel creates an interface where the attacker lacks authorization.
6. Use the unauthorized interface creation to disrupt networking, alter namespace assumptions, or support further container/namespace escape activity.

How to detect it

Look for evidence of unexpected network interface creation by low-privileged users, containers, CI jobs, or sandboxed processes. Relevant data sources include Linux auditd logs, eBPF runtime security telemetry, container runtime logs, Kubernetes node logs, systemd-journald, kernel messages, EDR process telemetry, and network interface inventory changes. Focus on RTM_NEWLINK netlink activity that creates veth, vxcan, or netkit devices with peer namespace attributes from processes that should not administer the target namespace. Investigate interface names that do not match expected container runtime patterns, sudden growth in veth devices, veth peers appearing in the host namespace without a corresponding container lifecycle event, or interface creation by shells, scripting runtimes, build tools, or unknown binaries. For forensic review, correlate timestamps of new interface creation with process execution, user namespace creation, container start/exec events, and namespace file descriptor access under /proc/*/ns/net. There are no known public exploit-specific payload strings or threat actors associated with this CVE in the provided intelligence, so detection should be behavior-based rather than signature-only.

• RTM_NEWLINK
• IFLA_NET_NS_FD
• IFLA_NET_NS_PID
• IFLA_LINK_NETNSID
• IFLA_LINKINFO
• IFLA_INFO_KIND=veth
• IFLA_INFO_KIND=vxcan
• IFLA_INFO_KIND=netkit
• ip link add type veth
• ip link add type vxcan
• ip link add type netkit
• /proc/self/ns/net
• /proc/1/ns/net
• /proc/*/ns/net
• setns
• unshare -U
• unshare --user
• unshare --net
• veth
• vxcan
• netkit

What your security team should do

• Prioritize patching Linux kernels on container hosts, Kubernetes nodes, CI runners, shared shell servers, developer workstations used for untrusted code, and other multi-tenant Linux systems.
• Reboot systems after kernel package updates and verify the active running kernel includes the vendor fix.
• Temporarily restrict unprivileged user namespaces where business-compatible, for example through distribution sysctl controls or host hardening policies.
• Review container and sandbox configurations to avoid granting CAP_NET_ADMIN unless strictly required.
• Monitor for unexpected creation of veth, vxcan, or netkit interfaces, especially in the host network namespace or outside expected container runtime activity.
• Enable audit or eBPF-based telemetry for rtnetlink RTM_NEWLINK activity on high-risk hosts if feasible.
• Treat suspicious network namespace manipulation as a possible local exploitation or container-escape precursor and investigate the originating user, process tree, container, and workload image.
• Because this issue is not currently KEV-listed and has low EPSS, schedule remediation through normal but timely kernel maintenance unless the system hosts untrusted local workloads, in which case accelerate patching.