CVE-2026-33236

What it actually does

NLTK’s package downloader trusts the subdir and id fields in remote XML indexes without canonicalizing or rejecting path separators. A hostile index can therefore cause the client to create directories, create files, or overwrite existing files outside the intended NLTK data tree during a download, with integrity and availability impact on the local filesystem. Confidentiality of existing files is not directly disclosed by this flaw.

Why it matters to the business

Any developer workstation, notebook environment, CI runner, or production NLP service that still uses NLTK 3.9.3 or earlier and fetches corpora from a remote index can have application code, configs, or runtime files overwritten, causing outages, poisoned models or datasets, and a foothold for follow-on tampering. The issue is not in CISA KEV and public exploit maturity is none, but it has been public for about 193 days and EPSS has risen from 0.0058 to 0.0071 (+23% over 30 days), so unpatched Python NLP estates remain an unnecessary integrity risk.

How an attack unfolds

An attacker first needs the victim to load an untrusted NLTK package index (hostile mirror, compromised internal index, or social-engineering a user to point the downloader at an attacker URL). When the user or an automated job then downloads listed packages, the client applies attacker-controlled subdir and id values as filesystem paths. Because those values are not validated, writes land outside the normal data directory, creating or replacing files the process can write. The attacker does not need local privileges beyond whatever the NLTK process already has; user interaction (initiating a download or accepting a custom index) is required per the CVSS vector. No named threat actors or ransomware campaigns are associated with this CVE.

How to fix it

Upgrade NLTK off 3.9.3 and all prior releases to a build that includes commit 89fe2ec2c6bae6e2e7a46dad65cc34231976ed8a (the published patch). Pin dependencies so CI and production cannot silently reinstall 3.9.3 or older. Until every environment is upgraded, disable or avoid the remote downloader: vendor required corpora into images, use only a tightly controlled internal index, and do not configure custom index URLs. Restrict filesystem permissions of the account that runs NLTK so a download cannot overwrite application, config, or credential paths.

How to confirm the fix worked

Inventory Python environments for nltk==3.9.3 or lower (pip freeze, poetry.lock, uv.lock, conda lists, container SBOM). Confirm installed code contains the path-sanitization from commit 89fe2ec2c6bae6e2e7a46dad65cc34231976ed8a. After upgrade, run a normal corpus download against a trusted index and verify new files appear only under the configured nltk_data directory. Review downloader configuration and CI logs for non-default index URLs.

Typical attack path

1. Stand up or compromise an NLTK-compatible remote XML package index
2. Cause a user or pipeline to use that index (custom downloader URL, poisoned docs, or internal mirror takeover)
3. Wait for or induce an NLTK data download using versions 3.9.3 or earlier
4. Rely on unsanitized subdir/id fields so extracted or written files land outside the intended nltk_data location
5. Overwrite or plant files the NLTK process can write in order to disrupt the app or prepare later execution

How to detect it

This CVE has no public exploit maturity and no named actor reporting, so look for suspicious downloader use rather than a known payload. Review package-manager and container logs for nltk 3.9.3 or older still in use after 2026-03-20. Inspect application, CI, and notebook logs for NLTK downloader activity against unexpected index hosts, failed or unusually located file writes during corpus download, and new files appearing outside the standard nltk_data tree around download time. On endpoints, correlate python/python3 processes importing nltk.downloader with outbound HTTP(S) to non-standard index URLs and subsequent file-create events in application, home, or system directories. Absence of those artifacts does not prove non-exploitation if logging of Python file I/O is weak.

• nltk.downloader
• nltk-3.9.3
• nltk==3.9.3
• nltk_data
• Downloader.download
• xml index
• Collection.subdir
• python -m nltk.downloader

What your security team should do

• Patch or rebuild every image and lockfile still on NLTK 3.9.3 or earlier as a high-integrity item even though this is not KEV
• Block or alert on NLTK processes contacting non-official package-index hosts
• Vendor NLTK data into build artifacts so runtime downloaders are unused
• Hunt developer laptops, notebooks, and CI runners first—they are the most likely to hit remote indexes
• Re-scan after the EPSS uptick; treat remaining 3.9.3 installs as overdue given ~193 days since publication