CVE-2026-86258 in nbviewer
Summary
by MITRE • 09/06/2026
nbviewer through 1.0.1 contains a path traversal vulnerability in LocalFileHandler.can_show() that uses string-prefix comparison instead of proper path validation. Attackers can read files from sibling directories outside the configured root by requesting paths that share the root as a textual prefix, disclosing unintended notebooks and credentials.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/06/2026
The nbviewer application, specifically through version 1.0.1, suffers from a critical path traversal vulnerability within its LocalFileHandler.can_show() method. This flaw stems from an insecure implementation of file access control where the system relies on simple string-prefix comparison to validate user-supplied input against a configured root directory. Instead of utilizing robust operating-system-level path resolution mechanisms or canonicalization functions that resolve symbolic links and relative paths like dot-dot-slash sequences, the application performs a naive textual check. This approach fails to account for how file systems interpret hierarchical structures, allowing an attacker to craft requests that bypass the intended security boundary by exploiting the difference between string matching and actual filesystem navigation logic.
From a technical perspective, this vulnerability is classified under CWE-22: Improper Limitation of a Pathname to a Restricted Directory. The core issue lies in the failure to properly canonicalize paths before validation. When an attacker provides a path that begins with the same characters as the allowed root directory but includes traversal sequences or sibling directory references, the string-prefix check may incorrectly return true because it only verifies if the input starts with the expected prefix. For instance, if the root is /var/nbviewer and the application checks if the requested path starts with "/var/nbviewer", a request for "/var/nbviewer/../etc/passwd" might pass this superficial check depending on how the string comparison is implemented relative to any subsequent normalization steps that are missing or flawed. This allows access to files located in directories adjacent to or above the intended scope, effectively breaking out of the sandboxed environment designed by the application developers.
The operational impact of this vulnerability is severe, leading to unauthorized information disclosure and potential compromise of sensitive data. Attackers can exploit this flaw to read arbitrary files from the server hosting nbviewer that reside outside the designated notebook directory. This includes configuration files, source code repositories containing hardcoded credentials or API keys, database connection strings, and other private notebooks stored in sibling directories. The exposure of such sensitive information can lead to further attacks, including credential stuffing, lateral movement within a network if internal services are exposed via file contents, or intellectual property theft. In environments where nbviewer is used for educational or collaborative purposes, this breach undermines the confidentiality guarantees expected by users who assume their notebooks and associated resources are isolated from public access.
This vulnerability aligns with MITRE ATT&CK technique T1083: File and Directory Discovery, as it enables an attacker to enumerate and access files outside of intended boundaries without direct execution capabilities on the server itself. It also reflects common pitfalls in web application development where developers assume that input validation based on string manipulation is sufficient for security-critical path restrictions. The lack of proper sanitization highlights a gap in secure coding practices regarding file system interactions, emphasizing the need for defense-in-depth strategies rather than relying solely on perimeter-style checks within the application logic.
To mitigate this vulnerability, it is imperative to upgrade nbviewer to version 1.0.2 or later where the path validation logic has been corrected to use proper filesystem-aware methods such as os.path.realpath() in Python environments to resolve paths to their canonical form before comparison. Alternatively, developers should implement strict allow-listing of permitted file extensions and ensure that any user-supplied path is resolved relative to a fixed base directory using secure APIs that prevent traversal sequences from escaping the root context. Additionally, deploying web application firewalls with rules specifically targeting path traversal patterns can provide an additional layer of protection during the transition period. Regular security audits focusing on input validation for file operations are recommended to identify similar weaknesses in other components of the infrastructure.