nnn CVE-2026-65609

Exploitation requires three concurrent conditions: (1) the attacker must have write access to the victim's nnn session directory on the local filesystem - this is typically only possible if the attacker is another local user on a shared system, or if they can achieve file placement via another vulnerability or social engineering; (2) the victim must use the -s option when launching nnn, explicitly loading the malicious session file - this is a non-default invocation that requires user action; (3) the victim must be running nnn version 5.2 or potentially an unconfirmed earlier version. Exploitation is limited to local access only (AV:L), cannot be triggered remotely, and requires active user interaction to load the session file. The absence of a default-on session autoload mechanism means passive exposure is not possible without deliberate user action.

The CVSS 4.0 base score of 2.4 (Low) accurately reflects the constrained attack surface: the vector AV:L/AC:L/AT:N/PR:L/UI:A/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N indicates a local attack requiring low privileges and active user interaction (the victim must explicitly invoke nnn with the -s flag). There is no confidentiality impact and only limited integrity and availability impact against the vulnerable system itself, with no subsequent-system effects. EPSS data is not available in the provided intelligence, and the vulnerability is not listed in CISA KEV, so no confirmed active exploitation is known. No public proof-of-concept code has been identified. The practical threat is narrow: an attacker must already have write access to the victim's nnn session directory - a prerequisite that substantially limits exploitability in shared or hardened environments. The primary real-world risk is a crash or corruption of nnn's runtime state, not remote code execution or data exfiltration. This is a low-priority finding in most operational contexts unless nnn is used in privileged or automated pipelines where session files could be injected.

A local attacker with write access to the victim's nnn session directory crafts a session file containing maliciously oversized length fields. When the victim subsequently runs nnn with the -s flag (e.g., nnn -s mysession), nnn deserializes the crafted file without bounds checking, writing data beyond fixed-size global buffers and corrupting adjacent global state, potentially crashing nnn or influencing its runtime behavior. No public proof-of-concept has been identified, but the attack logic is straightforward for a developer familiar with nnn's session file format.