Exploit discussion active in current signal (1 latest mentions)
Immediate actions
Patch dabeaz ply systems immediately
Hunt for exploitation attempts and persistence artifacts
Increase monitoring for publicly documented tradecraft
Recommended action window: High priority (within 72h)
NVD description
An undocumented and unsafe feature in the PLY (Python Lex-Yacc) library 3.11 allows Remote Code Execution (RCE) via the `picklefile` parameter in the `yacc()` function. This parameter accepts a `.pkl` file that is deserialized with `pickle.load()` without validation. Because `pickle` allows execution of embedded code via `__reduce__()`, an attacker can achieve code execution by passing a malicious pickle file. The parameter is not mentioned in official documentation or the GitHub repository, yet it is active in the PyPI version. This introduces a stealthy backdoor and persistence risk. NOTE: A third-party states that this vulnerability should be rejected because the proof of concept does not demonstrate arbitrary code execution and fails to complete successfully.
"CVE-2025-56005: PLY (Python Lex‑Yacc): Undocumented RCE via picklefile Parameter" is disputed https://www.openwall.com/lists/oss-security/2026/01/30/1
TL;DR: CVE-2025-56005 is a nothingburger. Calling this "remote" is nonsense. Doubt this advisory was written in good faith. Just a missing hardening opportunity.
Post summary
The post disputes CVE‑2025‑56005, labeling it a false claim of remote exploitation and framing it as merely a missing hardening issue.
🚨 CVE-2025-56005 : PYTHON PLY REMOTE CODE EXECUTION VIA PICKLE DESERIALIZATION ALERT 🚨
@PLY
A critical deserialization flaw has been identified in PLY (Python Lex-Yacc) 3.11 — allowing unauthenticated remote attackers to achieve arbitrary code execution when attacker-controlled data reaches the picklefile load path in yacc.yacc().
Risk Severity: Critical (reported CVSS ~9.8; public PoC trending; rapid weaponization likely).
Impact:
• Arbitrary code execution as the Python service user (often CI runner / build agent / app service account)
• Credential + secret theft (env vars, tokens, SSH keys, artifact signing material)
• Supply-chain poisoning (tampered build outputs, injected code into produced artifacts)
• Persistence & lateral movement (backdoors, miners, ransomware deployment potential)
Root Cause:
CWE-502 (Deserialization of Untrusted Data)
PLY can deserialize attacker-controlled pickle content via an (often overlooked/undocumented) caching pathway tied to the picklefile parameter, and pickle can execute code during load via crafted objects (e.g., __reduce__).
Attackers can:
• Reach an app/CI service that uses PLY 3.11 to process external grammar/config inputs
• Cause the service to load a malicious pickle file through the picklefile caching mechanism[ citation:1]
• Trigger code execution during pickle.load() (payload executes at deserialization time)
• Run OS commands, drop backdoors, or tamper with pipelines/artifacts depending on privileges[ citation:2]
Are You Affected?
Vulnerable:
• PLY 3.11 (confirmed affected in public advisories).
• Highest risk where PLY-backed parsing is exposed via web endpoints, multi-tenant platforms, CI/CD, build automation, or config/grammar repos.
Fixed in:
• No confirmed upstream fixed version is consistently documented across advisories as of now—treat as unpatched unless your vendor distro indicates otherwise.
Note: If your deployment never accepts untrusted grammar/config and you can guarantee picklefile cannot be influenced (directly or indirectly), exposure drops—but CI/CD and “config-as-code” environments frequently violate this assumption.
Immediate Action Required:
Update/Patch:
• Monitor upstream + your distro advisories for a patched release; upgrade immediately once available.
Mitigation (do now):
• Audit all yacc.yacc() call sites and ensure picklefile cannot be set from user input, repos, or tenant-controlled config.
• Disable parser table pickling/caching where possible (or force the cache path to a trusted, immutable location).
• For internet-facing parsing endpoints: block requests containing picklefile= and similar parameter injection patterns at the edge/WAF (defense-in-depth).
Audit & Monitor:
• Hunt for picklefile usage in code + logs; monitor creation/access of .pkl/pickle artifacts in parser/cache directories.
• Monitor Python services for suspicious child process execution, unexpected outbound traffic, and new persistence mechanisms.
Incident Response:
• Assume full host compromise if an exposed service processed untrusted inputs and a malicious pickle could be loaded—isolate, capture forensics, and rotate all reachable credentials (CI tokens, deploy keys, artifact signing keys).
PLY 3.11 should be treated as a high-value RCE primitive anywhere untrusted parsing inputs exist—mitigate immediately and plan migration/patching without delay
#ply#security#ostorlabCVE
Post summary
A critical deserialization flaw in PLY 3.11 allows remote code execution via malicious pickle files; no patch is yet available, so immediate mitigations and monitoring are recommended.
