Skip to content
REDMAW

Applications

Insecure Deserialization

Untrusted serialized data becomes a code-execution problem when the server reconstructs objects or behavior without enforcing a safe trust boundary.

RedMaw

Definition

Deserialization turns stored or transmitted data back into live objects. It becomes a security problem when the data crossing that boundary is attacker-influenced and the reconstruction process can be steered into behavior the application never intended.

Why this is not a generic CVE

It is tempting to treat this as a library-version issue. The more accurate framing is a trust decision: the server is rebuilding state from input it does not control, and the reconstruction machinery may invoke application code as a side effect. A patched library in an application that still trusts hostile object state has moved the problem, not removed it.

Where it usually appears

  • Session or state blobs held in cookies or hidden fields
  • Message-queue consumers processing serialized payloads
  • Caching layers that store reconstructed objects
  • Inter-service payloads assumed to be internal and therefore trusted
Where it leads
  1. Internet
  2. Application
  3. Unsafe Object Processing
  4. Application Control
  5. Sensitive System

Each hop validated by successful exploitation

Tags

  • deserialization
  • code execution
  • trust boundary

Validation

How RedMaw validates this attack

Validation runs only inside authorized scope, with agreed exploitation limits.

  1. 01Locate boundaries where serialized data is reconstructed
  2. 02Establish whether the payload is attacker-influenced
  3. 03Determine what the reconstruction can be steered to do within scope
  4. 04Preserve the payload and the resulting behavior as evidence

Stop assuming you are secure. Prove it.

Continuously test what an attacker can actually reach across your applications, SaaS identities, internal infrastructure and AI systems.