Skip to content
Vol. 1 · Ed. 2026
CyberGlossary
Entry № 603

Unsichere Deserialisierung

Geprüft vonCybersecurity entrepreneur & security researcher

Was ist Unsichere Deserialisierung?

Unsichere DeserialisierungSchwachstelle, bei der eine Anwendung nicht vertrauenswürdige Daten deserialisiert und Angreifer beliebige Objekte erzeugen — häufig mit Remote-Code-Execution.


Wenn eine Anwendung serialisierte Daten (Binärformate von Java/PHP/Python/.NET, YAML oder JSON mit Typ-Metadaten) wieder in Objekte zurückwandelt, kann der Deserialiser Konstruktoren, Magic-Methoden oder Gadget-Chains aufrufen — Ketten bereits geladener Methoden, die aneinandergereiht eine gefährliche Senke wie Runtime.exec erreichen. Mit nicht vertrauenswürdigem Input erstellt ein Angreifer eine Payload, die dieses Verhalten während der Deserialisierung auslöst, und erlangt so Remote Code Execution (RCE), Authentifizierungs-Umgehung, Dateischreiben oder Denial of Service.

Der Musterfall ist CVE-2015-4852: Oracle WebLogic deserialisierte unauthentifizierte Java-Objekte, die über das T3-Protokoll an TCP 7001 gesendet wurden, auf unsichere Weise; mit Apache Commons Collections im Classpath erzeugte das Werkzeug ysoserial ein funktionierendes RCE-Gadget. Oracles erster Patch setzte auf eine fragile Deny-List von Klassen, statt die Deserialisierung nicht vertrauenswürdiger Daten grundsätzlich zu unterbinden. Ähnliche Fehler trafen Apache Struts (CVE-2017-9805, über XStream) und zahllose PHP-unserialize()-Object-Injection-Bugs. In der OWASP-Liste wanderte die Kategorie von A8:2017 in das umfassendere A08:2021 – Software and Data Integrity Failures.

flowchart LR
  A[Angreifer] -->|manipulierter serialisierter Blob<br/>Cookie / T3 / API-Body| APP[Anwendung]
  APP -->|deserialisiert untrusted Bytes| DZ[Deserialiser]
  DZ -->|instanziiert Objekte<br/>ruft Magic-Methoden auf| GC[Gadget-Chain<br/>im Classpath]
  GC -->|erreicht gefährliche Senke| RCE[Runtime.exec / Dateischreiben]
  APP -. Abwehr .-> SIG[Signierte Payload +<br/>Typ-Allow-List]
  SIG -.->|unbekannte Typen ablehnen| DROP[Verwerfen]

Schutzmaßnahmen: nicht vertrauenswürdige Daten niemals deserialisieren; schemagebundene Formate bevorzugen (reines JSON, Protobuf) ohne Typ-Rekonstruktion; serialisierte Payloads signieren oder per HMAC schützen; eine strikte Allow-List deserialisierbarer Typen erzwingen; und Runtimes gepatcht halten — modernes .NET hat BinaryFormatter als veraltet markiert und entfernt.

Beispiele

  1. 01

    Java-App deserialisiert ein Session-Cookie mit Commons Collections im Classpath — Folge: RCE.

  2. 02

    Python-Dienst führt pickle.loads auf nutzerkontrollierten Bytes aus.

Häufige Fragen

Was ist Unsichere Deserialisierung?

Schwachstelle, bei der eine Anwendung nicht vertrauenswürdige Daten deserialisiert und Angreifer beliebige Objekte erzeugen — häufig mit Remote-Code-Execution. Es gehört zur Kategorie Schwachstellen der Cybersicherheit.

Was bedeutet Unsichere Deserialisierung?

Schwachstelle, bei der eine Anwendung nicht vertrauenswürdige Daten deserialisiert und Angreifer beliebige Objekte erzeugen — häufig mit Remote-Code-Execution.

Wie schützt man sich gegen Unsichere Deserialisierung?

Schutzmaßnahmen gegen Unsichere Deserialisierung kombinieren typischerweise technische Kontrollen und operative Praktiken, wie in der Definition oben beschrieben.

Welche anderen Bezeichnungen gibt es für Unsichere Deserialisierung?

Übliche alternative Bezeichnungen: Unsafe Deserialization, Objekt-Deserialisierungs-Schwachstelle.

Verwandte Begriffe

Siehe auch