Bug#1144456: nltk: CVE-2026-12259 CVE-2026-12261 CVE-2026-12372 CVE-2026-12876

[Salvatore Bonaccorso]

Source: nltk
Version: 3.9.1-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: carnil at debian.org, Debian Security Team <team at security.debian.org>

Hi,

The following vulnerabilities were published for nltk.

CVE-2026-12259[0]:
| 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.


CVE-2026-12261[1]:
| A vulnerability in `nltk.downloader` in nltk/nltk versions <= 3.9.4
| allows for cross-package resource and model poisoning. The
| downloader extracts package archives into shared namespaces such as
| `corpora/` and `taggers/` instead of package-isolated roots, and
| validates package integrity only after the archive has been written
| and extracted. This design flaw enables one package to overwrite
| another package's trusted resources within the same namespace,
| making the changes immediately active through ordinary NLTK APIs.
| This issue persists across fresh interpreter restarts and can affect
| downstream workflows, including machine learning pipelines and
| reproducibility-sensitive environments.


CVE-2026-12372[2]:
| A Server-Side Request Forgery (SSRF) vulnerability exists in
| nltk/nltk versions 3.9.4 and the current develop branch. The
| `nltk.pathsec.validate_network_url()` function, intended to prevent
| SSRF by rejecting internal network addresses, fails to reject IPs in
| the RFC 6598 shared address space (`100.64.0.0/10`). This occurs
| because Python's `ipaddress` module does not classify such addresses
| as `is_private` or `is_global`, and the current guard only checks
| `is_private` and a few explicit categories. An attacker who can
| influence a URL passed to NLTK's network-loading helpers can exploit
| this vulnerability to make a strict-mode application send requests
| to shared-address-space hosts, potentially exposing non-public
| infrastructure reachable from the application host. The impact is
| limited to SSRF-style confidentiality exposure, with no code
| execution claimed.


CVE-2026-12876[3]:
No description was found (try on a search engine)


If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2026-12259
    https://www.cve.org/CVERecord?id=CVE-2026-12259
[1] https://security-tracker.debian.org/tracker/CVE-2026-12261
    https://www.cve.org/CVERecord?id=CVE-2026-12261
[2] https://security-tracker.debian.org/tracker/CVE-2026-12372
    https://www.cve.org/CVERecord?id=CVE-2026-12372
[3] https://security-tracker.debian.org/tracker/CVE-2026-12876
    https://www.cve.org/CVERecord?id=CVE-2026-12876

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



-- System Information:
Debian Release: forky/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 7.1.7+deb14-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled