GHSA-5wp5-5229-5g6q: Path Traversal
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: 1. File is downloaded to a temp path via HTTP 2. os.replace(tmpfilepath, filepath) moves it to the final location (line 799) 3. Extraction begins via unzipiter() (line 825)
Between steps 2 and 3, there is no SHA-256 verification. The checksum logic exists in pkgstatus() (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: 1. MITM during HTTP download (NLTK downloads from http:// by default on some mirrors) 2. Race condition on shared filesystems (attacker replaces file between os.replace and unzipiter) 3. DNS poisoning redirecting to attacker-controlled server
PoC: python import nltk import unittest.mock import zipfile import io import os
Create a malicious zip that will be "downloaded" maliciouszip = io.BytesIO() with zipfile.ZipFile(maliciouszip, 'w') as zf: zf.writestr('punkttab/tokenizers/punkttab/english.pickle', b'MALICIOUS PAYLOAD - attacker controlled content')
Patch urllib to return our malicious zip with unittest.mock.patch('urllib.request.urlopen') as mockurlopen: mockresponse = unittest.mock.MagicMock() mockresponse.read.returnvalue = maliciouszip.getvalue() mockresponse.headers = {'Content-Length': str(len(maliciouszip.getvalue()))} mockurlopen.returnvalue = mockresponse # Download proceeds, no integrity check catches the swap # nltk.download('punkttab') # 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 unzipiter(), 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/nltkto a version that resolves this vulnerability.Fixed in 3.9.3 - Configuration
Add SHA-256 verification immediately after os.replace(tmp_filepath, filepath) (line 799) and before extraction begins via _unzip_iter() (line 825). If the computed SHA-256 hash does not match the expected checksum, delete/reject the file so extraction never proceeds.
NLTK downloader (nltk/downloader.py) Integrity verification between os.replace() and _unzip_iter() = Compute SHA-256 of the final downloaded file and compare it to the expected checksum from the package index; if mismatch, reject and delete the file before extraction
Event History
Frequently Asked Questions
Who is most exposed to this issue?
Deployments that use the NLTK downloader over HTTP, including mirrors that default to HTTP, are exposed to network-path attacks such as man-in-the-middle interception or DNS poisoning. Environments using shared filesystems are also exposed if an attacker can replace the downloaded file after it is moved into place and before extraction begins.
What does an attacker need to exploit it?
An attacker needs the ability to influence the downloaded package archive, such as by intercepting an HTTP download, redirecting the download through DNS poisoning, or winning the replacement race on a shared filesystem. User interaction is required according to the supplied CVSS vector.
Does the downloader validate the archive it actually downloads before extracting it?
No. The existing checksum logic is used only to assess the status of an already installed package before download; it is not invoked after the new file is downloaded and moved to its final path. The archive can therefore be extracted without SHA-256 verification of the received file.