Unsafe pickle deserialization in PLY 3.11 yacc() via undocumented picklefile parameter
CVE-2025-56005 describes an unsafe deserialization condition in the PyPI-distributed PLY (Python Lex-Yacc) 3.11 package. According to the provided content, ply.yacc.yacc() accepts an undocumented picklefile parameter that leads to LRTable.read_pickle() in ply/yacc.py deserializing a supplied .pkl file with Python pickle.load() without validation. Because Python pickle deserialization can invoke attacker-controlled behavior such as __reduce__(), a malicious pickle can execute code during parser initialization before normal parsing logic runs. The content also notes dispute around the CVE: third-party discussion and an oss-sec thread argue the published proof of concept is flawed and that the CVE may merit rejection. Based on the supplied technical description alone, the issue is best characterized as unsafe deserialization of attacker-controlled pickle data in PLY 3.11.
Are you exposed to this one?
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
Impact, mitigation & remediation
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
Impact
What an attacker gets, and what they’ve been doing with it.
yacc() with a malicious or attacker-replaceable picklefile, arbitrary code may execute in the security context of the Python process loading the parser tables. This can enable full compromise of the affected application environment, including execution of OS commands, installation of backdoors, persistence through poisoned cache artifacts, tampering with parser initialization, and potential follow-on access to application data or adjacent systems reachable from that process. The content specifically highlights elevated risk where parser table files are loaded from shared, cached, CI/CD, configurable, or otherwise writable locations.Mitigation
If you can’t patch tonight, do this now.
picklefile parameter with untrusted input or attacker-influenced paths. Treat all pickle files as unsafe. Ensure applications cannot accept user-controlled filenames or directories for parser table loading. Store any parser cache artifacts only in trusted directories with strict permissions, and prevent untrusted users or processes from writing or replacing .pkl files that may later be loaded. Run affected services with least privilege and, where practical, isolate them in containers or sandboxes to reduce blast radius if deserialization occurs. Note that the validity of the published PoC is disputed in the provided content, so mitigation should focus on eliminating unsafe pickle loading regardless.Remediation
Patch, then assume compromise.
picklefile parameter in ply.yacc.yacc(). Prevent LRTable.read_pickle() from loading externally supplied pickle files, or replace pickle-based parser table caching with a safer serialization mechanism. Regenerate parser tables instead of loading them from disk where feasible, and ensure any retained cache files are created and stored only in trusted, non-user-writable locations.Exploits
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos (1 hidden).
Repository purpose: a small Python project intended to reproduce and critique an alleged PLY 3.11 RCE (referenced as CVE-2025-56005) and argue for rejection. Structure: README.md explains that the copied PoC in main.py fails (AttributeError) and does not demonstrate cross-process untrusted data flow; main.py contains the only code. Exploit mechanics in main.py: it crafts a dictionary mimicking PLY yacc parsing tables and embeds an object (Exploit) whose __reduce__ returns (os.system, (cmd,)), then pickles this structure to a local file exploit.pkl. It then calls ply.yacc.yacc(picklefile='exploit.pkl', debug=False, write_tables=False) and parses the token 'example'. If PLY unpickles attacker-controlled parser tables unsafely, unpickling would execute the payload command, creating /tmp/pwned and writing 'VULNERABLE'. No network exploitation is implemented; the attack vector is local and depends on a victim process loading an attacker-supplied picklefile. The repository includes pyproject.toml and uv.lock to pin ply==3.11 and provide reproducible setup via uv.
Affected products & vendors
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
Recent activity
21 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
The version that knows your environment.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.