EUVD-2026-26053Severity by source
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Primary rating from NVD · only source for this CVE.
CVSS VectorNVD
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
6DescriptionCVE.org
GNU nano creates the user’s ~/.local directory with overly permissive permissions when the directory does not exist yet. On first use of features requiring Cross-Desktop Group (XDG) data storage, nano explicitly requests directory mode 0777, making the directory world‑writable in environments where the process umask does not sufficiently restrict permissions. In systems with a relaxed or zero umask, such as container environments, CI/CD runners, embedded systems, or user shells configured with umask 000, this results in ~/.local being created as world‑writable. A local attacker can exploit a race window between nano’s creation of ~/.local and its subsequent creation of more restrictive subdirectories to write attacker‑controlled files into the victim’s XDG directory hierarchy.
This problem was fixed in nano version 9.0
AnalysisAI
GNU nano creates the ~/.local directory with world-writable permissions (0777) on first use of XDG data storage features when the directory does not exist, allowing local attackers in systems with relaxed umasks (such as containers, CI/CD runners, or environments with umask 000) to write attacker-controlled files into the victim's XDG directory hierarchy via a race condition. The vulnerability affects nano versions before 9.0 and carries a CVSS score of 2.1 with CISA SSVC assessment indicating partial technical impact but no known public exploitation.
Technical ContextAI
GNU nano uses the Cross-Desktop Group (XDG) Base Directory specification for storing application data in ~/.local/share/nano and related subdirectories. When these directories do not exist, nano explicitly requests creation with mode 0777 (world-writable) rather than relying on the process umask to restrict permissions. In Unix-like systems, the final directory permissions are typically computed as (requested_mode AND ~umask). However, when the umask is 0 (common in container environments, CI/CD runners, and some embedded systems), 0777 AND ~0 = 0777, resulting in a world-writable directory. A local attacker can exploit the time window between nano's creation of ~/.local/0777 and its subsequent creation of more restrictive subdirectories to inject malicious files. The root cause is CWE-732 (Incorrect Permission Assignment for Critical Resource), stemming from nano's hardcoded request for overly permissive directory creation modes without accounting for the security implications in restrictive-umask environments.
RemediationAI
Upgrade GNU nano to version 9.0 or later, which fixes the directory permission issue. This is the primary and recommended remediation. For users unable to immediately upgrade, the race condition can be mitigated by ensuring the process umask is set to a restrictive value (e.g., umask 0077 or umask 0027) before invoking nano; this prevents 0777 from resulting in world-writable directories even if nano requests that mode. In container and CI/CD environments, set the umask in the container entrypoint, shell profile, or orchestration configuration. Alternatively, pre-create ~/.local/share/nano with correct permissions (mode 0700 or 0755 owned by the user) before nano's first run, preventing nano from attempting creation. The patch is available from the GNU nano upstream repository at https://cgit.git.savannah.gnu.org/cgit/nano.git/commit/?id=cb43493e and should be included in nano 9.0 release packages from distribution maintainers.
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today