CVE-2026-126295: Path Traversal and Unconfined File Access in NLTK BllipParser

The Natural Language Toolkit (NLTK) provides Python interfaces to various natural language processing models and external native libraries. Starting in NLTK 3.10.0, the library introduced a centralized path security subsystem (nltk.pathsec) designed to confine all file-backed resources and external tool models within configured NLTK data directories (nltk_data). This security boundary prevents applications that pass dynamically resolved or user-influenced model identifiers to NLTK wrappers from accessing arbitrary files on the host operating system.

CVE-2026-126295 (GHSA-fg9w-wfp5-j933) stems from an incomplete implementation of this path confinement architecture in nltk/parse/bllip.py. The BllipParser class serves as NLTK's wrapper around the Charniak-Johnson reranking syntactic parser, implemented via the bllipparser native C/C++ extension (RerankingParser). During the security hardening introduced in version 3.10.0, sibling wrappers such as CRFTagger, HunposTagger, StanfordTagger, and MaltParser were updated to validate all model paths using nltk.pathsec functions before invoking native code or external binaries. However, nltk/parse/bllip.py was omitted from this refactoring.

Because BllipParser performs no path validation, any filesystem path passed to the BllipParser.__init__() constructor (parser_model, reranker_features, reranker_weights) or the BllipParser.from_unified_model_dir() class method (model_dir) is forwarded directly to the underlying C extension. The native extension subsequently executes OS-level open() and read() system calls on the unvalidated paths without confinement checks, ownership verification, file type restrictions, or size limits.

This vulnerability is classified primarily under CWE-22 (Improper Limitation of a Pathname to a Restricted Directory), alongside CWE-73 (External Control of File Name or Path) and CWE-400 (Uncontrolled Resource Consumption). In applications where caller-influenced arguments reach BllipParser, an attacker can bypass nltk_data confinement to read arbitrary files, leak file contents or existence metadata via parser error diagnostics, hang application processes by targeting blocking special files (such as named pipes or device nodes), or trigger out-of-memory conditions by loading oversized files.

To understand the root cause of CVE-2026-126295, it is necessary to examine how NLTK enforces path security across native extensions. Standard Python file operations inside NLTK can be intercepted or wrapped using nltk.pathsec.open(). However, third-party C extensions and external command-line binaries accept file path strings and perform their own file descriptor operations directly through operating system syscalls. To secure these interfaces, nltk.pathsec exposes validate_tool_path() and validate_tool_dir().

These validation helpers enforce several critical security invariants before returning a canonicalized string path to be passed to native code:

• Data-Root Confinement: The target path must resolve within one of the trusted nltk.data.path root directories, rejecting path traversal sequences (..), absolute paths outside the roots, URLs, and command-line option patterns.
• Ownership and Permission Verification (require_private=True): The target file or directory must not reside in world-writable or shared locations (such as /tmp) where another local user could plant or replace a model file.
• File Type Enforcement: For file loaders, validate_tool_path() verifies that the target is a regular, single-linked file (utilizing O_NOFOLLOW semantics), explicitly rejecting symbolic links, directories, sockets, device nodes, and named pipes (FIFOs).
• Resource Bounding (max_bytes=MAX_TOOL_MODEL_BYTES): The file size is checked against a strict upper bound prior to loading, preventing native buffers from allocating excessive memory.

In NLTK versions 3.10.0 through 3.10.3, nltk/parse/bllip.py failed to import any symbols from nltk.pathsec. In BllipParser.__init__(), the parameters parser_model, reranker_features, and reranker_weights were passed directly into self.rrp.load_parser_model() and self.rrp.load_reranker_model(). Similarly, in BllipParser.from_unified_model_dir(), the model_dir parameter was passed directly into bllipparser.Model.get_unified_model_parameters(model_dir), a third-party helper that constructs sub-paths under model_dir without checking NLTK data roots, and then passes those sub-paths into BllipParser.__init__().

