CVE-2026-46671: path traversal — MEDIUM

CISO Take

A path traversal flaw in the Rust `onenote_parser` crate lets a maliciously crafted `.onetoc2` table-of-contents file cause `Parser::parse_notebook` to open arbitrary files outside the notebook's directory, because entry names are joined to the base path without validating they stay confined to it. There's no public exploit or CISA KEV listing, EPSS data isn't available, and the practical blast radius is limited: the parser bails as soon as the target file fails to parse as a valid OneNote section, so direct content exfiltration isn't realistic — the real exposure is file-existence probing and denial-of-service if the traversal points at large or special files (e.g. device files). Any pipeline that ingests `.onetoc2` files from untrusted sources — document loaders feeding a RAG index, agent tools that unpack user-uploaded notebooks — inherits this risk, while teams that only parse their own notebooks face negligible exposure. Upgrade to `onenote_parser` 1.1.1, which rejects absolute paths, parent-directory components, and canonicalises the resolved path against the notebook base directory; if you can't upgrade immediately, restrict `parse_notebook` to trusted input or switch to `parse_section`/`parse_section_buffer` on individual `.one` files, which skip the vulnerable directory walk entirely.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

Medium risk (CVSS 4.4, local vector, no privileges, user interaction required). Confidentiality impact is low and constrained — the parser aborts before returning content when the traversed target isn't a valid OneNote section, so this is not a practical data-exfiltration primitive. The realistic exposure is file-existence enumeration (an information leak about filesystem layout) and availability impact if the traversal is pointed at a large file or a special device file, causing resource exhaustion or a hang. No public exploit code, no Nuclei template, and not in CISA KEV — exploitation likelihood in the wild appears low today, but the fix is trivial to apply and the affected code path (parsing untrusted uploaded files) is a common pattern in AI document-ingestion tooling.

How does the attack unfold?

Delivery

Attacker crafts a malicious .onetoc2 file with entry names containing path-traversal sequences and delivers it to a target ingestion pipeline or user.

AML.T0011

Exploitation

Parser::parse_notebook joins the untrusted entry name to the notebook's base directory without validating it stays confined, opening a file outside the intended path.

Impact

Because the parser bails on non-OneNote content, the attacker can only probe file existence or trigger denial-of-service by targeting large or special files, not exfiltrate content.

AML.T0029

Delivery

Attacker crafts a malicious .onetoc2 file with entry names containing path-traversal sequences and delivers it to a target ingestion pipeline or user.

AML.T0011

Exploitation

Parser::parse_notebook joins the untrusted entry name to the notebook's base directory without validating it stays confined, opening a file outside the intended path.

Impact

Because the parser bails on non-OneNote content, the attacker can only probe file existence or trigger denial-of-service by targeting large or special files, not exfiltrate content.

AML.T0029

How severe is it?

CVSS 3.1

4.4 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Local

AC Low

PR None

UI Required

S Unchanged

C Low

I None

A Low

What should I do?

1 step

Upgrade to onenote_parser 1.1.1 or later, which rejects absolute paths, parent-directory (..) components, and invalid path characters in entry names, and canonicalises the resolved path to confirm it stays inside the notebook's base directory. If upgrading isn't immediately possible: only call Parser::parse_notebook on .onetoc2 files from trusted sources, or switch to Parser::parse_section / Parser::parse_section_buffer on individual .one files, which do not perform the vulnerable directory walk. For detection, monitor for unexpected file-open attempts or crashes originating from notebook-parsing code paths when processing user-supplied .onetoc2 files, and audit any ingestion pipeline for use of the vulnerable parse_notebook entry point against untrusted input.

How is it classified?

DoS Data Leakage Plugin AML.T0029 - Denial of AI Service AML.T0037 - Data from Local System

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

NIST AI RMF

GOVERN-6.1 - Third-party risk policies and procedures

OWASP LLM Top 10

LLM03:2025 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-46671?

