CVE-2026-65612 in nnn
Summary
by MITRE • 08/19/2026
nnn does not sanitize the filename variable. An attacker can place a file with a crafted name on a shared filesystem, removable media, or inside an extracted archive whose name contains a single quote followed by shell syntax. If the victim navigates to that file and opens it with preview-tabbed, the filename 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 best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability identified in the file manager application nnn represents a critical command injection flaw stemming from insufficient input sanitization of filename variables during shell command generation. This security defect allows an attacker to execute arbitrary system commands with the privileges of the user running the nnn process, provided they can influence the filenames present within directories accessed by the victim. The core technical failure lies in the application's handling of special characters, specifically single quotes and shell metacharacters, which are not properly escaped or validated before being embedded into underlying operating system commands. This lack of rigorous input validation creates a direct pathway for code injection when specific file operations trigger external command execution.
The operational impact is significant because it enables remote code execution under the context of the current user without requiring authentication if the attacker has access to shared filesystems, removable media such as USB drives, or can trick users into extracting maliciously crafted archives. The attack vector typically involves placing a file with a specially constructed name containing shell syntax on a target location. When an unsuspecting victim navigates to this directory and utilizes features that generate preview commands, such as the preview-tabbed functionality, the application constructs a shell command using the unsanitized filename. Consequently, any injected payload embedded within the filename is interpreted by the system shell rather than treated as literal text, leading to immediate execution of malicious code with the same permissions as the nnn process itself.
This vulnerability aligns closely with Common Weakness Enumeration standard CWE-78, which describes Improper Neutralization of Special Elements used in an OS Command, commonly known as OS Command Injection. The exploitation technique mirrors tactics documented in the MITRE ATT&CK framework under T1059, specifically command and scripting interpretation subcategories like T1059.004 for Unix Shell Commands. By leveraging standard shell metacharacters such as semicolons or pipes within filenames, an attacker can chain commands to perform reconnaissance, escalate privileges if the user has elevated rights, or install persistent backdoors on the compromised system. The severity is further compounded by the social engineering aspect required to get a victim to open files from untrusted sources like removable media or downloaded archives.
Mitigation strategies must focus on both immediate remediation and long-term defensive coding practices. For end-users, it is advisable to avoid opening preview tabs for files originating from untrusted locations until patches are applied. System administrators should ensure that nnn is updated to the latest version where this issue has been resolved by the maintainers. From a development perspective, the application must implement strict input validation and output encoding mechanisms whenever filenames or other user-supplied data are passed to system shells. Utilizing safe API calls that do not invoke shell interpreters directly, such as execve with explicit argument arrays instead of sh -c strings, would eliminate this class of vulnerability entirely. Additionally, implementing allowlists for permitted characters in filenames within the application logic can provide an additional layer of defense against injection attacks.