Eine Schwachstelle in der Python-PLY-Bibliothek (Python Lex-Yacc) ermöglicht es Angreifern, beliebigen Code auf anfälligen Systemen auszuführen, und gibt Anlass zur Sorge bei Anwendungen, die auf zwischengespeicherte Parser-Tabellen angewiesen sind.
Die Schwachstelle, die PLY in der über PyPI verbreiteten Version 3.11 betrifft, verfügt über einen öffentlich verfügbaren Proof of Concept (PoC) und ermöglicht die Remote-Codeausführung beim Start der Anwendung.
Diese Schwachstelle ermöglicht Angreifern „… die Ausführung beliebigen Codes, die Ausführung beim Start der Anwendung sowie die Codeausführung, bevor jegliche Parsing-Logik erreicht wird“, sagten die Forscher in der Sicherheitswarnung.
Die Pickle-Deserialisierungs-Schwachstelle in PLY
PLY ist in Python-Anwendungen, die benutzerdefinierte Parser implementieren, weit verbreitet eingebettet, darunter Compiler, Konfigurations-Engines und domänenspezifische Sprachen.
In vielen dieser Systeme erfolgt die Initialisierung des Parsers früh im Lebenszyklus der Anwendung und wird implizit als vertrauenswürdig eingestuft.
Daher können Schwachstellen auf dieser Ebene überproportionale Auswirkungen haben und potenziell zu einer vollständigen Kompromittierung des Systems führen, bevor die meisten Sicherheitskontrollen überhaupt aktiv sind.
Das als CVE-2025-56005 geführte Problem weist ein hohes Risikoprofil auf, da die Ausnutzung nicht davon abhängt, dass schädliche Eingaben geparst werden.
Stattdessen wird der anfällige Code ausgeführt, bevor die Parsing-Logik beginnt, wodurch herkömmliche Eingabevalidierung, Sandboxing und Laufzeitüberwachung weitgehend wirkungslos werden.
Im Zentrum der Schwachstelle steht ein undokumentierter picklefile-Parameter in der yacc()-Funktion von PLY Version 3.11.
Wenn dieser Parameter gesetzt ist, versucht PLY, zwischengespeicherte Parser-Tabellen mit der Python-Funktion pickle.load() von der Festplatte zu laden – ohne Integritätsprüfungen, Validierung oder eine Überprüfung der Herkunft der zu deserialisierenden Datei.
Dieses Verhalten ist gefährlich, da das Python-Modul pickle grundsätzlich unsicher für nicht vertrauenswürdige Daten ist.
Bei der Deserialisierung können Objekte eine __reduce__()-Methode definieren, die beliebigen Code ausführt.
Daher garantiert das Laden einer schädlichen Pickle-Datei die Codeausführung, die häufig bereits erfolgt, bevor Anwendungsprotokollierung, Sicherheitsinstrumentierung oder Berechtigungsbeschränkungen vollständig initialisiert sind.
In der Praxis kann ein Angreifer, der den Pfad oder Inhalt der Pickle-Datei beeinflussen kann, beliebige Systembefehle ausführen, indem er einfach die Parser-Initialisierung auslöst.
Ein verfügbarer Proof of Concept zeigt, dass bei yacc(picklefile=”exploit.pkl”) dem Laden eines manipulierten Pickles mit einer schädlichen __reduce__()-Nutzlast die Codeausführung sofort erfolgt – ohne Benutzerinteraktion oder Parsing-Eingaben.
Ausnutzung
Eine Ausnutzung wird in Umgebungen möglich, in denen Parser-Tabellendateien kontrolliert, ersetzt oder anderweitig manipuliert werden können.
Zu den möglichen Ausnutzungsszenarien gehören zwischengespeicherte Parser-Tabellenverzeichnisse auf der Festplatte, gemeinsam genutzte Netzwerkdateisysteme, auf die mehrere Dienste zugreifen, CI/CD-Pipeline-Artefakte, die in mehreren Builds wiederverwendet werden, sowie anwendungsdefinierte Dateipfade, die beschreibbar oder konfigurierbar sind.
Da diese Ressourcen häufig als vertrauenswürdige interne Komponenten behandelt werden, verfügen sie möglicherweise nicht über eine angemessene Überwachung oder Integritätskontrollen, was die Wahrscheinlichkeit einer unbemerkten Kompromittierung erhöht.
Risiken durch Codeausführung beim Start reduzieren
Da diese Schwachstelle die Codeausführung beim Start der Anwendung ermöglicht, sollten sich Unternehmen darauf konzentrieren, unsichere Deserialisierung zu verhindern und das Vertrauen in parserbezogene Artefakte zu begrenzen.
Die bloße Validierung von Laufzeiteingaben reicht nicht aus, wenn die Ausnutzung erfolgt, bevor die normalen Sicherheitskontrollen aktiv sind.
Ein Schutzkonzept, das Code-Reviews, die Absicherung von Dateisystemen und den Schutz von Build-Pipelines kombiniert, ist wichtig, um zur Verringerung des Risikos beizutragen.
- Prüfen Sie Anwendungen auf die Verwendung des undokumentierten picklefile-Parameters und vermeiden Sie nach Möglichkeit das Laden von Parser-Tabellen von der Festplatte.
- Behandeln Sie alle Pickle-Dateien als nicht vertrauenswürdige Eingaben und beseitigen Sie unsichere Deserialisierungspfade während der Parser-Initialisierung.
- Beschränken Sie die Speicherorte des Parser-Cache auf nicht beschreibbare Verzeichnisse und wenden Sie strenge Dateisystemberechtigungen an.
- Härten Sie CI/CD-Pipelines gegen Artefaktvergiftung und unbefugte Änderungen an Build-Ausgaben.
- Führen Sie die Parser-Initialisierung in isolierten oder mit geringstmöglichen Berechtigungen ausgestatteten Umgebungen aus , um die Auswirkungen einer Ausnutzung zu begrenzen.
- Überwachen Sie kritische Dateipfade und das Startverhalten auf unerwartete Dateiänderungen oder Prozessausführung.
- Integrieren Sie Szenarien für unsichere Deserialisierung in den Sicherheitsbetrieb und testen Sie regelmäßig Pläne zur Reaktion auf Sicherheitsvorfälle , um die Codeausführung beim Start zu berücksichtigen.
Diese Maßnahmen tragen dazu bei, den Schadensradius einer Ausnutzung zu begrenzen und die Widerstandsfähigkeit gegen Kompromittierungen beim Start zu erhöhen, die andernfalls herkömmliche Sicherheitskontrollen umgehen könnten.
Build-Artefakte als Angriffsvektor
Diese Schwachstelle verdeutlicht die Risiken unsicherer Deserialisierung und des impliziten Vertrauens in interne Anwendungskomponenten, insbesondere während früher Ausführungsphasen, in denen die Sicherheitskontrollen eingeschränkt sind.
Da Bibliotheken wie PLY weiterhin in kritische Parsing- und Build-Workflows eingebettet sind, sollten Unternehmen ihre Absicherung und Überwachung von Codepfaden beim Start neu bewerten.
Eine geringere Abhängigkeit von nicht validierten Artefakten, strengere Dateisystem- und Pipeline-Kontrollen sowie die Isolierung risikoreicher Initialisierungslogik können dazu beitragen, die Auswirkungen einer Ausnutzung zu begrenzen.
Der Umgang mit diesen Risiken fügt sich nahtlos in Zero-Trust-Frameworks ein, die Komponenten und Ausführungskontexte kontinuierlich validieren.