Summary
NLTK: Unsafe Pickle Deserialization in TransitionParser Allows Remote Code Execution
The NLTK library's TransitionParser.parse() method deserializes model files using pickle_load() with the default restricted=False parameter, allowing arbitrary Python code execution when loading a malicious model file. The library provides a RestrictedUnpickler class for safe deserialization, but it is never used by production code paths, leaving the vulnerability unpatched.
Root Cause
File: nltk/parse/transitionparser.py (lines 542-557)
The parse() method calls pickle_load(f) without restricted=True, routing through WarningUnpickler which inherits from pickle.Unpickler and does NOT override find_class(). This allows arbitrary class/function resolution during unpickling, enabling RCE via standard pickle gadgets (e.g., os.system, subprocess.Popen).
Vulnerability chain in nltk/picklesec.py:
def pickle_load(file, *, context=None, restricted=False):
if restricted:
return RestrictedUnpickler(file).load() # Safe: blocks all globals
return WarningUnpickler(file, context=context).load() # VULNERABLE PATH
WarningUnpickler only emits a warning but does NOT block unsafe class loading, it calls super().load() which is standard pickle.Unpickler.load().
Why this is not by design:
- NLTK intentionally created
RestrictedUnpicklerto block unsafe deserialization - The
restricted=Trueparameter exists in the API but is never used by any production code path - All call sites use the default
restricted=False:transitionparser.py:557,parse/chartparser_app.py:816,parse/chartparser_app.py:2273,parse/chartparser_app.py:2311
Attack Surface
Entry point: TransitionParser().parse(depgraphs, modelFile) receives a filesystem path with no validation.
Exploitation path:
- Attacker places a malicious pickle file at a known or attacker-controlled location
- Victim calls
parser.parse(sentences, "/path/to/malicious_model.pkl") pickle_load()deserializes the file withrestricted=False(default)- Standard pickle gadget chain executes arbitrary Python code with victim's privileges
Impact: Remote code execution with the privileges of the user running the NLTK-dependent application. Affects researchers, data scientists, and automated ML pipelines using NLTK for parsing tasks.
Steps to Reproduce
Environment
- NLTK version: 3.8.1+ (all versions with
transitionparser.py) - Python 3.6+
- No special dependencies required
Reproduction
Create a malicious pickle file that uses
__reduce__to execute a system command during deserialization.Call
TransitionParser().parse([], '/path/to/malicious_model.pkl').The
pickle_load(f)call attransitionparser.py:557usesrestricted=Falseby default, routing throughWarningUnpickler, which does not overridefind_class()and permits full class resolution, executing the embedded gadget.Arbitrary code executes with the victim's privileges.
Proof That the Fix Works
Changing line 557 in transitionparser.py from:
model = pickle_load(f)
to:
model = pickle_load(f, restricted=True)
causes RestrictedUnpickler to raise an UnpicklingError and block execution, confirming the safe path prevents the attack.
Working PoC
import pickle
import os
from nltk.parse.transitionparser import TransitionParser
# Create malicious pickle with RCE payload
class Exploit:
def __reduce__(self):
return (os.system, ('touch /tmp/nltk_poc_triggered',))
with open('/tmp/malicious_model.pkl', 'wb') as f:
pickle.dump(Exploit(), f)
# Trigger the vulnerable code path (requires algorithm argument in ≤ 3.9.4)
parser = TransitionParser('arc-standard') # or 'arc-eager'
parser.parse([], '/tmp/malicious_model.pkl') # loads and unpickles unsafely
# Exploit succeeds: file /tmp/nltk_poc_triggered is created
On NLTK ≥ 3.10.0 (patched), the same code fails with:
_pickle.UnpicklingError: global 'posix.system' is not in the pickle allowlist
This proves the vulnerability exists in versions ≤ 3.9.4 and is fixed in 3.10.0+.
Impact
Untrusted serialized data is processed by a deserializer that can instantiate arbitrary objects or execute code as a side effect. Typical impact: arbitrary code execution or logic abuse.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Change all call sites to use restricted=True:
| File | Line | Before | After |
|---|---|---|---|
nltk/parse/transitionparser.py |
557 | pickle_load(f) |
pickle_load(f, restricted=True) |
nltk/parse/chartparser_app.py |
816 | pickle_load(model_data_file) |
pickle_load(model_data_file, restricted=True) |
nltk/parse/chartparser_app.py |
2273 | pickle_load(file) |
pickle_load(file, restricted=True) |
nltk/parse/chartparser_app.py |
2311 | pickle_load(fp) |
pickle_load(fp, restricted=True) |
Note: This fix may affect loading older sklearn models. A more robust approach would implement a module allowlist in RestrictedUnpickler.find_class().
Frequently Asked Questions
- What is CVE-2026-78683? CVE-2026-78683 is a critical-severity insecure deserialization vulnerability in nltk (pip), affecting versions <= 3.9.4. It is fixed in 3.10.0. Untrusted serialized data is processed by a deserializer that can instantiate arbitrary objects or execute code as a side effect.
- Which versions of nltk are affected by CVE-2026-78683? nltk (pip) versions <= 3.9.4 is affected.
- Is there a fix for CVE-2026-78683? Yes. CVE-2026-78683 is fixed in 3.10.0. Upgrade to this version or later.
- Is CVE-2026-78683 exploitable, and should I be worried? Whether CVE-2026-78683 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-78683 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-78683? Upgrade
nltkto 3.10.0 or later.