CVE-2026-71513 in NLTK
Summary
by MITRE • 08/22/2026
NLTK before 3.10.3 contains a remote code execution vulnerability in AllowlistUnpickler that validates only the pickle module string and not the global name, allowing attackers to resolve dotted names by attribute traversal to callables outside the allowlisted namespace. Attackers can craft untrusted transition-parser models that execute arbitrary commands when TransitionParser.parse loads the model through allowlisted_pickle_load.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/22/2026
The vulnerability identified in Natural Language Toolkit versions prior to 3.10.3 represents a critical failure in deserialization security, specifically within the AllowlistUnpickler class used for loading pickle data. Python's pickle module is inherently unsafe when processing untrusted input because it allows arbitrary object instantiation and function calls during unpickling. To mitigate this risk, NLTK implemented an allowlisting mechanism intended to restrict execution to a predefined set of safe modules and classes. However, the validation logic employed in AllowlistUnpickler was fundamentally flawed as it only verified that the module name string matched one of the allowed entries without sufficiently validating the global attribute names or performing strict namespace isolation during object resolution.
The core technical flaw lies in how Python resolves dotted names within pickle streams. When an attacker crafts a malicious pickle payload, they can exploit attribute traversal to bypass the allowlist restrictions. By referencing attributes on objects that are themselves instantiated from allowed classes but possess methods or properties pointing to dangerous functions outside the permitted scope, an adversary can effectively resolve arbitrary callables. This technique allows the execution of code in contexts such as os.system or subprocess.Popen, which were not explicitly listed in the safe modules because they were accessed indirectly through attribute chains rather than direct module imports. The validation logic failed to inspect these intermediate steps, assuming that if the top-level module was allowed, all subsequent operations would be safe.
This vulnerability directly impacts applications utilizing NLTK's TransitionParser component, particularly when loading transition-parser models from untrusted sources or networked environments. When a user loads a model file via allowlisted_pickle_load, the underlying unpickler processes the serialized data without adequate safeguards against attribute-based code execution. An attacker who can supply a crafted model file can trigger arbitrary command execution on the host system with the privileges of the running process. This transforms what appears to be a simple configuration loading operation into a full remote code execution vector if the input source is compromised or maliciously injected, posing severe risks to data integrity and confidentiality in NLP pipelines that handle external inputs.
The operational impact extends beyond immediate command execution, potentially leading to complete system compromise depending on the deployment context. In server-side applications processing user-uploaded linguistic models, this flaw could allow attackers to exfiltrate sensitive training data, install backdoors, or pivot further into internal networks. The vulnerability aligns with CWE-502, which describes Deserialization of Untrusted Data, and specifically relates to insufficient validation of deserialized objects against a known-good set of classes. From an offensive security perspective, this technique mirrors ATT&CK tactic T1610, where attackers exploit legitimate software features for persistence or execution, leveraging the trust placed in standard library components like pickle by application developers who may underestimate the sophistication required to bypass allowlists through attribute traversal.
Mitigation requires immediate upgrading to NLTK version 3.10.3 or later, which addresses this flaw by implementing stricter validation of global names and preventing arbitrary attribute resolution during unpickling operations. Developers should also review any custom implementations of AllowlistUnpickler in their codebases to ensure they do not replicate the same logical errors. As a broader security practice, applications handling untrusted data should avoid using pickle for serialization entirely, opting instead for safer formats like JSON or MessagePack that do not support arbitrary object instantiation. If pickle must be used due to legacy constraints, input validation must occur at multiple layers, and sandboxing techniques such as restricted execution environments can provide additional defense-in-depth against deserialization attacks.