CVE-2026-121549 in nnn
Summary
by MITRE • 11/03/2026
nnn through 5.3 contains an insecure temporary file vulnerability in the pdfread and nuke plugins that allows local attackers to overwrite files by exploiting predictable paths in /tmp. Attackers can pre-create a symlink at the name-derived or PID-derived path so the victim's plugin truncates and overwrites any file the victim can write.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified within versions 5 through 5.3 of the software affects both the pdfread and nuke plugins, representing a classic insecure temporary file creation flaw that stems from predictable naming conventions used during runtime operations. This specific weakness allows local attackers to manipulate file system interactions by exploiting the deterministic nature of the paths generated in the /tmp directory. The core technical issue lies in how these plugins handle intermediate data storage; rather than utilizing secure randomization or atomic file creation mechanisms, they rely on path names derived from predictable inputs such as process identifiers or static naming patterns. This predictability creates a race condition window where an attacker can anticipate the exact location and name of the temporary file that will be created by the vulnerable application during its normal execution flow.
From a technical perspective, this vulnerability is categorized under CWE-377, which describes insecure temporary files as those created in directories with predictable names without proper access controls or atomic operations. The attack vector relies on the principle of symlink following, where an attacker pre-creates a symbolic link at the predicted path within /tmp before the vulnerable plugin attempts to write its data. When the application executes and seeks to create or truncate this temporary file for processing PDF documents or Nuke-related content, it follows the symbolic link rather than creating a new independent file. Consequently, any write operation performed by the privileged or victim process is redirected to the target specified in the symlink. This mechanism effectively bypasses standard permission checks because the application believes it is writing to its own temporary space, while in reality, it is modifying files owned and writable by the attacker within their own directory structure.
The operational impact of this vulnerability extends beyond simple data leakage or denial of service, as it facilitates arbitrary file write operations that can lead to privilege escalation if executed with elevated privileges. By overwriting critical system configuration files, application binaries, or user-specific settings located in directories where the victim has write permissions, an attacker can alter the behavior of the host system. For instance, replacing a shared library or modifying a startup script could allow for persistent code execution under the context of the compromised account. This capability significantly lowers the barrier for exploitation since it requires only local access and does not necessitate complex buffer overflow techniques or remote network interaction. The simplicity of using symbolic links makes this attack highly reliable and difficult to detect through standard logging mechanisms unless specific file integrity monitoring is in place.
In terms of threat modeling, this vulnerability aligns with ATT&CK technique T1552.004, which involves unsecured credentials stored locally or more broadly fits within the broader category of resource hijacking where an attacker takes control of a system resource to gain persistence or privilege escalation. The exploitation strategy mirrors common patterns seen in Unix-like operating systems where /tmp is world-writable and lacks sticky bit enforcement on all directories, although modern distributions often mitigate this by default. However, applications that do not adhere to secure coding practices remain vulnerable regardless of OS-level mitigations if they fail to implement application-side safeguards such as using mkstemp for atomic file creation or restricting temporary directory permissions via umask settings.
To mitigate this vulnerability, developers must refactor the codebase within the pdfread and nuke plugins to eliminate reliance on predictable temporary paths. The primary remediation involves replacing standard file open calls with secure alternatives like mkstemp in C-based implementations or equivalent functions in other languages that generate unique filenames atomically. This ensures that each temporary file has a random, unpredictable name and is created exclusively for the requesting process, preventing symlink attacks entirely. Additionally, implementing strict access controls on any custom temporary directories used by these plugins can further reduce risk. Administrators should also ensure that system-wide policies enforce proper permissions on /tmp, such as mounting it with noexec or nodev options where appropriate, to limit the potential impact of successful exploitation. Regular security audits focusing on file handling routines are essential to prevent similar insecure patterns from being introduced in future updates.