Serialization Security Review
Purpose
Find vulnerabilities caused by unsafe serialization, deserialization, object mapping, parser configuration,
and cross-boundary state transfer. Focus on cases where untrusted bytes, JSON, YAML, XML, cookies, view state,
cache blobs, or queue messages are turned into executable, privileged, or overly dynamic objects.
High-Risk Targets
Prioritize:
- Java native serialization and
ObjectInputStream
- Jackson polymorphic typing and unsafe default typing
- Fastjson auto-type behavior
- .NET
BinaryFormatter, LosFormatter, NetDataContractSerializer
- PHP
unserialize() and POP-chain entry points
- Python
pickle, marshal, and unsafe YAML loaders
- Node parsers that revive functions, prototypes, or constructors
- session cookies, view state, queue payloads, cache entries, and signed blobs crossing trust boundaries
Workflow
Step 1: Find Deserialization Boundaries
Locate where external or semi-trusted data is parsed, decoded, revived, or reconstructed:
- HTTP body parsers
- cookies and session stores
- file import handlers
- webhook processors
- message queue consumers
- cache/database blob readers
- mobile/app local state restores
Step 2: Classify the Input Trust Level
For each boundary, decide whether the input is:
- fully attacker-controlled
- user-controlled but signed/encrypted
- partner-controlled
- internal-only but reachable through weaker upstream systems
Do not assume "internal" means safe without an integrity guarantee.
Step 3: Identify Dangerous Parser Features
Look for:
- polymorphic type resolution
- class-name-based instantiation
- automatic object revival
- unsafe YAML/XML object construction
- magic methods, hooks, or callbacks triggered after deserialization
- prototype pollution or constructor abuse
- gadget-friendly libraries on the classpath or dependency tree
Step 4: Judge Exploitability
Confirm:
- the data crosses a trust boundary
- attacker influence reaches the parser
- type restrictions or integrity checks are absent, weak, or bypassable
- the resulting object graph has dangerous side effects or privileged behavior
Step 5: Recommend Safe Patterns
Prefer:
- explicit DTO binding
- strict schemas
- allowlisted concrete types
- data-only formats without executable behavior
- integrity validation before parsing
- safe parser defaults and feature disablement
Step 6: Report by Boundary
For each issue, state:
- boundary
- parser/serializer in use
- attacker control level
- impact
- exact hardening action
Guardrails
- Do not report plain serialization for output-only responses as a vulnerability by itself.
- Do not assume every JSON parser use is dangerous; focus on dynamic typing, unsafe features, and trust boundaries.
- Do not treat signed data as safe if the signing key is weak, leaked, or validation happens after parsing.
- Do not forget secondary entry points such as queues, caches, or admin import tools.
- Do not stop at
deserialize(); inspect post-deserialization hooks and object behavior.
Output Format
Use:
[SEVERITY] <serialization issue title>
Boundary: <entry point or state-transfer path>
File: <path>:<line>
Why it matters: <trust boundary + parser behavior + impact>
Fix: <concrete hardening action>
1---2name: eresus-serialization-review3description: Serialization and deserialization security review skill for object mappers, parser pipelines, message formats, and state transfer mechanisms. Trigger when the user asks to: "review serialization security", "check deserialization", "audit Jackson/Fastjson/YAML/XML parsing", "look for gadget-chain risk", "review session or message deserialization", or wants a focused audit of parser-driven attack surface. Complements eresus-sast-scanner with a deep dive on serialization abuse paths.4---5
6# Serialization Security Review
7
8## Purpose
9
10Find vulnerabilities caused by unsafe serialization, deserialization, object mapping, parser configuration,
11and cross-boundary state transfer. Focus on cases where untrusted bytes, JSON, YAML, XML, cookies, view state,
12cache blobs, or queue messages are turned into executable, privileged, or overly dynamic objects.
13
14## High-Risk Targets
15
16Prioritize:
17
18- Java native serialization and `ObjectInputStream`
19- Jackson polymorphic typing and unsafe default typing
20- Fastjson auto-type behavior
21- .NET `BinaryFormatter`, `LosFormatter`, `NetDataContractSerializer`
22- PHP `unserialize()` and POP-chain entry points
23- Python `pickle`, `marshal`, and unsafe YAML loaders
24- Node parsers that revive functions, prototypes, or constructors
25- session cookies, view state, queue payloads, cache entries, and signed blobs crossing trust boundaries
26
27---
28
29## Workflow
30
31### Step 1: Find Deserialization Boundaries
32
33Locate where external or semi-trusted data is parsed, decoded, revived, or reconstructed:
34
35- HTTP body parsers
36- cookies and session stores
37- file import handlers
38- webhook processors
39- message queue consumers
40- cache/database blob readers
41- mobile/app local state restores
42
43### Step 2: Classify the Input Trust Level
44
45For each boundary, decide whether the input is:
46
47- fully attacker-controlled
48- user-controlled but signed/encrypted
49- partner-controlled
50- internal-only but reachable through weaker upstream systems
51
52Do not assume "internal" means safe without an integrity guarantee.
53
54### Step 3: Identify Dangerous Parser Features
55
56Look for:
57
58- polymorphic type resolution
59- class-name-based instantiation
60- automatic object revival
61- unsafe YAML/XML object construction
62- magic methods, hooks, or callbacks triggered after deserialization
63- prototype pollution or constructor abuse
64- gadget-friendly libraries on the classpath or dependency tree
65
66### Step 4: Judge Exploitability
67
68Confirm:
69
70- the data crosses a trust boundary
71- attacker influence reaches the parser
72- type restrictions or integrity checks are absent, weak, or bypassable
73- the resulting object graph has dangerous side effects or privileged behavior
74
75### Step 5: Recommend Safe Patterns
76
77Prefer:
78
79- explicit DTO binding
80- strict schemas
81- allowlisted concrete types
82- data-only formats without executable behavior
83- integrity validation before parsing
84- safe parser defaults and feature disablement
85
86### Step 6: Report by Boundary
87
88For each issue, state:
89
90- boundary
91- parser/serializer in use
92- attacker control level
93- impact
94- exact hardening action
95
96---
97
98## Guardrails
99
100- Do not report plain serialization for output-only responses as a vulnerability by itself.
101- Do not assume every JSON parser use is dangerous; focus on dynamic typing, unsafe features, and trust boundaries.
102- Do not treat signed data as safe if the signing key is weak, leaked, or validation happens after parsing.
103- Do not forget secondary entry points such as queues, caches, or admin import tools.
104- Do not stop at `deserialize()`; inspect post-deserialization hooks and object behavior.
105
106---
107
108## Output Format
109
110Use:
111
112```markdown
113[SEVERITY] <serialization issue title>
114Boundary: <entry point or state-transfer path>
115File: <path>:<line>
116Why it matters: <trust boundary + parser behavior + impact>
117Fix: <concrete hardening action>
118```
aibot88