CVE-2026-121550 in nnn
Summary
by MITRE • 11/03/2026
nnn through 5.3 contains an insecure file handling vulnerability that allows local attackers to redirect writes because main() accepts an existing NNN_FIFO path without verifying it is a FIFO. Attackers can pre-create the documented predictable /tmp/nnn.fifo path as a symlink or readable regular file, causing victim-writable files to be overwritten or leaking the victim's browsed paths.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified in nnn versions through 5.3 represents a critical insecure file handling flaw rooted in improper validation of input parameters during initialization. Specifically, the main function accepts an NNN_FIFO environment variable path without performing adequate type checking to ensure that the specified path is indeed a named pipe or FIFO device. This oversight allows local attackers with basic filesystem manipulation capabilities to exploit this lack of verification by pre-creating the documented predictable file path located in /tmp/nnn.fifo as either a symbolic link pointing to a sensitive system file or a regular readable and writable file. The core technical flaw lies in the application's assumption that any existing file at the expected location is safe for interaction, ignoring standard security practices that require verifying file types before opening them for write operations.
From an operational perspective, this vulnerability enables two distinct categories of attacks depending on how the attacker configures the malicious entry point. If the attacker creates a symbolic link pointing to a target file with permissions allowing writing by the victim user or group, any data written by nnn through the FIFO mechanism will be redirected to that target location instead of the intended pipe. This results in arbitrary local file overwrites, which can lead to denial of service if critical configuration files are corrupted, or privilege escalation if system-level files such as /etc/passwd or shell scripts are overwritten with malicious content. Alternatively, if the attacker creates a regular readable file at that path and ensures it is writable by nnn's execution context in specific configurations, they may be able to intercept data intended for the FIFO, potentially leaking information about the victim's browsed paths or other sensitive session data handled through this interface.
This vulnerability aligns with CWE-59 Improper Link Resolution Before File Access, commonly known as a race condition involving symbolic links, and falls under the broader category of CWE-436 Interpretation Error where the application misinterprets user-controlled input regarding file types. In terms of adversary behavior, this technique corresponds to ATT&CK tactic T1059 Command and Scripting Interpreter if used for execution via overwritten scripts, or more directly to data manipulation techniques that compromise integrity through unauthorized write operations. The predictability of the /tmp/nnn.fifo path exacerbates the risk because attackers do not need to guess random filenames; they can reliably target this specific location knowing it is hardcoded into the application's logic as a default communication channel between processes or for session state management.
Mitigation strategies must focus on enforcing strict file type validation before any open or write operations are attempted. The developers should implement checks using standard system calls such as stat() to verify that the path corresponds specifically to a FIFO device, rejecting all other file types including regular files and symbolic links. Additionally, adopting secure temporary file creation practices by generating unique filenames with mkstemp() rather than relying on predictable paths in shared directories like /tmp would significantly reduce the attack surface. Until an official patch is applied, users should avoid setting the NNN_FIFO environment variable to a pre-existing path or ensure that their /tmp directory has restrictive permissions and uses sticky bits appropriately to limit cross-user file manipulation risks.