NLTK versions before 3.10.2 contain a symlink-based sandbox bypass in FramenetCorpusReader

CVE-2026-62384 affects NLTK versions before 3.10.2. The flaw lives in FramenetCorpusReader — specifically the frame_by_name(), _lu_file(), and doc() methods. An attacker who can write to the corpus subdirectory on disk can plant a symlink whose name contains no path separators. When the reader processes that filename, it passes the lexical path-validation check (nltk.pathsec) but the OS resolves the symlink to a file outside the corpus root, letting the attacker read arbitrary XML-parseable files. The affected scope is NLTK < 3.10.2, fixed in 3.10.2.

The vendor labels this HIGH 7.5 with CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. That vector is misleading. The attack requires the ability to create symlinks inside the corpus directory on the local filesystem — that is fundamentally a local-access prerequisite, not a network one. The only plausible remote vector is tricking a user into installing a malicious corpus package that embeds symlinks, which is a supply-chain social-engineering step the CVSS doesn't price in. The confidentiality impact is further limited to files that are valid XML. No integrity or availability impact exists. The vendor severity overstates the real-world risk.

Why this verdict

• AV:N is wrong — this is a local-access bug. The attacker must create symlinks on the target filesystem inside the corpus directory. The only remote path is via a trojanized corpus package, which is a separate supply-chain social-engineering attack not captured in the CVSS.
• FramenetCorpusReader is niche. FrameNet is an academic linguistics dataset. The fraction of NLTK's 50M+ monthly installs that actively use FramenetCorpusReader in production services exposed to untrusted input is vanishingly small — likely well under 1%.
• XML-only read limits blast radius. The exfiltrated file must parse as valid XML. High-value targets like /etc/shadow, database credentials files, and most config files are not XML, severely limiting what an attacker can steal.
• Role multiplier: NLTK is a library, not infrastructure. It does not occupy any high-value role (not an IdP, hypervisor, backup agent, network edge, CI/CD server, or security agent). In its most common deployment — data-science workstations and Jupyter notebooks — a local attacker who can write to ~/nltk_data already has equivalent or greater read access. In rare ML-pipeline server deployments, the FramenetCorpusReader is unlikely to be in the code path. No high-value-role floor applies.
• No exploitation signals. Zero KEV listing, no known PoCs, EPSS at 0.66%. Two days post-disclosure with no attacker interest.

Why not higher?

Upgrading to HIGH would require either a genuine unauthenticated remote attack path or exploitation in a high-value-role component. Neither applies: the network vector is a CVSS labeling error (symlink creation is local), FramenetCorpusReader is an academic corpus reader not found in identity/infrastructure roles, and the read-only XML-constrained impact does not reach code execution or domain compromise.

Why not lower?

Despite heavy friction, this is a real sandbox bypass in a widely-installed library (50M+ downloads/month). A trojanized corpus package distributed through a compromised NLTK data mirror *could* weaponize this without direct host access. The confidentiality impact on XML-formatted files (which includes many application configs, Maven POMs, Spring configs, and .csproj files) is non-trivial. Dropping to LOW would undercount the supply-chain angle.

1. Upgrade NLTK to 3.10.2 — The definitive fix. Run pip install --upgrade nltk>=3.10.2 across all environments. Since this is assessed as MEDIUM, the noisgate remediation SLA gives you 365 days, but given the trivial upgrade path, aim to roll it into your next dependency-update cycle.
2. Restrict write access to NLTK corpus directories — Ensure ~/nltk_data and any shared corpus paths are owned by the application user with mode 0755 (not world-writable). On shared research servers, use per-user corpus roots. This eliminates the symlink-planting prerequisite entirely.
3. Pin corpus data sources — If you use nltk.download() in CI/CD or automated pipelines, pin to the official NLTK data server and verify checksums. Do not accept corpus packages from untrusted mirrors or user uploads.
4. Enable file-integrity monitoring on corpus directories — Deploy FIM (OSSEC, Wazuh, auditd) rules to alert on symlink creation inside NLTK corpus directories. This provides detection of exploitation attempts.

Run this script on any host where NLTK is installed. It checks the installed NLTK version against the fix. No special privileges required. Invoke with: python check_cve_2026_62384.py

#!/usr/bin/env python3
"""Check for CVE-2026-62384: NLTK FramenetCorpusReader symlink sandbox bypass.
Affected: NLTK < 3.10.2
Fixed: NLTK >= 3.10.2
"""
import sys

try:
    import nltk
except ImportError:
    print("UNKNOWN - NLTK is not installed on this system.")
    sys.exit(2)

try:
    from packaging.version import Version
except ImportError:
    # fallback to distutils (deprecated but available in older Pythons)
    from distutils.version import LooseVersion as Version

installed = nltk.__version__
fixed = "3.10.2"

try:
    if Version(installed) < Version(fixed):
        print(f"VULNERABLE - NLTK {installed} is installed (fix: >= {fixed}). CVE-2026-62384 applies.")
        sys.exit(1)
    else:
        print(f"PATCHED - NLTK {installed} is installed (fix: >= {fixed}). CVE-2026-62384 does not apply.")
        sys.exit(0)
except Exception as e:
    print(f"UNKNOWN - Could not compare versions: {e}")
    sys.exit(2)

Sources

1. OffSeq Threat Radar — CVE-2026-62384
2. GitLab Advisory Database — NLTK CVE-2026-12074 (related FrameNet path traversal)
3. NLTK GitHub Releases
4. NLTK Zip-Slip Fix PR #3468
5. PyPI — NLTK
6. NLTK Official Data Installation Guide
7. PyPI Download Stats — NLTK