CVE-2026-65611 in nnn
Summary
by MITRE • 08/19/2026
nnn does not sanitize the path variable. An attacker can create a directory on a shared filesystem, removable media, or inside an extracted archive whose name contains a single quote followed by shell syntax. If the victim enters that directory in nnn and uses the batch copy or move workflow, the crafted directory name is embedded into the generated shell command and the injected payload executes with the privileges of the nnn process.
Maintainer of this project was notified about this vulnerability. It might has been addressed, but the maintainer did not provide a vulnerable version range. Only version 5.2 was tested and confirmed as vulnerable.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/21/2026
The vulnerability identified in the file manager application nnn represents a critical command injection flaw stemming from insufficient input sanitization of path variables during batch operations. This security defect allows an attacker to execute arbitrary shell commands with the privileges of the user running the nnn process, effectively leading to full system compromise within that context. The root cause lies in how the application constructs external shell commands for file management tasks such as copying or moving files. When a user selects multiple items for batch processing, nnn generates a command string that includes the paths of these items. However, the software fails to properly escape or sanitize special characters within filenames, specifically single quotes and other shell metacharacters. This lack of rigorous input validation creates a direct pathway for code injection when maliciously crafted file names are processed by the application's internal logic.
The operational mechanism of this exploit relies on social engineering combined with specific filesystem conditions. An attacker can create a directory or file whose name contains a single quote followed immediately by shell syntax, such as command substitution operators or pipe characters. This payload must be placed in a location accessible to the victim, such as a shared network drive, removable media like USB drives, or within an archive that is extracted on the victim's system. When the victim navigates into this directory using nnn and initiates a batch copy or move operation involving files with these crafted names, the application embeds the unsanitized filename directly into the shell command string without proper escaping. Consequently, when the operating system executes this generated command, it interprets the injected syntax as valid code rather than literal text, resulting in the execution of arbitrary commands under the current user's security context.
This vulnerability aligns with Common Weakness Enumeration (CWE) category CWE-78 Improper Neutralization of Special Elements used in an OS Command, commonly known as OS Command Injection. The impact is severe because it bypasses standard application sandboxing by leveraging the shell interpreter itself. If nnn is run with elevated privileges or if the user has significant permissions on the system, the attacker gains equivalent access. This can lead to data exfiltration, installation of persistent backdoors, privilege escalation through subsequent exploits, and complete compromise of the host machine's integrity and confidentiality. The attack vector is primarily local but can be triggered remotely via shared filesystems or phishing campaigns involving malicious archives, making it a significant risk in enterprise environments where removable media or network shares are commonly used for file transfer.
Mitigation strategies must address both immediate remediation and long-term defensive coding practices. Since the maintainer has not provided a specific vulnerable version range but confirmed vulnerability in version 5.2, users should immediately update to any patched release if available from official channels. In the absence of an updated binary, administrators can implement mitigations such as restricting nnn's execution privileges using tools like sudoers with strict command whitelisting or employing mandatory access control systems like SELinux or AppArmor to limit shell interaction capabilities. Additionally, users should be educated on the risks of executing batch operations in directories containing files from untrusted sources. For developers, the fix requires implementing robust input validation and output encoding for all path variables before they are passed to system shells. Utilizing safe APIs that do not invoke a shell interpreter directly, or ensuring proper escaping using language-specific libraries designed for command construction, is essential to prevent similar injection vectors in future versions of the software.