CVE-2025-14009

What it actually does

The NLTK downloader extracts third-party ZIP corpora with zipfile.extractall() and no member-path canonicalization or allow-list checks. A crafted archive can write files outside the intended nltk_data tree (zip-slip/path traversal). Python modules dropped onto import paths—especially package __init__.py files—are executed on subsequent import, producing arbitrary code execution as the NLTK-hosting process, with changed scope and high impact on confidentiality, integrity, and availability.

Why it matters to the business

Workstations, CI jobs, and production NLP services that fetch NLTK data can be fully compromised, exposing source, models, credentials, and downstream dependents. EPSS remains low (about 0.0095, up roughly 20% over 30 days) and the issue is not in CISA KEV and is not associated with ransomware, but the library’s wide use in language-processing stacks still makes unpatched download paths a high operational risk. Inventory also flags Red Hat spice-client-win, spice-client-win-x64, and spice-client-win-x86 on RHEL AUS 8.2 AppStream as affected, so remote-display client fleets share patch urgency even though in-the-wild exploitation is not reported.

How an attack unfolds

An attacker supplies a ZIP packaged as an NLTK data corpus whose internal names escape the extraction root. When an application or user calls the NLTK downloader (default or custom index), the archive is fetched and unpacked without path validation. Traversal writes land outside nltk_data; if they include importable Python, the interpreter loads them automatically and runs attacker-controlled code with the privileges of the downloading process. From there the attacker can read local files, reach the network, and install persistence. No named threat actors or mature public exploits are associated with this issue; abuse depends on controlling or spoofing the package source the downloader trusts.

How to fix it

On RHEL AUS 8.2 AppStream, upgrade spice-client-win, spice-client-win-x64, and spice-client-win-x86 to 0:8.10-3.el8_2.1. For NLTK, stop using the built-in downloader against untrusted indexes; vendor-pin and integrity-check corpora (hashes/signatures), extract only into a dedicated low-privilege directory, and apply upstream NLTK releases as soon as a downloader with path-validated extraction is available. Until then, pre-stage data offline, block outbound fetches from production, and run any remaining downloads in isolated, non-root jobs that cannot write onto application import paths.

How to confirm the fix worked

Confirm RH packages report 0:8.10-3.el8_2.1 (or later) via the platform package manager. Inventory every environment that imports nltk and determine whether nltk.download, Downloader, or custom download_dir usage remains. Review nltk/downloader.py _unzip_iter (and equivalent) for member-path normalization, rejection of absolute paths and parent-directory segments, and avoidance of raw extractall. Verify corpora are populated from an internal verified cache rather than live Internet fetches, and that the nltk_data tree and its parents are not writable by the runtime user. Do not validate with crafted traversal archives.

Typical attack path

1. Obtain influence over an NLTK package source the victim will use (malicious index, mirror tampering, or a substituted archive).
2. Deliver a ZIP whose member names escape the intended extraction directory.
3. Wait for nltk.download or equivalent to fetch and extract the archive with unsanitized extractall.
4. Rely on written Python modules being imported during later NLTK or application use.
5. Use the resulting process-level code execution for data access, persistence, or further movement.

How to detect it

Assume possible historical exposure wherever NLTK has been allowed to download packages. Review application, notebook, CI, and package-manager logs around nltk.download / Downloader usage, especially to non-default indexes or download_dir values. On disk, compare nltk_data and parent directories against a known-good corpus list; look for unexpected .py/.so/.pyd files, extra __init__.py, or writes outside the package tree. Correlate Python processes that recently fetched ZIPs with subsequent unusual child processes, outbound connections, or persistence artifacts. No named APT campaigns or ransomware families are tied to this CVE, so hunt on behavior and filesystem anomalies rather than actor-specific infrastructure.

• nltk.download(
• nltk.downloader
• _unzip_iter
• zipfile.extractall
• nltk_data
• download_dir
• __init__.py written outside expected nltk package directories
• ZIP member names containing ../ or ..\ during NLTK extract
• python process fetching .zip then spawning unexpected children

What your security team should do

• Patch listed spice-client-win packages to 0:8.10-3.el8_2.1 on RHEL AUS 8.2 immediately and inventory all NLTK usage, including transitive and notebook/CI paths.
• Disable or firewall NLTK’s network downloader in production; serve corpora from an internal, integrity-checked cache.
• Constrain the runtime user so it cannot write outside a dedicated data directory or onto sys.path.
• Hunt for unexpected files adjacent to nltk_data and for download activity from unapproved indexes; treat hits as potential prior abuse.
• Track upstream NLTK for a path-safe extractor and EPSS/KEV changes; the score is rising, even if still low.