---
id: "CVE-2026-12259"
kind: "vulnerability"
aliases: ["CVE-2026-12259", "GHSA-5wp5-5229-5g6q"]
title: "NLTK: Missing Post-Download Integrity Verification Allows Malicious Package Injection"
severity: "medium"
cvss: 6.5
epss: 0.00101
exploited: false
status: "open"
category: "package"
products: [{"name": "nltk", "fixed": ["3.9.3"], "affected": "<= 3.9.2", "ecosystem": "pypi"}, {"name": "nltk", "fixed": [], "affected": "= 3.9.4", "ecosystem": "vendor"}]
ecosystems: ["pypi", "vendor"]
tags: ["ci", "cwe-494", "nltk", "package", "pypi", "python", "self-hosted"]
not_affected_if: ["https-only-network", "no-runtime-downloads", "pre-bundled-data"]
published_at: "2026-08-03T08:17:17+00:00"
first_seen_at: "2026-10-27T08:02:10+00:00"
updated_at: "2026-10-27T08:31:47+00:00"
sources: [{"source": "ghsa", "url": "https://github.com/advisories/GHSA-5wp5-5229-5g6q", "first_seen_at": "2026-10-27T08:02:10+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12259", "first_seen_at": "2026-10-27T08:31:47+00:00"}]
---

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

NLTK'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, check and fix written by a model from the sources; labelled as such._

## Affected

- pypi:nltk affected <= 3.9.2 fixed 3.9.3
- vendor:nltk affected = 3.9.4 fixed ?

## How to check

- Run `pip show nltk` and check whether the version is `3.9.2` or lower.
- Check whether `nltk.download` fetches from any `http://` mirror in your environment.
- Check whether NLTK data directories live on a shared or writable filesystem.

## Fix

- Upgrade nltk to `3.9.3` or later with `pip install --upgrade nltk==3.9.3`.
- Until the upgrade, download NLTK data only over HTTPS from trusted networks.

## Timeline

- 2026-10-27T08:02:10+00:00 ghsa https://github.com/advisories/GHSA-5wp5-5229-5g6q
- 2026-10-27T08:31:47+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-12259

## From the sources

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 = {'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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_