RCE + Deserialization
Why untrusted deserialization becomes remote code execution.
- → Untrusted Input
- ↓ Deserializer
- ↓ Object Construction
- ↓ Dangerous Gadget / Sink
- ↓ Code Execution
If any box is missing, you usually have a crash or a data bug — not RCE. Notes in this program fill the boxes with function names from public trees after validation, then stop at mitigation.
Notes
03/RCE + Deserialization/RCE + Deserialization
Why Untrusted Deserialization Can Become RCE
Remote code execution here is a data-flow property: untrusted bytes are allowed to construct objects that already know how to run code.
A class study of untrusted deserialization. The object is the data flow — not a gadget chain, not a payload, not a live exploit.
Read the journal note04/RCE + Deserialization/RCE + Deserialization
RCE Attack Surface in Modern Web Applications
Web RCE is rarely “the framework is broken.” It is a reachable sink behind a parser, template, upload, or admin feature the application chose to expose.
Where remote code execution actually lives in modern web apps: parsers, templates, uploads, expression languages, and admin debug surfaces.
Read the journal note
FAQ
Questions
- What is untrusted deserialization?
- Decoding a rich object format from bytes the caller controls, using a format that can encode behavior — for example Python pickle or similar construction plans — instead of inert data.
- When is deserialization actually remote code execution?
- Only when three facts hold: the input is attacker-controlled, the deserializer can instantiate types that perform work, and those types exist in the runtime. Missing one usually yields a crash or a data bug.