CVE-2025-56005: Critical Remote Code Execution via Unsafe Pickle Deserialization in PLY

CVE: CVE-2025-56005
Name: Unsafe picklefile deserialization in PLY yacc()
CVSS Score: 9.8 (Critical)
Severity: Critical
Exploitability: Remote code execution via untrusted data
Exploit Availability: Proof-of-concept (PoC) exists publicly and confirms that exploitation is simple when untrusted .pkl files are processed.

Official patch / upgrade:
Use the official fixed release or upgrade guidance from the PLY project:
https://github.com/advisories/GHSA-qc6m-pwr3-g72p

Overview

This vulnerability exists because the PLY library’s parser generator function (yacc()) allows loading a serialized parser state from a file using Python’s pickle module. The pickle format is inherently unsafe when used with untrusted data, as it can execute arbitrary code during deserialization.

The picklefile parameter responsible for this behavior is undocumented in the official PLY documentation, which makes the issue harder to identify during code reviews. When an attacker is able to control or influence the pickle file being loaded, arbitrary code execution can occur immediately during deserialization.

Technical Details

The yacc() function internally invokes pickle.load() on the file specified by the picklefile argument. No validation or integrity checks are performed on the contents of the file. Python’s pickle mechanism allows object reconstruction logic to invoke functions or system commands embedded in the serialized data.

When a malicious pickle file is deserialized, attacker-supplied instructions are executed automatically. This results in remote code execution under the privileges of the running Python process.

Because the parameter is undocumented, developers may unknowingly expose this behavior in production systems, especially in applications that accept uploaded files, dynamically reference parser cache files, or load parser states from shared directories.

Exploitation Scenario

Exploitation is possible when an attacker can cause a malicious .pkl file to be passed into the vulnerable deserialization path. This may occur through:

File upload functionality that does not restrict file types
API endpoints that accept file paths or configuration values
Shared storage locations where attackers can write files
Build or initialization processes that automatically load parser cache files

Once the malicious file is processed by yacc(), code embedded in the pickle payload is executed immediately. No authentication or user interaction is required.

Proof-of-Concept and Exploit Availability

Public proof-of-concept code exists and demonstrates successful remote code execution using a crafted pickle payload. This confirms that the vulnerability is practical and exploitable in real-world environments.

These PoCs are intended for educational and defensive testing purposes only and should be executed exclusively in isolated lab environments.

Proof-of-Concept (PoC) – Educational

Goal

Demonstrate how unsafe pickle deserialization in PLY’s yacc() function can lead to remote code execution.

PoC Concept

A malicious pickle file is created.
The pickle contains instructions that execute a system command when deserialized.
The vulnerable application calls yacc(picklefile="malicious.pkl").
During pickle.load(), the embedded command is executed automatically.

Minimal PoC Example (Conceptual)

Step 1: Malicious pickle creation (attacker-controlled)

import pickle
import os

class Exploit:
    def __reduce__(self):
        return (os.system, ("id",))  # example harmless command

with open("malicious.pkl", "wb") as f:
    pickle.dump(Exploit(), f)

This pickle file is not just data. It contains logic that tells Python to execute a command when the file is loaded.

Step 2: Vulnerable application behavior

from ply import yacc

# attacker controls or influences this file path
yacc.yacc(picklefile="malicious.pkl")

As soon as yacc() loads the pickle file, pickle.load() is triggered internally, and the command executes automatically.

Why this works

Python pickle allows arbitrary object reconstruction.
The __reduce__() method defines how objects are rebuilt.
PLY does not validate or restrict what is inside the pickle.
Execution happens immediately during deserialization.

Detection Strategy

Detection should focus on a combination of file activity, application behavior, and process execution patterns.

Log Sources to Monitor

Python application logs for deserialization errors or unexpected stack traces
Web server and API logs for .pkl file uploads or suspicious file references
File integrity monitoring for creation or modification of pickle files
Endpoint telemetry for abnormal child process execution
Network logs for unexpected outbound connections initiated by Python processes

Indicators of Compromise

Presence of unexpected .pkl files in application or parser directories
Python processes spawning shells or command interpreters
System commands executed shortly after file upload or parser initialization
Abnormal network connections originating from backend services

Sysmon Rules for Detection

The following Sysmon rules are provided as detection guidance and should be adapted to the environment before deployment.

Sysmon Rule 1: Python Spawning a Shell (High Confidence Indicator)

<Sysmon schemaversion="4.90">
  <EventFiltering>
    <ProcessCreate onmatch="include">
      <ParentImage condition="contains">python</ParentImage>
      <Image condition="contains">cmd.exe</Image>
    </ProcessCreate>
    <ProcessCreate onmatch="include">
      <ParentImage condition="contains">python</ParentImage>
      <Image condition="contains">powershell.exe</Image>
    </ProcessCreate>
    <ProcessCreate onmatch="include">
      <ParentImage condition="contains">python</ParentImage>
      <Image condition="contains">/bin/sh</Image>
    </ProcessCreate>
  </EventFiltering>
</Sysmon>

This rule detects Python processes spawning command interpreters, which is uncommon in normal parsing operations and strongly suggests exploitation.

Sysmon Rule 2: Suspicious Pickle File Creation or Modification

<Sysmon schemaversion="4.90">
  <EventFiltering>
    <FileCreate onmatch="include">
      <TargetFilename condition="endswith">.pkl</TargetFilename>
    </FileCreate>
    <FileCreateTime onmatch="include">
      <TargetFilename condition="endswith">.pkl</TargetFilename>
    </FileCreateTime>
  </EventFiltering>
</Sysmon>

This rule highlights the creation or modification of pickle files, which should be reviewed when occurring in application directories.

Sysmon Rule 3: Network Connections from Python After Deserialization

<Sysmon schemaversion="4.90">
  <EventFiltering>
    <NetworkConnect onmatch="include">
      <Image condition="contains">python</Image>
    </NetworkConnect>
  </EventFiltering>
</Sysmon>

Outbound network connections from backend Python services that normally do not initiate external communication should be treated as suspicious.

Mitigation and Hardening

Until the official patch is applied, the following actions are strongly recommended:

Remove or disable usage of the undocumented picklefile argument
Block .pkl file uploads at the application layer
Restrict file system write access for application users
Replace pickle-based persistence with safer serialization formats
Run parser components with minimal privileges and sandboxing
Monitor for behavioral indicators using endpoint detection tools

Final Takeaway

This vulnerability represents a high-risk deserialization flaw that enables unauthenticated remote code execution. Because the vulnerable functionality is undocumented, it may exist in production systems without developer awareness. Strong detection, immediate mitigation, and prompt upgrading to the official fixed version are essential to reduce exposure.