Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain local unprivileged shell
-
DeliveryCreate user namespace via unshare(CLONE_NEWUSER)
-
ExploitClone mount tree with open_tree(OPEN_TREE_NAMESPACE)
-
Executionsetns into the unlocked namespace copy
-
ImpactRead previously masked files
Vulnerability Assessment
| Exploitation Conditions | Requires local access as an unprivileged user on a kernel that permits unprivileged user-namespace creation (unshare(CLONE_NEWUSER)); the attacker then uses open_tree with OPEN_TREE_NAMESPACE. Disclosure is only meaningful where a directory has something mounted over it to hide content - specifically the covered/overmounted masking that container runtimes apply to parts of /proc and /sys, or that admins use to hide paths. Limiting factors: no remote vector (AV:L); it yields nothing on systems without such covering mounts; a caller already privileged over the source mount namespace sees no change; and hosts that disable unprivileged user namespaces remove the unprivileged path entirely. |
| Impact | The input CVSS of 8.8 (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) overstates this flaw: the description, the CWE-less 'Information Disclosure' tag, and the mechanism all indicate a pure confidentiality issue - open_tree(OPEN_TREE_NAMESPACE) copying a mount tree without the locking that unshare()/copy_mnt_ns() applies, so content previously hidden by covered (overmounted) directories becomes readable. There is no evidence of integrity or availability loss, so the I:H/A:H components appear inflated and should be treated as C-only. The attack is strictly local (AV:L) and requires an unprivileged user to first create a user namespace, i.e. a real local foothold, matching PR:L. Exploitation-likelihood signals are low and consistent with each other: EPSS 0.20% (9th percentile), no CISA KEV listing, and no public exploit referenced. The vendor priority label is 'this_week' and a fix is available via two stable-kernel commits, so this warrants scheduled patching rather than emergency response. The practical risk is concentrated in multi-tenant/container hosts where runtimes rely on covering mounts to mask parts of /proc and /sys - there the disclosure can defeat an intended isolation control. |
| Exploit ScenarioDerived | On a shared container or multi-tenant Linux host, a local unprivileged user creates a user namespace and then calls open_tree(path, OPEN_TREE_NAMESPACE) to clone a mount tree; because the copy is not locked the way unshare() locks it, directories that a runtime or admin had masked with an overmount are revealed, and the user reads the files underneath (e.g. masked /proc or /sys entries). No cataloged public exploit exists, but the CVE description itself embeds a minimal reproducer demonstrating the read of a 'hidden' file. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 24, 2026
Linux kernels that allow unprivileged user-namespace creation let a local low-privileged user read file content that covering (over-mounted) directories were intended to hide, by calling open_tree() with OPEN_TREE_NAMESPACE and then setns() into the resulting mount namespace. The flaw matters most on hosts running container runtimes that mask parts of /proc and /sys with mounts, or where administrators hide paths behind mounts; systems without such covering mounts, or that disable unprivileged user namespaces, are not exposed through this path. There is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis, with EPSS at 0.20% (9th percentile); vendor fixes are available as upstream stable commits, so patching this week is appropriate.
RemediationAI
Vendor-released patch is available: apply the upstream stable fixes at https://git.kernel.org/stable/c/b8a94a405ddcf45e9470789e0a821d8f2aa4ca10 and https://git.kernel.org/stable/c/0febe278ec45b1ccdbe9bd5ff1ba365d8fd55e2a, or update to the kernel versions carrying them (EUVD version data references the 7.2.11 and 7.3 points), then reboot into the fixed kernel since this is core mount-namespace code. Where patching must wait, the effective compensating control is removing the unprivileged trigger: set kernel.unprivileged_userns_clone=0 on Debian-derived kernels or user.max_user_namespaces=0, which eliminates the unprivileged path but breaks rootless containers, unprivileged sandboxes (bubblewrap, Flatpak, some browsers) and similar tooling, so scope it carefully. These settings do nothing for a privileged local caller, who sees no behaviour change from the fix anyway; hosts without covering mounts over sensitive paths gain no practical exposure from this flaw, and containers relying on mounted-over /proc and /sys masks should be treated as the priority assets.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
open_tree(2) with the OPEN_TREE_NAMESPACE flag builds a new mount namespace from a copy of the mount tree at a given path. The caller must hold privileges over its own user namespace (because the new mount namespace is owned by it) but not over the mount namespace it copies from, so an unprivileged user only has to create a user namespace first. The copy is performed with detached-bind-mount semantics: without AT_RECURSIVE only the mount at the path is cloned and its children are omitted, and with AT_RECURSIVE unbindable mounts are skipped. That is acceptable for a caller privileged over the source namespace, who could unmount those mounts anyway, but not for an unprivileged caller - for them the equivalent operation is unshare(), where copy_mnt_ns() copies every mount including unbindable ones and lock_mnt_tree() makes the copy immutable so nothing covered is revealed. In the OPEN_TREE_NAMESPACE path create_new_namespace() performs only the locking, with the result that content sitting beneath a covering mount is directly reachable in the new namespace (demonstrated by opening /covered/under.txt after mount -t tmpfs over /tmp/otn/covered). No CWE was supplied in the source data; the mechanism is an isolation failure that yields confidentiality loss only, which is why our assessed vector is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N rather than the input 8.8 score that also claims high integrity and availability impact.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Local unprivileged user-namespace syscall path (AV:L/PR:L/AC:L), crossing an isolation boundary to read masked content (S:C, C:H); no integrity or availability impact, so I:N/A:N.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
4DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
namespace: keep covered mounts covered in OPEN_TREE_NAMESPACE
open_tree(OPEN_TREE_NAMESPACE) creates a new mount namespace from a copy of the tree at the given path. The caller needs to be privileged over its current user namespace because the new mount namespace will be owned by it. It doesn't need to be privileged over the mount namespace the tree is copied from. An unprivileged user just needs to create a user namespace first.
The copy follows the rules of a detached bind mount. Without AT_RECURSIVE only the mount itself is cloned and its children are left out. With AT_RECURSIVE unbindable mounts are skipped. Both is fine when the caller has privileges over the source mount namespace because it could unmount those mounts anyway. Not so for an unprivileged user in that mount namespace. For them a mount namespace copy is what unshare() does. copy_mnt_ns() copies everything including unbindable mounts and lock_mnt_tree() makes sure nothing can be unmounted in the copy. Nothing that was covered gets revealed.
create_new_namespace() only does the locking and so the covered content is right there in the new mount namespace:
mount -t tmpfs none /tmp/otn; mkdir /tmp/otn/covered
echo hidden > /tmp/otn/covered/under.txt
mount -t tmpfs none /tmp/otn/covered
uid 1000, after unshare(CLONE_NEWUSER): fd = open_tree(AT_FDCWD, "/tmp/otn", OPEN_TREE_NAMESPACE); setns(fd, CLONE_NEWNS); open("/covered/under.txt", O_RDONLY) -> "hidden"
Covering paths with mounts is how container runtimes mask parts of /proc and /sys and how admins hide things.
When the caller's user namespace doesn't own the source mount namespace copy the way unshare() does and refuse a non-recursive copy of a mount that has anything mounted below the requested directory and copy unbindable mounts in a recursive copy. A caller that is privileged over the source mount namespace sees no change.
Executive ViewAI
A high-severity Linux kernel vulnerability (CVE-2026-98988) allows a local attacker with low privileges to bypass mount-based file hiding mechanisms, potentially exposing sensitive data masked by container runtimes or administrator-configured mounts. This affects organizations running containerized workloads or relying on over-mounts for data protection, especially where unprivileged user namespaces are enabled. While no active exploitation is currently observed, the ability to read supposedly hidden files could undermine container isolation and data confidentiality controls.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
EUVD-2026-108782
GHSA-6v5x-qw46-2jph
NVD
CVE.org
EPSS
Exploit-DB