Skip to content

GHSA-5wp5-5229-5g6q CVE-2026-12259 CVE-2026-63310 GHSA-gf32-cmjh-8m9v PYSEC-2026-3729 PYSEC-2026-4318

NLTK: Missing Post-Download Integrity Verification Allows Malicious Package Injection

Medium PyPI
Severity
0.0 / 10
Medium · CVSS 4.0
Exploit chance (EPSS)
0.10%
Chance of exploitation in the next 30 days. Higher than 0.89% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-494 Download of Code Without Integrity Check
Fix
3.9.3
Upgrade nltk to this version or later

Description

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:

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.

Affected versions

PyPI

PackageVulnerableFixed in
nltk
< 3.9.3
3.9.3
nltk
<= 3.9.2
No fix yet
nltk
<= 3.9.4
No fix yet

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

nltk PyPI → 3.9.3

pip
pip install --upgrade "nltk>=3.9.3"
poetry
poetry add "nltk>=3.9.3"
uv
uv add "nltk>=3.9.3"

Severity breakdown

CVSS 4.0 0.0

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack vector
Network
Attack complexity
Low
Attack requirements
None
Privileges required
None
User interaction
None
Confidentiality (vulnerable system)
High
Integrity (vulnerable system)
High
Availability (vulnerable system)
High
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None
Exploit maturity
Not defined
Scope
X

CVSS 3.1 5.3

CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N

Attack vector
Network
Attack complexity
High
Privileges required
None
User interaction
Required
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
None

Weakness

CWE-494: Download of Code Without Integrity Check

The product downloads source code or an executable from a remote location and executes the code without sufficiently verifying the origin and integrity of the code.

How to prevent it
  • Implementation: Perform proper forward and reverse DNS lookups to detect DNS spoofing.
  • Architecture and Design, Operation: Encrypt the code with a reliable encryption scheme before transmitting. This will only be a partial solution, since it will not detect DNS spoofing and it will not prevent your code from being modified on the hosting site.
  • Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Speficially, it may be helpful to use tools or frameworks to perform integrity checking on the transmitted code. When providing the code that is to be downloaded, such as for automatic updates of the software, then use cryptographic signatures for the code and modify the download clients to verify the signatures. Ensure that the implementation does not contain CWE-295, CWE-320, CWE-347, and related weaknesses. Use code signing technologies such as Authenticode. See references [REF-454] [REF-455] [REF-456].
  • Architecture and Design, Operation: Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
  • Architecture and Design, Operation: Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-j456-xh4h-cpf2
NLTK: WekaClassifier passes an unvalidated caller-controlled model path to the weka JVM, bypassing nltk.pathsec containment
High Also affects nltk
GHSA-ff5c-cp5c-9wjf
NLTK: Uncontrolled resource consumption in RecursiveDescentParser via ambiguous or left-recursive grammars
Medium Also affects nltk
GHSA-f794-5jv7-7672
NLTK: Downloader.download follows hardlinks and overwrites outside-root files
High Also affects nltk
GHSA-8mgp-746c-j5xp
NLTK: Model-artifact APIs bypass pathsec and touch files outside allowed roots
High Also affects nltk
GHSA-8mpw-7fpc-4gqj
NLTK: Pl196xCorpusReader has quadratic ReDoS on malformed TEI blocks
Low Also affects nltk
GHSA-cw6x-m8jw-qmrh
NLTK: Uncontrolled recursion in nltk.featstruct.FeatStructReader causes unhandled RecursionError (DoS) via deeply nested feature-structure input
Medium Also affects nltk
GHSA-vp2x-qp44-57v7
NLTK: Quadratic CPU Exhaustion in `XMLCorpusView._read_xml_fragment()`
Low Also affects nltk
GHSA-ww6m-cw3f-q94g
NLTK: Quadratic-time DoS in PorterStemmer via long runs of 'y'
High Also affects nltk
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor