Affected: Homebrew: acronym

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(tmp_filepath, filepath) moves it to the final location (line 799) 3. 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: 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 _unzip_iter) 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" 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 = {'C…

In nltk version 3.9.4, the `nltk.downloader.Downloader._download_package()` function writes downloaded package bytes to disk and may extract them before enforcing SHA-256 or MD5 checksum validation. This allows an attacker to tamper with the package response body for `info.url` through a compromised mirror, malicious proxy, or other source-substitution condition, leading to the installation of attacker-controlled package bytes. The vulnerability can result in malicious corpus or model content being trusted by downstream users or applications.

Affected: PyPI: nltk

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(tmp_filepath, filepath) moves it to the final location (line 799) 3. 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: 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 _unzip_iter) 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" 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 = {'C…

Affected: Ubuntu:Pro:14.04:LTS: nltk, Ubuntu:Pro:16.04:LTS: nltk, Ubuntu:Pro:18.04:LTS: nltk, Ubuntu:Pro:20.04:LTS: nltk, Ubuntu:Pro:22.04:LTS: nltk, Ubuntu:Pro:24.04:LTS: nltk, Ubuntu:Pro:26.04:LTS: nltk

In nltk version 3.9.4, the `nltk.downloader.Downloader._download_package()` function writes downloaded package bytes to disk and may extract them before enforcing SHA-256 or MD5 checksum validation. This allows an attacker to tamper with the package response body for `info.url` through a compromised mirror, malicious proxy, or other source-substitution condition, leading to the installation of attacker-controlled package bytes. The vulnerability can result in malicious corpus or model content being trusted by downstream users or applications.