A path traversal flaw in the Rust `onenote_parser` crate lets a maliciously crafted `.onetoc2` table-of-contents file cause `Parser::parse_notebook` to open arbitrary files outside the notebook's directory, because entry names are joined to the base path without validating they stay confined to it. There's no public exploit or CISA KEV listing, EPSS data isn't available, and the practical blast radius is limited: the parser bails as soon as the target file fails to parse as a valid OneNote section, so direct content exfiltration isn't realistic — the real exposure is file-existence probing and denial-of-service if the traversal points at large or special files (e.g. device files). Any pipeline that ingests `.onetoc2` files from untrusted sources — document loaders feeding a RAG index, agent tools that unpack user-uploaded notebooks — inherits this risk, while teams that only parse their own notebooks face negligible exposure. Upgrade to `onenote_parser` 1.1.1, which rejects absolute paths, parent-directory components, and canonicalises the resolved path against the notebook base directory; if you can't upgrade immediately, restrict `parse_notebook` to trusted input or switch to `parse_section`/`parse_section_buffer` on individual `.one` files, which skip the vulnerable directory walk entirely.

Is CVE-2026-46671 actively exploited?

No confirmed active exploitation of CVE-2026-46671 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-46671?

Upgrade to `onenote_parser` 1.1.1 or later, which rejects absolute paths, parent-directory (`..`) components, and invalid path characters in entry names, and canonicalises the resolved path to confirm it stays inside the notebook's base directory. If upgrading isn't immediately possible: only call `Parser::parse_notebook` on `.onetoc2` files from trusted sources, or switch to `Parser::parse_section` / `Parser::parse_section_buffer` on individual `.one` files, which do not perform the vulnerable directory walk. For detection, monitor for unexpected file-open attempts or crashes originating from notebook-parsing code paths when processing user-supplied `.onetoc2` files, and audit any ingestion pipeline for use of the vulnerable `parse_notebook` entry point against untrusted input.

What systems are affected by CVE-2026-46671?

This vulnerability affects the following AI/ML architecture patterns: RAG pipelines, document ingestion pipelines, agent frameworks.

What is the CVSS score for CVE-2026-46671?

CVE-2026-46671 has a CVSS v3.1 base score of 4.4 (MEDIUM).

What is the AI security impact?

Affected AI Architectures

RAG pipelinesdocument ingestion pipelinesagent frameworks

MITRE ATLAS Techniques

AML.T0029 Denial of AI Service

AML.T0037 Data from Local System

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: GOVERN-6.1

OWASP LLM Top 10: LLM03:2025

What are the technical details?

Original Advisory

Rust OneNote File Parser is a parser for Microsoft OneNote files implemented in Rust. Prior to version 1.1.1, a maliciously crafted `.onetoc2` table-of-contents file can cause `Parser::parse_notebook` to open arbitrary files on the host filesystem outside the notebook's directory. The parser reads entry names listed inside the `.onetoc2` and joins them against the notebook's base directory without validating that they are relative paths confined to that directory. The parser will bail out when the target file fails to parse as a OneNote section, so direct content exfiltration through the parser's return value is not practical, though file-existence probing and denial-of-service via large or special files remain possible. Anyone using `onenote_parser` to parse .onetoc2 files received from untrusted sources is affected. Users who only ever parse their own notebooks are not at meaningful risk. The issue is fixed in onenote_parser 1.1.1. The fix rejects absolute paths, parent-directory components, and other invalid path characters in entry names, and additionally canonicalises the resolved path to confirm it stays inside the notebook's base directory. For users who cannot upgrade to 1.1.1, only call `Parser::parse_notebook` on `.onetoc2` files from trusted sources. Alternatively, use `Parser::parse_section` / `Parser::parse_section_buffer` on individual .one files, which do not perform the directory walk.

Exploitation Scenario

An attacker crafts a `.onetoc2` table-of-contents file whose internal entry names contain path-traversal sequences (e.g. `../../../../etc/passwd` or a Windows device path) and delivers it to a target — for example, uploading it to a document-ingestion pipeline that accepts OneNote exports for indexing, or emailing it to a user whose workflow feeds notebooks into an AI agent's file-processing tool. When the victim system calls `Parser::parse_notebook` on the file, the parser joins the malicious entry name to the notebook's base directory and attempts to open the resulting path. Since the parser aborts once it finds the target isn't a valid OneNote section, the attacker can't reliably read file contents back, but they can use the differing failure behavior (or timing) to probe whether specific files exist on the host, or point the traversal at a large or special file to trigger a hang or resource-exhaustion denial-of-service in the ingestion pipeline.

Weaknesses (CWE)

CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Primary CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

CWE-22 — Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'): The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.

[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
[Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Source: MITRE CWE corpus.