Cloudanix VulnDB

CVE-2026-63833

High · 7.1

CVSS

7.1

EPSS

0.1%

Published

Jul 19, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A local user may be able to turn a writable Windows-formatted drive mounted on Linux into a path to full administrator control of the machine.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Privilege Gain
Component
OS kernel
Class
Privilege Escalation
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

This is a local privilege escalation vulnerability in the Linux kernel ntfs3 filesystem driver. ntfs3 stores Windows Subsystem for Linux permission metadata in reserved extended attributes named $LXUID, $LXGID, $LXMOD, and $LXDEV. On a writable ntfs3 mount, an unprivileged file owner could directly set these reserved attributes through normal userspace extended-attribute APIs. After the inode metadata was reloaded, ntfs3 could interpret attacker-controlled values as trusted ownership and mode metadata, allowing a user-owned file to be treated as root-owned and setuid. If executed under permissive mount options, this can allow the local user to gain effective UID 0 privileges.

Why it matters to the business

Systems that allow untrusted or lower-privileged users to write to ntfs3-mounted NTFS volumes may be at risk of local root compromise. The primary operational consequence is privilege escalation after an attacker has already obtained local access, which can lead to full host takeover, tampering with files and services, credential theft, persistence, and lateral movement. Risk is highest on multi-user Linux systems, developer workstations, shared servers, build hosts, kiosks, or environments that mount NTFS volumes read-write without nosuid/noexec protections. The vulnerability is recently published, has low EPSS at this time, is not listed in CISA KEV, and has no reported exploit maturity in the provided data, but local privilege escalation flaws can become useful post-compromise primitives once public exploit techniques emerge.

How an attack unfolds

An attacker first needs local, low-privileged access to a Linux system with a writable NTFS volume mounted through the ntfs3 kernel driver. The attacker creates or controls a file on that mount and uses extended-attribute operations to write reserved WSL metadata attributes that ntfs3 should have treated as internal-only. By planting values corresponding to root ownership and setuid-capable permissions, the attacker causes ntfs3 to reload attacker-supplied metadata into the inode's UID, GID, and mode fields. When the file is subsequently executed, and if the mount does not block setuid execution, the process can run with elevated effective privileges. The attacker can then use those privileges to obtain root-level control of the host.

How to fix it

Apply the Linux kernel update containing the ntfs3 fix that rejects direct userspace writes to reserved $LX* extended-attribute names. Because no exact fixed package versions were provided, follow the relevant Linux distribution kernel advisory and upgrade to the latest patched kernel for the deployed release, then reboot into the fixed kernel. As interim mitigation, avoid exposing writable ntfs3 mounts to untrusted users, mount NTFS volumes read-only where possible, or remount ntfs3 filesystems with restrictive options such as nosuid, noexec, and nodev. If NTFS write support is not required, disable or avoid loading the ntfs3 driver. On shared systems, review fstab, automount, removable-media, and desktop-mount policies to ensure NTFS volumes are not mounted in a way that allows privilege escalation through setuid execution.

How to confirm the fix worked

Confirm the running kernel includes the ntfs3 patch from the relevant vendor or upstream stable kernel release, not only that the package is installed. Inventory mounted NTFS filesystems and verify they are either not using ntfs3, are not writable by untrusted users, or are mounted with nosuid and preferably noexec/nodev. A controlled validation test on a non-production system can confirm that direct userspace attempts to set reserved attributes named $LXUID, $LXGID, $LXMOD, or $LXDEV on an ntfs3 file are rejected with a permission or invalid-argument error. Also verify that setuid execution from ntfs3 mounts is blocked where mitigation rather than patching is being relied upon.

Typical attack path

  1. Obtain local low-privileged shell or user access on a Linux system.
  2. Identify a writable NTFS filesystem mounted using the ntfs3 driver.
  3. Create or control a file on the writable ntfs3 mount.
  4. Set reserved $LX* extended attributes that are intended for ntfs3 internal WSL permission metadata.
  5. Trigger inode metadata reload so ntfs3 interprets the attacker-controlled attributes as trusted UID, GID, and mode values.
  6. Execute the manipulated file if mount options permit execution and setuid behavior.
  7. Gain elevated effective privileges and use them for host compromise, persistence, or lateral movement.

How to detect it

To assess possible prior exploitation, focus on local host telemetry. Review auditd, eBPF/EDR, Sysmon for Linux, or kernel telemetry for setxattr, lsetxattr, and fsetxattr calls involving reserved ntfs3 WSL metadata names $LXUID, $LXGID, $LXMOD, or $LXDEV, especially when performed by non-root users against files on NTFS mounts. Examine shell history and process execution logs for extended-attribute tooling used against ntfs3 paths. Inspect writable ntfs3 mounts for files carrying these reserved attributes, unexpected root ownership, or setuid bits on files located in user-writable directories. Review authentication, sudo, process, and EDR logs for signs of a low-privileged user spawning a root shell or executing newly created binaries from NTFS mount points. If removable media is common, correlate mount events with subsequent privilege changes. Absence of logs for xattr syscalls may limit retrospective confidence, so combine telemetry review with filesystem inspection.

  • $LXUID
  • $LXGID
  • $LXMOD
  • $LXDEV
  • setxattr
  • lsetxattr
  • fsetxattr
  • getfattr
  • setfattr
  • security.audit: setxattr
  • syscall=setxattr
  • syscall=lsetxattr
  • syscall=fsetxattr
  • fstype=ntfs3
  • type=SYSCALL
  • name="$LXUID"
  • name="$LXGID"
  • name="$LXMOD"
  • name="$LXDEV"
  • -fstype ntfs3
  • nosuid

What your security team should do

  • Prioritize patching Linux systems that permit local users to write to ntfs3-mounted NTFS volumes, especially shared servers, developer workstations, VDI hosts, and systems handling removable media.
  • Reboot systems after kernel update and verify they are running the fixed kernel.
  • Immediately remount writable ntfs3 filesystems with nosuid and noexec where operationally feasible.
  • Inventory /proc/mounts, fstab, systemd mount units, desktop automount policies, and removable-media handling for ntfs3 usage.
  • Hunt for suspicious extended-attribute writes to $LXUID, $LXGID, $LXMOD, and $LXDEV on NTFS mounts.
  • Review recent local privilege escalation indicators, including unexpected setuid files, root-owned files created by non-root users, and unusual root shells spawned from user-writable mount paths.
  • Restrict local shell access and removable-media mounting rights on systems where ntfs3 cannot be promptly patched.
  • Track vendor advisories for exact fixed kernel versions and update detection content as package names and fixed releases become available.

The record

In the Linux kernel, the following vulnerability has been resolved: ntfs3: reject direct userspace writes to reserved $LX* xattrs NTFS3 uses $LXUID, $LXGID, $LXMOD and $LXDEV as internal WSL permission metadata and reloads them into i_uid, i_gid and i_mode from ntfs_get_wsl_perm(). Because the empty-prefix xattr handler also lets file owners call setxattr() on these names directly, an unprivileged writer on a writable ntfs3 mount can plant root ownership and S_ISUID on their own file and gain euid 0 after inode reload. Reject direct userspace writes to the reserved $LX* names. Internal ntfs3 metadata updates are unchanged because ntfs_save_wsl_perm() writes them via ntfs_set_ea() directly. [almaz.alexandrovich@paragon-software.com: added an additional check for non privileged users]

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities