The runtime is the language engine that executes the application: the PHP, Python, Node.js, Java, Ruby, or .NET process that parses and runs developer code. This layer owns a distinct class of vulnerabilities, separate from the application logic above it (Code) and the server platform beneath it (Platform). The test for whether a bug belongs here: would it still exist if the application source were benign and the front-end server were hardened, because the weakness is in how the engine parses, executes, or bridges to the OS?

Runtime bugs are overwhelmingly engine-specific: a PHP object-injection chain, a Java gadget chain, and a Python pickle payload share a name and nothing else. So this area is organized by primitive, then by language, because the gadgets and payloads diverge per engine.

Where it breaks#

• Deserialization. Engines that rebuild objects from a byte stream run engine-defined callbacks (magic methods, __reduce__, readObject) during reconstruction. Feed the sink attacker-controlled bytes and those callbacks become a code-execution chain.
• Stream wrappers. Engines expose pseudo-protocols (php://, phar://, data://) that turn an innocuous file operation into source disclosure, remote inclusion, or deserialization.
• Sandboxes and function restrictions. Deployments that try to contain the runtime (disable_functions, open_basedir, a language sandbox, a Node vm) rely on boundaries the engine itself can be coaxed to cross.

Sections#

• Insecure deserialization: rebuilding attacker-controlled objects into RCE, by language (PHP, Python, Java, Ruby, .NET, Node.js).
• File wrappers and stream handlers: engine stream wrappers that escalate file operations to disclosure, deserialization, and RCE.
• Sandbox and function restriction escape: defeating disable_functions, open_basedir, and language or VM sandboxes.

References#

• PortSwigger Web Security Academy: Insecure deserialization
• OWASP: Deserialization of untrusted data