# CVE-2026-39402: lxc lxc-user-nic insufficient ownership validation allows cross-tenant OVS port deletion

> An unprivileged user can delete network interfaces belonging to other users in multi-tenant LXC environments using OpenVSwitch, causing denial of service.

- **Severity:** Medium 4.3 (`CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:N/SI:N/SA:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 5 May 2026
- **Updated:** 6 May 2026
- **Also known as:** DEBIAN-CVE-2026-39402, GHSA-3m9j-g9gc-vcvq, MGASA-2026-0172, OESA-2026-2657, UBUNTU-CVE-2026-39402, openSUSE-SU-2026:10678-1

## What is CVE-2026-39402?

CVE-2026-39402 is a medium-severity missing authorization vulnerability in lxc, published on 5 May 2026. It can only be exploited from the same machine or local network, with no action from the victim.

### Official description

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.

Weakness: CWE-863 (Incorrect Authorization)

## Which versions are affected by CVE-2026-39402?

It affects 1 product.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `lxc` | openSUSE:Tumbleweed | All versions | 7.0.0-1.1 |

Products: Linuxcontainers Lxc.

## How do I fix CVE-2026-39402?

Upgrade to a fixed version.

## Is CVE-2026-39402 being exploited?

It is not confirmed as exploited in the wild, but public exploit code for CVE-2026-39402 exists.

## Other vulnerabilities in lxc

- [CVE-2016-8649](https://insights.sbomify.com/CVE-2016-8649/): Path traversal in LXC before 1.0.9 and 2.x before 2.0.6 (critical 9.1)
- [CVE-2016-10124](https://insights.sbomify.com/CVE-2016-10124/): Privilege escalation in n/a (high 8.6)
- [CVE-2017-18641](https://insights.sbomify.com/CVE-2017-18641/): Supply chain in n/a (high 8.1)
- [CVE-2013-6441](https://insights.sbomify.com/CVE-2013-6441/): Privilege escalation in n/a (high 7.2)
- [CVE-2015-1331](https://insights.sbomify.com/CVE-2015-1331/): Path traversal in n/a (medium 4.9)

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-39402 and fix it if it is affected.

What it is: CVE-2026-39402 is a medium-severity missing authorization vulnerability in lxc, published on 5 May 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: It is not confirmed as exploited in the wild, but public exploit code for CVE-2026-39402 exists.

Affected product: lxc. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-39402/ (Markdown: https://insights.sbomify.com/CVE-2026-39402/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-39402
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-39402
- OSV: https://osv.dev/vulnerability/CVE-2026-39402

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-39402/
Summaries are generated and may contain mistakes; the official description above is the record.