RCE + Deserialization
Untrusted input → deserializer → object construction → dangerous sink → code execution. The data flow is the research object.
Research
Vulnerability Research Lab Journal.
This is not a CVE glossary. Each note traces a weakness the way a researcher does: patch → root cause → attack surface → impact. We do not publish exploit instructions.
Three axes
- RCE Research
How untrusted input becomes code execution — deserialization, gadgets, and reachable sinks — without publishing exploit recipes.
- CVE Research
From public patch to root cause: version pair, diff, changed function, security check, impact. Identifiers are claimed only after coordination.
- AI Infrastructure Security
Inference servers, model loading, serialization, RPC, and plugins — the network-facing stack around the model.
Five research programs
CVE Patch Diffing
Vulnerable version → fixed version → git diff → changed function → security check → root cause → impact.
AI Infrastructure RCE
Framework, inference server, model load, serialization, RPC, ZMQ, API, plugin, sandbox, container.
AI-Assisted Validation
Candidate generation is cheap. False positive, reachability, exploitability, and patch verification are the work.
CVE to Real Risk
CVE → versions → exposure → reachability → auth → network → exploitability → impact → known exploitation (KEV).
Unified note structure
Every journal note uses the same twelve sections. If a heading does not apply, the note says so — it does not skip the heading to inflate RCE.
- 01 Executive Summary
- 02 Vulnerability
- 03 Affected Software
- 04 Attack Surface
- 05 Root Cause
- 06 Data Flow
- 07 Why It Becomes RCE
- 08 Patch Analysis
- 09 Detection
- 10 Mitigation
- 11 Lessons Learned
- 12 References
Lab journal
How we traced it.
01 · Lab Journal
How to Read a Security Patch Like a Researcher02 · CVE Patch Diffing
CVE Patch Diffing: Finding the Root Cause03 · RCE + Deserialization
Why Untrusted Deserialization Can Become RCE04 · RCE + Deserialization
RCE Attack Surface in Modern Web Applications05 · CVE to Real Risk
Authentication → Authorization → Privilege Escalation06 · CVE to Real Risk
SSRF: From URL Parser to Server-Side Impact07 · CVE to Real Risk
API Authorization Vulnerability Research08 · AI Infrastructure
AI Infrastructure Attack Surface: Where Can RCE Happen?09 · AI Vulnerability Research
How to Validate an AI-Generated Vulnerability10 · CVE to Real Risk
CVE to Exploitability: Measuring Real-World Risk
Surfaces under study
Web applications · APIs · Deserializers · Inference servers · Model loading · RPC / ZMQ · Plugin systems · Authentication and authorization · URL parsers · Open-source patches
FAQ
How this journal is searched
- How do I read a security patch like a researcher?
- Ignore the changelog sentence. Compare the last vulnerable tag with the first fixed tag, name the function that gained a check, and write the invariant that check now enforces.
- How to read a security patch
- Where can RCE happen in AI infrastructure?
- On network-facing pieces around the model: inference servers, model loading, serialization, RPC, ZMQ, APIs, plugins, sandboxes, and containers — not only in prompts.
- AI infrastructure attack surface
- How do you validate an AI-generated vulnerability?
- Treat the model output as a candidate. Filter false positives, prove reachability from untrusted input, assign an impact class, then verify any existing patch before disclosure.
- AI-assisted validation
- How do you measure real-world CVE risk?
- A CVSS score is not enough. We ask: affected versions, exposure, reachability, authentication, network access, exploitability, impact class, and whether CISA lists it as known exploited (KEV).
- CVE to real-world risk
Engage
Put your controls under test.
Tell us what needs to be validated. We reply with scoping questions, rules of engagement, and an NDA before any testing.