PoC lab — building the proof of concept
An advisory tells you a bug exists. These write-ups are the work in between: standing up a lab, diffing the patch, finding the primitive, and turning it into something that actually runs end to end.
Write-ups
1
First published
2026
Last updated
Nov 2026
All PoC Lab posts
1 entry## How these write-ups are put together
Every post in this section follows roughly the same shape, because that is the
order the work actually happens in:
1. **Read what the advisory does and does not say.** The precondition is usually
the only real hint you get.
2. **Stand up both versions side by side** — the vulnerable one and the patched
one — in isolated dependency trees, so nothing but the version number
differs.
3. **Diff the patch properly.** Not the release notes. The shipped code.
4. **Build a control first.** If you cannot show the benign case working, you
cannot claim the broken case is broken.
5. **Find the primitive, then chain it.** One variable at a time, with the raw
bytes dumped to disk at every step.
6. **Prove the fix kills it**, and be honest about what the fix does *not*
change.
7. **Make it useful to whoever has to triage it** — detection, an inert check
mode, and meaningful exit codes.
Everything here is written for defensive use: confirming exposure, testing
detection, and justifying an upgrade. Run it against systems you own or are
authorised to test.