Source: nltk Version: 3.9.1-2 Severity: important Tags: security upstream X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
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
