Live › vulnerability › CVE-2026-12259
Go to dashboardNLTK's downloader does not verify a SHA-256 checksum on downloaded data packages before extracting them. An attacker who can tamper with a download, through a man-in-the-middle position, a plain-HTTP mirror, DNS poisoning, or a race on a shared filesystem, can get a malicious package installed in place of the real one.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-27 08:02 UTC, 0h before NVD. All times on this page are UTC.
Teams that run nltk.download at install or build time, or at runtime, on networks where traffic can be intercepted, or that use mirrors served over plain HTTP. Systems that shared a writable data directory are also exposed to the race-condition variant. Teams with NLTK data baked into a reviewed image and no runtime downloads have less exposure.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| nltk | pypi | <= 3.9.2 | 3.9.3 |
| nltk | vendor | = 3.9.4 | – |
pip show nltk and check whether the version is 3.9.2 or lower.nltk.download fetches from any http:// mirror in your environment.3.9.3 or later with pip install --upgrade nltk==3.9.3.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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:
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:
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-12259")
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.