Furthermore, passing unvalidated os.PathLike objects directly to multiple downstream consumers introduces a Time-of-Check to Time-of-Use (TOCTOU) risk at the Python object layer. If a custom PathLike object implements a stateful __fspath__() method that returns a benign path on its first invocation and a malicious path on subsequent invocations, validating the object without capturing and passing the resulting canonical str allows the object to swap the underlying path when the C extension later resolves it.

A structural comparison between nltk/parse/bllip.py and other native wrappers in NLTK prior to version 3.10.4 highlights the omission. While nltk/tag/crf.py, nltk/tag/hunpos.py, nltk/tag/stanford.py, and nltk/parse/malt.py all invoked validate_tool_path(), nltk/parse/bllip.py contained no references to nltk.pathsec.

In the vulnerable versions (3.10.0 through 3.10.3), BllipParser.__init__() and from_unified_model_dir() were implemented as follows:

# Vulnerable implementation in nltk/parse/bllip.py (NLTK 3.10.0 - 3.10.3)
from nltk.parse.api import ParserI
from nltk.termsec import safe_print
from nltk.tree import Tree
 
class BllipParser(ParserI):
    def __init__(
        self,
        parser_model=None,
        reranker_features=None,
        reranker_weights=None,
        parser_options=None,
        reranker_options=None,
    ):
        _ensure_bllip_import_or_error()
 
        parser_options = parser_options or {}
        reranker_options = reranker_options or {}
 
        # VULNERABILITY: Paths are passed directly to the native C extension
        # without confinement, file type, ownership, or size validation.
        self.rrp = RerankingParser()
        self.rrp.load_parser_model(parser_model, **parser_options)
        if reranker_features and reranker_weights:
            self.rrp.load_reranker_model(
                features_filename=reranker_features,
                weights_filename=reranker_weights,
                **reranker_options,
            )
 
    @classmethod
    def from_unified_model_dir(
        cls,
        model_dir,
        parser_options=None,
        reranker_options=None,
        parsing_options=None,
    ):
        _ensure_bllip_import_or_error()
        # VULNERABILITY: model_dir is not validated before deriving sub-paths.
        (
            parser_model_dir,
            reranker_features_filename,
            reranker_weights_filename,
        ) = get_unified_model_parameters(model_dir)
        return cls(
            parser_model_dir,
            reranker_features_filename,
            reranker_weights_filename,
            parser_options,
            reranker_options,
        )

In commit fdde6d9ebf5fd612e817b49ec7fecd752802c268, the maintainers resolved the vulnerability by importing MAX_TOOL_MODEL_BYTES, validate_tool_dir, and validate_tool_path from nltk.pathsec and applying strict validation to all path arguments before they reach the C extension:

# Patched implementation in nltk/parse/bllip.py (NLTK 3.10.4)
from nltk.parse.api import ParserI
from nltk.pathsec import (
    MAX_TOOL_MODEL_BYTES,
    validate_tool_dir,
    validate_tool_path,
)
from nltk.termsec import safe_print
from nltk.tree import Tree
 
# Inside BllipParser.__init__():
        if parser_model is not None:
            # parser_model designates a directory containing model files.
            # validate_tool_dir enforces data-root confinement and require_private=True
            # prevents local attackers from planting models in shared directories.
            parser_model = validate_tool_dir(
                parser_model,
                context="BllipParser parser model",
                require_private=True,
            )
        if reranker_features and reranker_weights:
            # Reranker features and weights are individual files read into memory.
            # validate_tool_path enforces confinement, regular file status, ownership,
            # and bounds file size to MAX_TOOL_MODEL_BYTES.
            reranker_features = validate_tool_path(
                reranker_features,
                context="BllipParser reranker features",
                max_bytes=MAX_TOOL_MODEL_BYTES,
                require_private=True,
            )
            reranker_weights = validate_tool_path(
                reranker_weights,
                context="BllipParser reranker weights",
                max_bytes=MAX_TOOL_MODEL_BYTES,
                require_private=True,
            )
 
        self.rrp = RerankingParser()
        # The C extension is invoked using the validated string variables returned
        # by pathsec, preventing stateful PathLike __fspath__ swapping.
        self.rrp.load_parser_model(parser_model, **parser_options)
        if reranker_features and reranker_weights:
            self.rrp.load_reranker_model(
                features_filename=reranker_features,
                weights_filename=reranker_weights,
                **reranker_options,
            )
 
