Vulnerabilities in nnn software

CERT Polska has received a report about vulnerabilities in nnn software and participated in coordination of their disclosure.

The vulnerabilityCVE-2026-65609: nnn is vulnerable to Out-of-Bound write vulnerability. Due to lack of validation of attacker-controlled length fields deserialized from a session file, a crafted session file can cause nnn to write data beyond the bounds of fixed-size global buffers when loaded with the-soption. An attacker who can place a malicious session file in the victim's nnn session directory can exploit this to corrupting neighboring global variables in memory.

The vulnerabilityCVE-2026-65610: nnn storeshomelenvariable asuchar_t, which can only represent values in the range 0-255. An attacker who can influence the victim's execution environment can provide an arbitrary HOME path with length that is truncated to 0. The expression(homelen - 1)is promoted tosigned intand becomes -1 and producing an out-of-bounds read and an out-of-bounds write one byte before the path buffer.

The vulnerabilityCVE-2026-65611: 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.

The vulnerabilityCVE-2026-65612: 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 withpreview-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 these vulnerabilities. They might have been addressed, but the maintainer did not provide a vulnerable version range. Only version 5.2 was tested and confirmed as vulnerable.

We thank Michał Majchrowicz and Marcin Wyczechowski from AFINE Team for the responsible vulnerability report.