Summary
NLTK: Missing Post-Download Integrity Verification Allows Malicious Package Injection
NLTK's package downloader in nltk/downloader.py does not verify file integrity after download and before extraction.
The download flow at lines 789-825:
- File is downloaded to a temp path via HTTP
- os.replace(tmp_filepath, filepath) moves it to the final location (line 799)
- Extraction begins via _unzip_iter() (line 825)
Between steps 2 and 3, there is no SHA-256 verification. The checksum logic exists in _pkg_status() (lines 982-1015) but it is only used BEFORE download as a status check ("is this package already installed and up-to-date?"). It is never called after download to verify the file that was actually received.
Attack vectors:
- MITM during HTTP download (NLTK downloads from http:// by default on some mirrors)
- Race condition on shared filesystems (attacker replaces file between os.replace and _unzip_iter)
- DNS poisoning redirecting to attacker-controlled server
PoC:
import nltk
import unittest.mock
import zipfile
import io
import os
# Create a malicious zip that will be "downloaded"
malicious_zip = io.BytesIO()
with zipfile.ZipFile(malicious_zip, 'w') as zf:
zf.writestr('punkt_tab/tokenizers/punkt_tab/english.pickle',
b'MALICIOUS PAYLOAD - attacker controlled content')
# Patch urllib to return our malicious zip
with unittest.mock.patch('urllib.request.urlopen') as mock_urlopen:
mock_response = unittest.mock.MagicMock()
mock_response.read.return_value = malicious_zip.getvalue()
mock_response.headers = {'Content-Length': str(len(malicious_zip.getvalue()))}
mock_urlopen.return_value = mock_response
# Download proceeds, no integrity check catches the swap
# nltk.download('punkt_tab') # Would install attacker payload
This is distinct from CVE-2024-39705 (pickle deserialization via download) and CVE-2025-14009 (zip-slip path traversal). Those address what happens AFTER extraction. This finding addresses the gap BEFORE extraction where integrity is never verified.
Suggested fix: After os.replace() and before _unzip_iter(), compute SHA-256 of the final file and compare against the expected checksum from the package index. Reject and delete the file if the hash does not match.
Impact
CVE-2026-12259 has a CVSS score of 5.3 (Medium). The vector is network-reachable, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (3.9.3); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-12259? CVE-2026-12259 is a medium-severity security vulnerability in nltk (pip), affecting versions <= 3.9.2. It is fixed in 3.9.3.
- How severe is CVE-2026-12259? CVE-2026-12259 has a CVSS score of 5.3 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of nltk are affected by CVE-2026-12259? nltk (pip) versions <= 3.9.2 is affected.
- Is there a fix for CVE-2026-12259? Yes. CVE-2026-12259 is fixed in 3.9.3. Upgrade to this version or later.
- Is CVE-2026-12259 exploitable, and should I be worried? Whether CVE-2026-12259 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-12259 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-12259? Upgrade
nltkto 3.9.3 or later.