Lab Journal
How I traced the vulnerability from patch → root cause → attack surface → impact.
01–10
01/Lab Journal/CVE Patch Diffing
How to Read a Security Patch Like a Researcher
A patch is a map from intended fix to original weakness — if you read the check that was added, not the changelog sentence.
How a researcher reads a security patch: version pair, changed function, added check, and the weakness the check implies. No exploit walkthrough.
Read the journal note02/CVE Patch Diffing/CVE Patch Diffing
CVE Patch Diffing: Finding the Root Cause
CVE-XXXX is a label. The research product is the path from version pair to the invariant the fix finally enforced.
A repeatable patch-diffing series: vulnerable version, fixed version, git diff, changed function, security check, root cause, impact. No live exploit.
Read the journal note03/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 note05/CVE to Real Risk/CVE to Real Risk
Authentication → Authorization → Privilege Escalation
Most “broken access control” notes skip the hop that matters: who is authenticated, what was authorized, and whether that principal can reach a privileged sink.
A tracing model for identity bugs: authentication, object-level authorization, then privilege escalation — including when the path can become RCE.
Read the journal note06/CVE to Real Risk/CVE to Real Risk
SSRF: From URL Parser to Server-Side Impact
SSRF research starts at the parser — scheme, host, redirect — and ends at what the server can reach, not at a single blocked IP string.
How a researcher traces server-side request forgery from URL parsing to internal impact, including when it stays data access and when it can precede RCE.
Read the journal note07/CVE to Real Risk/CVE to Real Risk
API Authorization Vulnerability Research
API research is object-level authorization under a real second tenant — not a swagger file and not a scanner’s “missing rate limit” row.
How the laboratory researches API authorization: tenancy, object IDs, batch endpoints, and the hop from data access to privileged sinks.
Read the journal note08/AI Infrastructure/AI Infrastructure RCE
AI Infrastructure Attack Surface: Where Can RCE Happen?
In 2026 the model is not the interesting boundary. The inference server, the loader, and the plugin RPC are.
A surface map for RCE in AI infrastructure: frameworks, inference servers, model loading, serialization, RPC, plugins, sandboxes, and containers.
Read the journal note09/AI Vulnerability Research/AI-Assisted Validation
How to Validate an AI-Generated Vulnerability
AI can propose candidates. The laboratory only publishes what a human can trace: false positive, reachability, exploitability, patch.
Series opener: why candidate generation is not research, and how we validate AI-suggested weaknesses without turning the blog into an exploit mill.
Read the journal note10/CVE to Real Risk/CVE to Real Risk
CVE to Exploitability: Measuring Real-World Risk
A CVE number is not a risk score. Risk is versions, exposure, reachability, authentication, network, exploitability, impact, and known exploitation.
How the laboratory ranks a public CVE for real-world risk, using exposure and KEV — not CVSS theatre and not an exploit demo.
Read the journal note