# Inside BllipParser.from_unified_model_dir():
        # Validate model_dir up front before the third-party helper derives sub-paths.
        model_dir = validate_tool_dir(
            model_dir,
            context="BllipParser unified model directory",
            require_private=True,
        )
        (
            parser_model_dir,
            reranker_features_filename,
            reranker_weights_filename,
        ) = get_unified_model_parameters(model_dir)

The fix is comprehensive and addresses both direct constructor invocations and factory method calls. By validating model_dir in from_unified_model_dir() prior to calling get_unified_model_parameters(model_dir) and subsequently re-validating the derived parser_model_dir, reranker_features_filename, and reranker_weights_filename inside __init__(), the patch implements defense-in-depth. Furthermore, rebinding the parameter names (parser_model, reranker_features, reranker_weights, and model_dir) to the str values returned by the validation functions ensures that any custom PathLike object cannot alter its path representation between validation and native open() execution.

Exploiting CVE-2026-126295 requires two primary prerequisites: the target environment must have the optional bllipparser native extension installed (pip install bllipparser), and the target application must pass attacker-controlled or externally influenced strings as model path arguments to BllipParser() or BllipParser.from_unified_model_dir(). If bllipparser is not installed, calling these methods immediately raises an ImportError via _ensure_bllip_import_or_error() before any filesystem interaction occurs.

When these prerequisites are met, an attacker can exploit the missing boundary checks through three primary vectors:

1. Arbitrary File Read and Diagnostic Oracle Disclosure: By supplying a path to a sensitive file or directory outside the NLTK data roots (such as /etc/passwd, application configuration files, or private keys) via parser_model, reranker_features, or reranker_weights, the attacker forces the C extension to open and parse the target file. When the target file does not conform to the expected Charniak-Johnson parser or reranker model format, the native parser throws exceptions or emits error diagnostics. If the host application returns or logs these exceptions, an attacker can differentiate between non-existent paths, unreadable paths, and valid files, or extract fragments of file contents tokenized within parser syntax error messages.

2. Denial of Service via Blocking Special Files: Because BllipParser does not verify that the target path is a regular file prior to opening it, an attacker can point reranker_features or parser_model sub-files at blocking special files on Unix-like systems, such as an empty named pipe (FIFO) created in /tmp, /dev/random, or /dev/zero. When the C extension calls open() or read() on a blocking FIFO with no writer, the underlying OS thread blocks indefinitely inside the native C call, bypassing Python-level timeouts and hanging the application worker process.

3. Denial of Service via Memory Exhaustion and Local Tampering: By supplying a path to an arbitrarily large file (or an infinite stream device such as /dev/urandom), the attacker bypasses the MAX_TOOL_MODEL_BYTES check, causing the native loader to allocate unbounded memory until the process terminates via an Out-Of-Memory (OOM) crash. Additionally, in multi-user local environments, the absence of require_private=True allows a local attacker to place crafted or corrupted model files in world-writable directories (such as /tmp or /var/tmp) and induce the target process to load them.

# Proof of Concept: Demonstrating Unconfined File Access and Blocking DoS
# Prerequisites: nltk >= 3.10.0, < 3.10.4 and bllipparser installed
 
import os
from nltk.parse.bllip import BllipParser
 
# Vector 1: Arbitrary file access / Error oracle outside nltk_data roots
untrusted_path = "/etc/passwd"
try:
    # In vulnerable versions, this bypasses nltk.pathsec and invokes OS open() directly
    parser = BllipParser(parser_model="/etc", reranker_features=untrusted_path, reranker_weights=untrusted_path)
