CVE-2026-46671: 
Rust vulnerability analysis and mitigation

CVE-2026-46671 is a path traversal vulnerability in the Rust onenote_parser crate (part of the msiemens/onenote.rs project) that allows a maliciously crafted .onetoc2 table-of-contents file to cause Parser::parse_notebook to open arbitrary files on the host filesystem outside the notebook's intended directory. It affects all versions of onenote_parser prior to 1.1.1. The vulnerability was published by the maintainer on May 16, 2026, and added to the GitHub Advisory Database on May 21, 2026. It carries a CVSS v3.1 base score of 4.4 (Medium) (GitHub Advisory, Security Advisory).

The root cause is CWE-22 (Improper Limitation of a Pathname to a Restricted Directory). In vulnerable versions, Parser::parse_notebook reads section entry names from the .onetoc2 file and directly joins them against the notebook's base directory path using base_dir.push(name) without validating that the resulting path remains within the base directory. This allows entry names containing absolute paths (e.g., /etc/passwd) or parent-directory traversal components (e.g., ../secret.one) to resolve to arbitrary filesystem locations. Exploitation requires local access and user interaction — a victim must invoke Parser::parse_notebook on a malicious .onetoc2 file. The fix, introduced in commit c9267b2, adds a resolve_entry_path function that rejects absolute paths, .. components, and invalid characters, and additionally canonicalizes the resolved path to confirm it stays within the base directory (GitHub Advisory, Fix Commit).

Successful exploitation enables an attacker to cause the parser to attempt to open arbitrary files on the host filesystem outside the notebook directory. Because the parser bails out when a target file fails to parse as a valid OneNote section, direct content exfiltration via the parser's return value is not practical; however, file-existence probing (determining whether specific files exist on the system) and denial-of-service via large or special files (e.g., device files on Linux) remain viable attack outcomes. Integrity is not impacted. The vulnerability is scoped to applications that process untrusted .onetoc2 files using onenote_parser (GitHub Advisory, Security Advisory).

1. Craft a malicious .onetoc2 file: Create a .onetoc2 table-of-contents file with section entry names containing path traversal sequences, such as ../../../etc/passwd (Linux) or C:\Windows\System32\drivers\etc\hosts (Windows absolute path).
2. Deliver the file to the target: Distribute the malicious .onetoc2 file to a victim who uses an application built on onenote_parser versions prior to 1.1.1 — for example, via email attachment, file sharing, or upload to a document processing service.
3. Trigger parsing: Cause the victim application to call Parser::parse_notebook on the malicious .onetoc2 file. This can happen automatically if the application processes uploaded notebooks without user confirmation.
4. Observe side-channel effects: Monitor application behavior (e.g., error messages, response timing, or resource consumption) to infer whether the targeted file exists on the filesystem (file-existence probing), or supply a path to a large or special file (e.g., /dev/urandom) to trigger a denial-of-service condition (GitHub Advisory, Fix Commit).

• File System: Presence of .onetoc2 files with entry names containing .., absolute path prefixes (e.g., /, C:\), or references to files outside the notebook directory.
• Logs: Application error logs showing InvalidPath errors or parse failures referencing unexpected filesystem paths (e.g., /etc/passwd, system directories) when processing .onetoc2 files.
• Process: Unusual file open attempts by the application process targeting files outside expected notebook directories, observable via system call tracing tools (e.g., strace on Linux, Process Monitor on Windows).

Upgrade onenote_parser to version 1.1.1 or later, which rejects absolute paths, parent-directory components (..), and other invalid path characters in .onetoc2 entry names, and canonicalizes resolved paths to confirm they remain within the notebook's base directory. For users unable to upgrade immediately, two workarounds are available: (1) only call Parser::parse_notebook on .onetoc2 files from fully trusted sources, or (2) use Parser::parse_section / Parser::parse_section_buffer on individual .one files directly, which do not perform the directory walk (GitHub Advisory, Release v1.1.1).