Loading story…
NLTK addressed multiple pickle deserialization weaknesses that could let attackers execute arbitrary Python code by supplying malicious model files. An advisory said versions up to 3.9.4 were vulnerable in TransitionParser.parse(), where pickle_load() used an unsafe path that allowed arbitrary class resolution during deserialization; the issue was fixed in NLTK 3.10.0. The project had already introduced safer loaders in picklesec.py, including RestrictedUnpickler, WarningUnpickler, and AllowlistUnpickler, and warned that pickle files should be loaded only from trusted sources.
A later hardening update tightened those protections after bypasses were identified in the allowlist logic. The patch closed remote-code-execution paths by rejecting dotted names, blocking dangerous module prefixes, denying specific risky globals and dunder names, and replacing broad module-prefix allowlists for Punkt model loading with exact global allowlists. The changes specifically targeted gadget access through objects such as sklearn.os.system, numpy.f2py.crackfortran.myeval, nltk.tokenize.repp.ReppTokenizer._execute, and numpy.load, while regression tests were added to ensure malicious payloads are blocked and legitimate NLTK and scientific-stack objects still deserialize correctly.
See affected versions and whether adversaries are exploiting it.
4 events from the most recent confirmed update back to the earliest known activity.
NLTK disclosed four vulnerabilities affecting versions before 3.10.3, including two critical pickle deserialization flaws plus an XML entity expansion DoS issue and an SSRF issue in proxy handling. The disclosure states all four issues are fixed in NLTK 3.10.3 and recommends upgrading, with no known active exploitation reported at the time.
On August 11, 2026, NLTK committed additional hardening to close pickle deserialization bypasses tracked as GHSA-4489 and GHSA-x99w. The patch blocked dotted-name traversal, denied dangerous module prefixes and globals, rejected dunder names, and replaced Punkt's broad module-prefix allowlist with exact allowed globals.
On July 1, 2026, NLTK introduced `picklesec.py` and a security fix labeled `fix(security): prevent pickle RCE in TransitionParser model loading`. The change added `RestrictedUnpickler`, `WarningUnpickler`, `AllowlistUnpickler`, and helper loaders intended to reduce arbitrary code execution risk from pickle files.
A vulnerability affecting NLTK versions up to 3.9.4 was fixed in NLTK 3.10.0. The flaw was in `TransitionParser.parse()`, which used `pickle_load()` with `restricted=false`, allowing arbitrary class resolution through `WarningUnpickler` and enabling code execution via malicious model files.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
4 references tracked. Mallory keeps watching after this page renders.
threataft.com
Open sourcevulncheck.com
Open sourcegithub.com
Open sourcegithub.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Critical deserialization flaws were disclosed in multiple AI and robotics components, allowing attackers to execute arbitrary code by sending crafted `pickle` payloads to exposed services. In Hugging Face’s **LeRobot** `0.4.3`, CVE-2026-25874 affects the async inference `PolicyServer`, where the `SendPolicyInstructions` and `SendObservations` gRPC handlers call `pickle.loads()` on attacker-controlled bytes before validation. The service is exposed over an insecure gRPC port with no TLS or authentication, making network-accessible deployments vulnerable to unauthenticated remote code execution; the issue was rated **CVSS 9.8** and no fix was available at disclosure. A separate flaw, CVE-2026-26210, was reported in **ktransformers**’ legacy `balance_serve` backend, where a ZeroMQ `ROUTER` socket bound on all interfaces forwards untrusted messages to worker threads that also invoke `pickle.loads()` without authentication, enabling unauthenticated remote code execution and prompting a fix PR.
Jun 29, 2026
A **critical remote code execution (RCE)** vulnerability was disclosed in the PyPI-distributed *PLY (Python Lex-Yacc) 3.11* library, tracked as **CVE-2025-56005** (reported with **CVSS 9.8**). The issue stems from an **undocumented** `picklefile` parameter in `yacc()` that triggers `pickle.load()` on an attacker-controlled file without validation, enabling arbitrary code execution during deserialization (e.g., via `__reduce__()`) before parser initialization completes. Reporting noted the risk is amplified because execution can occur silently at application startup, prior to any parsing logic. Exploitation is feasible in environments where parser tables or build artifacts are cached or shared, including **cached parser table locations**, **shared network directories**, and **CI/CD pipeline artifacts**, if an attacker can influence or replace the referenced pickle file or its path. A proof-of-concept was described demonstrating that a crafted pickle can execute system commands as soon as `yacc(picklefile=...)` is invoked. Separately, a different Python ecosystem issue was also reported: **CVE-2026-0994** in Google *Protocol Buffers* Python JSON parsing (`google.protobuf.json_format.ParseDict()`), where nested `google.protobuf.Any` messages can bypass recursion-depth accounting and crash services via **DoS**—but this is unrelated to the PLY RCE.
Jul 12, 2026
A critical remote code execution vulnerability, tracked as **CVE-2021-47952**, affects the Python `jsonpickle` library through unsafe deserialization of untrusted JSON. In `jsonpickle` 2.0.0, applications that pass attacker-controlled data to `jsonpickle.decode()` can be compromised because the `py/repr` tag is processed by an internal repr-loading path that forwards input into Python's `eval()`, allowing arbitrary code execution with the privileges of the running process. The issue requires no authentication, special privileges, or user interaction beyond the target application decoding malicious input. Public exploit details show the flaw can be triggered remotely with crafted serialized data containing a `py/repr` field, enabling execution of arbitrary Python commands and potentially system-level calls on both Windows and Linux. Earlier reporting said the behavior existed for backward compatibility across versions and initially lacked a patch, while later project changes reportedly removed reliance on `eval()` and disabled legacy repr object support by default, reflecting a broader pattern of deserialization risk in the project.
Jul 10, 2026