CVE-2026-12261 in nltk
Summary
by MITRE • 08/07/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/07/2026
The vulnerability in nltk.downloader represents a critical design flaw that undermines the security and integrity of natural language processing workflows. This weakness exists within the package management system of NLTK versions 3.9.4 and earlier, where the downloader component fails to implement proper namespace isolation during archive extraction processes. The root cause lies in the architecture's decision to extract packages into shared directories such as `corpora/` and `taggers/` rather than maintaining separate package-specific roots, creating an environment where malicious or compromised packages can infiltrate and modify resources belonging to legitimate packages without detection.
The technical implementation of this vulnerability stems from the order of operations within the downloader's validation process. Package integrity checks occur after the archive has already been written and extracted to the shared namespace locations, creating a window of opportunity for resource poisoning attacks. This timing issue allows an attacker to craft a malicious package that appears legitimate during verification but contains harmful resources that overwrite trusted components in the shared directories. The vulnerability directly maps to CWE-276, which addresses inadequate privileges or incorrect permissions, and specifically relates to CWE-427, concerning uncontrolled search path elements that enable attackers to load malicious code.
The operational impact of this vulnerability extends far beyond simple resource overwrites, as it fundamentally compromises the trust model of NLTK-based applications. When one package overwrites another's resources, these changes become immediately active through standard NLTK APIs without requiring any special privileges or additional intervention from users. This persistence across interpreter restarts means that malicious modifications remain active even after system reboots, making detection and remediation particularly challenging. The vulnerability affects downstream workflows including machine learning pipelines where model integrity is paramount, potentially leading to data corruption, model poisoning, or unauthorized access to sensitive information.
The implications for reproducible research and production environments are severe, as this vulnerability can break the consistency guarantees that researchers and developers rely upon when building and deploying NLTK-based applications. In security-sensitive contexts, this flaw could enable attackers to manipulate language processing models in ways that go undetected by standard integrity checks. Organizations using NLTK for critical applications must consider the potential for supply chain attacks where legitimate packages are compromised to inject malicious resources into shared namespaces. This vulnerability also aligns with ATT&CK technique T1584, which covers compromised software supply chains, and represents a significant risk to the broader Python ecosystem's trust model. The remediation approach should focus on immediate version upgrades to NLTK 3.9.5 or later, where namespace isolation has been implemented alongside improved validation timing. Additionally, administrators should conduct thorough audits of existing NLTK installations to identify any compromised resources and consider implementing more robust package management policies that limit automatic downloads in production environments.