CVE-2026-63914

What it actually does

This Linux kernel flaw misroutes XFRM/IPsec migration notifications across network namespace boundaries. When an XFRM_MSG_MIGRATE or SADB_X_MIGRATE operation occurs in a non-initial network namespace, the kernel sends the multicast notification to listeners in the host initial network namespace instead of the namespace that initiated the migration. As a result, a local user or process able to trigger relevant XFRM migration activity may cause IPsec/IKE migration metadata from one namespace to be exposed to listeners in another namespace. The leaked data can include traffic selectors, old and new endpoint addresses, and key-management address information. The flaw can also break expected IKEv2 MOBIKE/address-update behavior inside non-initial namespaces because local IKE daemons may never receive their own migration notifications.

Why it matters to the business

Systems using Linux network namespaces with IPsec, XFRM, IKE, containerized VPN services, or namespace-isolated networking may experience unintended exposure of VPN/IPsec routing metadata between isolation boundaries. This can weaken tenant, container, or workload separation on shared hosts and may disrupt mobility or address-update handling for IPsec services running inside non-default namespaces. The vulnerability is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low EPSS score, so it is generally a lower-likelihood issue; however, it is still important for multi-tenant Linux hosts, container platforms, VPN gateways, and environments that rely on network namespaces as a security boundary.

How an attack unfolds

An attacker first needs local access to a vulnerable Linux system and enough privilege or capability to interact with the relevant network namespace and XFRM/IPsec migration paths. The attacker then positions a listener, such as an IKE or PF_KEY/XFRM netlink subscriber, in the initial network namespace or otherwise monitors migration notifications delivered there. When XFRM migration is triggered from another network namespace, the vulnerable kernel incorrectly multicasts the migration event to the initial namespace. The attacker can read metadata from the notification, including endpoint changes and selector information associated with IPsec state in another namespace. In parallel, the legitimate IKE daemon inside the non-initial namespace may fail to receive the event, potentially causing broken MOBIKE or address-update behavior and service disruption.

How to fix it

Upgrade to a Linux kernel version that includes the fix for routing XFRM and PF_KEY migrate notifications to the caller's network namespace rather than hardcoding the initial namespace. Because no exact fixed package versions were provided, obtain the corrected kernel from the relevant Linux distribution, appliance vendor, cloud image provider, or upstream stable kernel branch once available. Prioritize hosts that combine network namespaces with IPsec/XFRM, IKE daemons, containerized VPN components, Kubernetes/container networking, or multi-tenant workloads. If immediate patching is not possible, reduce exposure by limiting local shell/container access, restricting CAP_NET_ADMIN and other network-administration capabilities, avoiding untrusted workloads on hosts that run namespace-isolated IPsec services, and monitoring or disabling unnecessary IKE/PF_KEY/XFRM listeners in the initial namespace.

How to confirm the fix worked

Confirm the running kernel includes the vendor or upstream patch that removes the init_net override from the XFRM and PF_KEY migrate notification paths. Validate by checking the installed kernel package version against vendor advisories or by reviewing kernel source/build provenance for changes to xfrm_send_migrate(), pfkey_send_migrate(), km_migrate(), and the xfrm_mgr migrate callback path so that the caller's struct net is propagated. Operationally, test in a lab with at least two network namespaces: subscribe to XFRM/PF_KEY migrate notifications in both the initial and non-initial namespaces, trigger an XFRM migration from the non-initial namespace, and verify the notification is only received in the issuing namespace and not in init_net.

Typical attack path

1. Obtain local access to a vulnerable Linux host.
2. Identify whether the host uses network namespaces with XFRM/IPsec, IKE, PF_KEY, or MOBIKE/address-update functionality.
3. Run or control a listener subscribed to XFRMNLGRP_MIGRATE or PF_KEY broadcast events in the initial network namespace.
4. Wait for or trigger an XFRM migration event from a non-initial network namespace, if the attacker has sufficient capability.
5. Receive migration notifications that should have remained scoped to the originating namespace.
6. Extract exposed metadata such as traffic selectors, old and new endpoint addresses, and key-management address information.
7. Optionally use the missed in-namespace notification to cause or amplify IPsec mobility/address-update failures.

How to detect it

There is unlikely to be a definitive post-exploitation artifact because the flaw involves misdelivered kernel netlink/PF_KEY multicast notifications, which are not commonly logged by default. Review auditd, eBPF, endpoint telemetry, shell history, and process execution logs for local users or containers invoking IPsec/XFRM administration tools, creating privileged network namespaces, or subscribing to XFRM/PF_KEY migration events. Useful log sources include audit logs for CAP_NET_ADMIN use, process execution telemetry for ip/xfrm, setkey, strongSwan, libreswan, racoon, or custom netlink tools, container runtime logs showing privileged or host-network containers, and IKE daemon logs showing unexpected MOBIKE/address-update failures or migration events observed from the wrong namespace. Investigate unexpected XFRM_MSG_MIGRATE or SADB_X_MIGRATE activity, especially when it originates from non-initial namespaces but is observed by services in the initial namespace. Compare IKE daemon logs across namespaces: a suspicious pattern is an init-namespace daemon receiving migration notifications while the daemon inside the namespace that initiated migration records no corresponding event.

• XFRM_MSG_MIGRATE
• SADB_X_MIGRATE
• XFRMNLGRP_MIGRATE
• pfkey_send_migrate
• xfrm_send_migrate
• ip xfrm state
• ip xfrm policy
• setkey
• CAP_NET_ADMIN
• MOBIKE
• address update
• migration notification

What your security team should do

• Inventory Linux hosts that use network namespaces together with IPsec, XFRM, IKE, PF_KEY, MOBIKE, containerized VPNs, or multi-tenant networking.
• Prioritize kernel updates on shared, multi-tenant, container-hosting, VPN gateway, and network-appliance systems.
• Track distribution and vendor advisories for the fixed kernel version because exact fixed package versions were not provided in the input.
• Restrict CAP_NET_ADMIN and privileged container execution to trusted administrators and workloads.
• Review whether any IKE daemons or custom XFRM/PF_KEY listeners run in the initial network namespace where they could receive cross-namespace migration notifications.
• Add monitoring for unexpected XFRM migration activity and namespace-related network administration actions on sensitive hosts.
• Where patching is delayed, avoid co-locating untrusted workloads with namespace-isolated IPsec/VPN services.