CVE-2026-78683: NLTK before 3.10.0 Remote Code Execution via Unsafe Pickle Deserialization
NLTK before 3.10.0 (affected versions <=3.9.4) contains an unsafe pickle deserialization vulnerability in the TransitionParser.parse() method (nltk/parse/transitionparser.py). The method calls pickleload() with the default restricted=False, routing deserialization through WarningUnpickler, which does not override findclass() and therefore permits arbitrary class resolution. When an application loads an attacker-crafted model file, embedded pickle gadget chains execute arbitrary Python code with the privileges of the user running the application. NLTK provides a RestrictedUnpickler for safe deserialization, but it is not used by production code paths. Fixed in 3.10.0.
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.0 - Compensating control
Avoid loading attacker-controlled NLTK model files; ensure model files used by TransitionParser.parse() are from trusted sources only to prevent unsafe pickle deserialization.
Event History
Frequently Asked Questions
Which deployments are exposed to exploitation?
Applications using NLTK versions through 3.9.4 are exposed if they invoke TransitionParser.parse() on a model file that an attacker can craft or control. The resulting code runs with the privileges of the user running the application.
Does an attacker need prior access or interaction to exploit this?
The vulnerability is network-reachable with low attack complexity and requires no privileges, but it requires a user or application to load the attacker-crafted model file. The supplied severity vector indicates user interaction is required.
What should be done to remediate the issue?
Upgrade NLTK to version 3.10.0, which fixes the issue. NLTK versions at or below 3.9.4 are affected.
What can be done if an immediate upgrade is not possible?
Do not load TransitionParser model files from untrusted or attacker-controlled sources. Restrict which users or processes can supply model files, because loading a crafted file can execute arbitrary Python code.