CVE-2026-39402 in lxc
Summary
by MITRE • 05/06/2026
lxc is a Linux container runtime. In the setuid helper lxc-user-nic, the delete path contains a logic flaw in the find_line() function that allows an unprivileged user to delete OVS-attached network interfaces belonging to other users. When lxc-user-nic delete scans its NIC database to authorize a deletion request, the interface name comparison can set the authorization flag based on a name match alone, even when the ownership, type, and link fields in that database entry belong to a different user. The vulnerable check sits after the goto next label handling, meaning it is reachable on lines where earlier ownership checks failed or were skipped. Because nothing downstream of this authorization signal re-verifies that the matched database line actually belongs to the caller, an unprivileged attacker with a valid lxc-usernet policy entry can trigger deletion of another user's OVS port on the same bridge.
This is limited to multi-tenant environments using lxc-user-nic with OpenVSwitch bridges. The impact is denial of service - one tenant can repeatedly disconnect networking from containers run by another tenant on shared infrastructure. This is patched in version 7.0.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/08/2026
The lxc-user-nic component represents a critical security vulnerability within Linux container runtime environments, specifically affecting the setuid helper utility responsible for managing network interfaces. This flaw exists in the find_line() function where a logic error enables unauthorized users to manipulate network configurations belonging to other system tenants. The vulnerability stems from insufficient validation mechanisms during the interface deletion process, creating a pathway for privilege escalation through network interface manipulation. The flaw manifests when the delete operation scans the NIC database for authorization purposes, where interface name matching alone triggers authorization without proper verification of ownership attributes. This represents a classic case of inadequate input validation and authorization checks, aligning with CWE-284 access control vulnerabilities that permit unauthorized access to system resources.
The technical implementation of this vulnerability occurs within the lxc-user-nic delete functionality where database entry validation happens after a goto next label handling mechanism. This programming construct creates a scenario where authorization flags can be incorrectly set based on name matches alone, regardless of whether the database entry actually belongs to the requesting user. The authorization check occurs in a code path that bypasses proper ownership verification, meaning that even when earlier validation checks fail or are skipped, the subsequent name comparison can still grant access. This logical flaw creates a race condition between validation and execution, where the authorization signal is set without proper downstream re-verification. The vulnerability is particularly dangerous because it operates within a privileged context, leveraging the setuid nature of the helper utility to execute unauthorized operations.
The operational impact of this vulnerability extends beyond simple privilege escalation to create significant denial of service conditions in multi-tenant container environments. An unprivileged attacker with valid lxc-usernet policy entries can repeatedly disrupt networking connectivity for containers belonging to other users on the same shared infrastructure. This creates a persistent threat where one tenant can systematically disable network access for another tenant's containers, effectively compromising the isolation guarantees that multi-tenant systems rely upon. The vulnerability's exploitation requires minimal privileges but can cause substantial operational disruption, making it particularly dangerous in production environments where containerized applications depend on stable network connectivity. The impact is amplified in cloud and infrastructure-as-a-service deployments where multiple customers share the same underlying hardware resources.
Mitigation strategies for this vulnerability focus on patching the affected lxc versions to 7.0.0 or later, which addresses the core logic flaw in the find_line() function. Organizations should also implement additional network isolation measures, including restricting access to lxc-user-nic utilities and monitoring for unauthorized network configuration changes. The vulnerability highlights the importance of proper authorization validation in setuid applications and demonstrates why security-conscious development practices are essential for privileged system components. System administrators should review and tighten lxc-usernet policy configurations to limit the scope of operations that unprivileged users can perform, while also implementing network monitoring to detect anomalous interface deletion patterns. This vulnerability aligns with ATT&CK techniques related to privilege escalation and defense evasion, emphasizing the need for comprehensive security controls that address both the immediate vulnerability and broader system hardening requirements.