except Exception as exc:
    # In a patched version (3.10.4+), nltk.pathsec raises a security exception before touching the OS.
    # In vulnerable versions (3.10.0-3.10.3), the native C extension opens the file and fails during parsing.
    print(f"Exception raised: {type(exc).__name__}: {exc}")
 
# Vector 2: Denial of Service via Named Pipe (FIFO)
fifo_path = "/tmp/blocking_model_fifo"
if not os.path.exists(fifo_path):
    os.mkfifo(fifo_path)
 
# Calling BllipParser on a FIFO with no writer hangs the native C extension indefinitely:
# BllipParser(parser_model="/tmp", reranker_features=fifo_path, reranker_weights=fifo_path)

The severity of CVE-2026-126295 is rated as High, with a CVSS v3.1 base score of 7.1 (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:L) according to the GitHub Security Advisory, and a CVSS v4.0 base score of 7.0 (CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:L/SC:N/SI:N/SA:N) assigned by VulnCheck.

A breakdown of the CVSS vector components reflects the technical constraints and consequences of the vulnerability:

• Attack Vector (AV:L): The attack vector is classified as Local because path traversal and local file manipulation rely on accessing the local filesystem or supplying paths in local/CLI execution contexts, though web applications that expose model selection parameters over a network interface would experience remote reachability.
• Attack Complexity (AC:L) & Privileges Required (PR:N): Triggering the unconfined file access requires no special privileges or complex race conditions once an input path reaches BllipParser.
• Confidentiality Impact (C:H / VC:H): High confidentiality impact reflects the ability to bypass nltk.pathsec confinement and read arbitrary files accessible to the application process permissions.
• Integrity Impact (I:N / VI:N): The vulnerability does not grant direct file write capabilities.
• Availability Impact (A:L / VA:L): Low availability impact accounts for worker thread hangs on special files and memory exhaustion from unbounded file reads.

From a threat intelligence perspective, CVE-2026-126295 is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog. The Exploit Prediction Scoring System (EPSS) assigns this vulnerability a score of 0.00197 (approximately 0.20% probability of exploitation within 30 days), placing it in the 9.56th percentile of all tracked CVEs. The low likelihood of widespread opportunistic exploitation is primarily due to two limiting factors: bllipparser is an optional dependency that is not installed by default with nltk, and most production NLP pipelines hardcode static model paths rather than exposing BllipParser path initialization to untrusted user input.

The primary remediation for CVE-2026-126295 is to upgrade the nltk package to version 3.10.4 or later. Version 3.10.4 incorporates commit fdde6d9ebf5fd612e817b49ec7fecd752802c268, which enforces validate_tool_dir() and validate_tool_path() across all BllipParser initialization routines.

pip install --upgrade "nltk>=3.10.4"

After upgrading, ensure that all legitimate BLLIP parser models used by the application are stored inside configured nltk_data directories (or directories explicitly added to nltk.data.path) and are owned by a trusted user account without world-writable permissions. Because require_private=True is enforced in version 3.10.4+, attempting to load models from shared temporary directories such as /tmp will be rejected by nltk.pathsec.

> [!NOTE] > If an immediate upgrade to NLTK 3.10.4 is not feasible, development teams must implement strict application-level input validation before instantiating BllipParser.

For environments where upgrading cannot be performed immediately, apply the following defense-in-depth measures:

1. Avoid Passing Raw Paths: Never pass user-supplied strings, HTTP request parameters, or unverified configuration values directly into BllipParser() or BllipParser.from_unified_model_dir().
2. Use Strict Allowlists: Map user-facing model selection identifiers against a hardcoded dictionary of known, static filesystem paths pointing strictly inside dedicated model directories.
3. Pre-Validate with nltk.pathsec: In NLTK 3.10.0 through 3.10.3, the nltk.pathsec module is already present in the library even though bllip.py does not call it. Applications can manually invoke nltk.pathsec.validate_tool_dir() and nltk.pathsec.validate_tool_path() on any model paths prior to passing the returned strings to BllipParser.