CVE-2026-65610 in nnn
Summary
by MITRE • 08/19/2026
nnn stores homelen variable as uchar_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 to signed int and becomes -1 and producing an out-of-bounds read and an out-of-bounds write one byte before the path buffer.
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/19/2026
The described vulnerability represents a classic integer truncation issue leading to an off-by-one error in memory access operations within the nnn file manager application. The core technical flaw stems from the data type selection for storing the length of the HOME environment variable, specifically using uchar_t which is an unsigned 8-bit integer capable of representing values only between zero and two hundred fifty-five. This limited range creates a critical boundary condition where any path string exceeding this maximum length will undergo truncation when assigned to the homelen variable. In practical terms, if an attacker or user configures their execution environment with a HOME directory path that is longer than two hundred fifty-five characters, the stored value effectively wraps around or becomes zero depending on the specific implementation details of the type casting and assignment process described in the report.
The security impact arises from how this truncated length variable is subsequently used in arithmetic operations involving buffer boundaries. The code calculates a boundary by subtracting one from homelen to determine valid indexing limits for string manipulation functions such as strcpy or similar memory copy routines. Because homelan has been truncated to zero due to the excessive input length, the expression homelen minus one results in negative one when promoted to a signed integer type during arithmetic evaluation. This negative value is then used as an index offset relative to the base address of the path buffer. Consequently, instead of accessing memory within the allocated bounds of the home directory string buffer, the application attempts to read from and write to the memory location immediately preceding the start of that buffer.
This out-of-bounds access constitutes a severe integrity violation with potential confidentiality implications depending on what data resides in the adjacent memory space prior to the path buffer. An attacker who can influence the victim's execution environment by setting an arbitrarily long HOME variable can trigger this condition, leading to undefined behavior. The immediate consequence is often application instability or crash due to segmentation faults when attempting to access protected memory pages outside the process heap or stack boundaries. However, in more complex scenarios involving specific compiler optimizations and adjacent data structures, such as file descriptors or pointers stored nearby on the stack, an out-of-bounds write could potentially overwrite critical control flow data or sensitive information, paving the way for remote code execution or privilege escalation if combined with other vulnerabilities.
From a classification perspective, this vulnerability aligns closely with CWE-190 Integer Overflow or Wraparound and CWE-787 Out-of-Bounds Write as well as CWE-788 Out-of-Bounds Read. The root cause is fundamentally an improper limitation of data type range leading to incorrect boundary calculations. In the context of the MITRE ATT&CK framework, this technique facilitates initial access through environment variable manipulation if the application processes user-controlled or system-level environmental settings without adequate validation. It falls under techniques related to command and script interpretation where environment variables are used to influence program behavior, although here it specifically targets memory safety rather than direct code injection.
The operational impact is significant for users who rely on nnn in environments with deeply nested directory structures or custom configurations that might result in long path names. While the report notes that only version five point two was confirmed as vulnerable and no specific range of affected versions was provided by the maintainer, it implies a need for caution across potentially multiple releases if similar code patterns persist. The lack of explicit versioning information complicates automated patch management but highlights the importance of source-level auditing rather than relying solely on vendor advisories for older or less actively maintained projects.
Mitigation strategies should focus primarily on input validation and robust type handling at the point where environment variables are processed. Developers must ensure that string lengths retrieved from environmental sources like HOME are validated against maximum allowable limits before being cast to smaller integer types. Implementing explicit checks such as verifying that homelen does not exceed a predefined safe threshold prior to arithmetic operations can prevent the truncation issue entirely. Additionally, using larger integer types for length variables or employing static analysis tools capable of detecting potential off-by-one errors and type promotion issues during development would significantly reduce the risk of similar flaws in future iterations. Users affected by this vulnerability should update their HOME environment variable to ensure it remains within standard path length limits until a patched version is available, thereby neutralizing the trigger condition for the out-of-bounds memory access.