CVE-2026-46671: Rust OneNote Parser Path Traversal Flaw

CVE-2026-46671 Overview

CVE-2026-46671 is a path traversal vulnerability [CWE-22] in the onenote_parser Rust crate, a library for parsing Microsoft OneNote files. Versions prior to 1.1.1 allow a maliciously crafted .onetoc2 table-of-contents file to force Parser::parse_notebook to open arbitrary files on the host filesystem outside the notebook's base directory. The parser joins entry names from .onetoc2 files against the notebook directory without validating that they are relative paths. Applications that parse .onetoc2 files from untrusted sources are affected. The issue is fixed in onenote_parser 1.1.1.

Critical Impact
Attackers can probe file existence and trigger denial-of-service through crafted .onetoc2 files. Direct content exfiltration is limited because the parser bails out when the target file is not a valid OneNote section.

Affected Products

onenote_parser (onenote.rs) crate versions prior to 1.1.1
Rust applications consuming Parser::parse_notebook on untrusted .onetoc2 input
Downstream tools and pipelines that process user-supplied OneNote notebooks

Discovery Timeline

2026-07-20 - CVE-2026-46671 published to NVD
2026-07-23 - Last updated in NVD database

Technical Details for CVE-2026-46671

Vulnerability Analysis

The vulnerability resides in Parser::parse_notebook within the onenote.rs crate. A .onetoc2 file lists entry names that reference .one section files inside the notebook. The parser reads these entry names and joins each name against the notebook's base directory to construct a full path. It then opens and parses the resulting file without confirming that the path remains inside the base directory.

A crafted .onetoc2 can supply absolute paths, .. parent-directory components, or platform-specific path characters. When joined against the base directory, these values resolve to locations elsewhere on the filesystem. The parser opens the file and attempts to parse it as a OneNote section.

Because parsing fails on non-OneNote content, the parser's return value does not expose file contents to the caller. However, an attacker can still confirm file existence based on error behavior and trigger denial-of-service by pointing the parser at large files, device files, or blocking special files.

Root Cause

The root cause is missing validation of entry names read from the .onetoc2 container. std::path::Path::join in Rust replaces the base path when joined with an absolute path and does not reject .. components. The parser trusted attacker-controlled input as safe relative filenames.

Attack Vector

Exploitation requires the victim to invoke Parser::parse_notebook on an attacker-supplied .onetoc2 file. This is a local attack vector with user interaction, targeting applications, services, or CLI tools that ingest OneNote notebooks from untrusted sources such as email attachments, file shares, or web uploads.

rust

// Patch excerpt: src/onenote/mod.rs
 use crate::onenote::section::{Section, SectionEntry, SectionGroup};
 use crate::onestore::parse_store;
 use crate::reader::Reader;
+use sanitise_file_name::sanitise;
 use std::ffi::OsStr;
 use std::fs::File;
 use std::io::{BufReader, Read};
-use std::path::Path;
+use std::path::{Component, Path, PathBuf};

Source: GitHub Commit c9267b2

The patch introduces the sanitise-file-name crate and imports Component and PathBuf to enable per-component path validation and canonicalisation.

Detection Methods for CVE-2026-46671

Indicators of Compromise

.onetoc2 files containing absolute paths, .. sequences, or path separators inside entry name fields
Application logs showing onenote_parser opening files outside the expected notebook directory
Parser errors indicating unexpected file formats when processing OneNote notebooks from external sources

Detection Strategies

Audit dependency manifests (Cargo.toml, Cargo.lock) across build pipelines for onenote_parser versions below 1.1.1
Inspect ingested .onetoc2 files by extracting entry names and flagging any that include /, \, .., or drive letters
Monitor filesystem access telemetry from processes linking the parser for reads outside expected notebook roots

Monitoring Recommendations

Enable file access auditing on hosts running services that parse OneNote uploads and alert on cross-directory reads
Track error rates and process crashes in OneNote parsing services as signals of DoS probing
Ingest software composition analysis output into the SIEM to detect vulnerable crate versions across the fleet

How to Mitigate CVE-2026-46671

Immediate Actions Required

Upgrade onenote_parser to version 1.1.1 or later in all Rust projects that consume the crate
Rebuild and redeploy any binary shipping the vulnerable version
Restrict the process running the parser to a minimal filesystem view using OS-level sandboxing

Patch Information

The fix landed in onenote_parser 1.1.1, released 2026-05-15. It rejects absolute paths, parent-directory components, and invalid path characters in entry names, then canonicalises the resolved path to confirm it stays inside the notebook's base directory. Details are available in the GitHub Security Advisory GHSA-4j5m-wc25-pvh7, the v1.1.1 Release Tag, and the Changelog Entry.

Workarounds

Only call Parser::parse_notebook on .onetoc2 files originating from trusted sources
Substitute Parser::parse_section or Parser::parse_section_buffer on individual .one files, which skip the directory walk
Pre-validate .onetoc2 entry names to reject absolute paths and .. components before invoking the parser

bash

# Update the crate in Cargo.toml
cargo update -p onenote_parser --precise 1.1.1
cargo audit