CVE-2026-71513: NLTK 3.10.0 through 3.10.2 Remote Code Execution via AllowlistUnpickler Dotted-Name Bypass
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 allowlistedpickleload.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
NLTKto a version that resolves this vulnerability.Fixed in 3.10.3 - Configuration
Update TransitionParser.parse model loading so allowlisted_pickle_load/AllowlistUnpickler validates both the pickle module string and the full global name, preventing dotted-name bypass via attribute traversal to callables outside the allowlisted namespace.
TransitionParser / allowlisted_pickle_load pickle loading via AllowlistUnpickler dotted-name validation = Only allow exact, fully-qualified allowlisted globals (no dotted-name/attribute traversal); reject non-allowlisted global names
Event History
Frequently Asked Questions
What conditions are required for exploitation?
An attacker must be able to supply or influence an untrusted transition-parser model that is later loaded by TransitionParser.parse. Exploitation occurs when the application loads that crafted model through allowlisted_pickle_load; the attacker does not need prior privileges, but user interaction is required according to the CVSS vector.
Are installations using NLTK 3.10.0 through 3.10.2 affected by default?
The affected behavior is present in NLTK versions 3.10.0 through 3.10.2, but exploitation specifically depends on loading an attacker-crafted transition-parser model. The provided information does not establish that a default installation loads untrusted models.
How can I determine whether an application is exposed?
Identify applications using NLTK before 3.10.3 and check whether they invoke TransitionParser.parse on model files obtained from users, external sources, shared storage, or other untrusted channels. Such model-loading paths are the relevant exposure point.
What should be done if upgrading is not immediately possible?
Do not load untrusted transition-parser model files through TransitionParser.parse. Restrict model sources to trusted, integrity-controlled files until NLTK can be updated to 3.10.3 or later.