CVE-2026-6390: GNU nano Information Disclosure Flaw

CVE-2026-6390 Overview

CVE-2026-6390 is a format string vulnerability [CWE-134] in GNU nano's multi-buffer error message handling. When a user opens multiple files at startup and one triggers an ALERT-level error, a filename containing printf format specifiers is reinterpreted by the error handling routine. An attacker who controls a filename can leverage this behavior to disclose stack memory, crash the editor, or potentially perform arbitrary memory writes. Exploitation requires local access and user interaction, since the victim must open the malicious filename in nano. The flaw affects GNU nano across Linux distributions that ship the affected version, including Red Hat Enterprise Linux.

Critical Impact
A crafted filename passed to nano at startup can trigger stack information disclosure, denial of service, or arbitrary memory writes through unsanitized format string processing.

Affected Products

GNU nano text editor (multi-buffer startup mode)
Red Hat Enterprise Linux distributions shipping the affected nano package
Downstream Linux distributions packaging vulnerable nano builds

Discovery Timeline

2026-07-23 - CVE-2026-6390 published to NVD
2026-07-23 - Last updated in NVD database

Technical Details for CVE-2026-6390

Vulnerability Analysis

GNU nano supports opening multiple files at once when invoked with several filename arguments. During startup, if one of these files causes an ALERT-level error, such as a file that cannot be read or accessed, nano generates an error message that includes the offending filename. The error message routine passes the filename directly into a formatted output function without treating it as a literal string. As a result, format specifiers such as %s, %x, %p, and %n embedded in the filename are interpreted rather than displayed. This is a textbook format string vulnerability classified under [CWE-134].

Because nano runs with the privileges of the invoking user, the impact is bounded by that user's context. The vulnerability still enables reading data from the process stack, crashing the editor through invalid pointer dereferences, and potentially writing to attacker-chosen memory addresses via %n-style specifiers.

Root Cause

The root cause is the use of user-controlled input as the format string argument to a printf-family function inside nano's multi-buffer error reporting path. Correct usage requires passing the filename as a variadic argument with a fixed %s format string, for example fprintf(stderr, "%s", filename) rather than fprintf(stderr, filename).

Attack Vector

An attacker stages a file with a malicious name containing format specifiers, for example a filename such as %x%x%x%n, in a directory the victim will browse. The victim then invokes nano with multiple file arguments where one is the crafted filename and one triggers an ALERT condition. When nano formats the error message, the format specifiers are evaluated against the current stack, leaking data or corrupting memory. Delivery vectors include shared directories on multi-user systems, extracted archives, and repositories cloned by developers.

No verified public proof-of-concept exploit code is available. See the Red Hat CVE-2026-6390 Advisory and Red Hat Bug Report #2458767 for vendor-supplied technical details.

Detection Methods for CVE-2026-6390

Indicators of Compromise

Filenames on disk containing printf format specifiers such as %s, %x, %p, or %n, especially in shared or world-writable directories.
Unexpected nano process crashes recorded in system logs or core dumps referencing formatted output functions.
Shell history entries showing nano invoked with multiple file arguments where one argument contains format specifier characters.

Detection Strategies

Scan filesystems for files whose names contain % followed by format specifier characters, prioritizing user home directories, /tmp, and shared mounts.
Monitor process telemetry for nano executions with argument vectors containing suspicious percent-encoded patterns.
Correlate crash events for nano with the presence of unusual filenames opened in the same session.

Monitoring Recommendations

Enable auditd rules on execve calls for /usr/bin/nano and alert on arguments containing multiple % characters.
Collect and centralize core dump metadata to identify repeated nano crashes across hosts.
Track package inventory to confirm which endpoints still run an unpatched nano version.

How to Mitigate CVE-2026-6390

Immediate Actions Required

Update the nano package to the fixed version supplied by your Linux distribution as soon as it is available.
Restrict write access to shared directories where users routinely open files with nano, reducing the ability for attackers to plant crafted filenames.
Advise users to avoid opening unfamiliar files with nano using multi-file startup arguments until patches are deployed.

Patch Information

Refer to the Red Hat CVE-2026-6390 Advisory for the authoritative list of fixed package versions and errata. Downstream distributions such as Debian, Ubuntu, Fedora, and SUSE release parallel updates through their standard security channels. Apply updates through the distribution package manager, for example dnf update nano on Red Hat-based systems or apt-get install --only-upgrade nano on Debian-based systems.

Workarounds

Open files individually with nano rather than passing multiple filenames on a single command line, which avoids the multi-buffer startup path that triggers the flaw.
Rename or remove files whose names contain % sequences before editing them, or quote and inspect filenames using ls -b before invoking the editor.
Use an alternative editor such as vim or emacs on multi-user hosts until the patched nano package is installed.

bash

# Configuration example: audit rule to log nano executions for later review
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/nano -k nano_exec