Opening the research log

Until now, most of what we found existed only inside a vendor’s ticket. A reference number, a status badge, and nothing else. Whatever actually happened on the way there stayed with us. This log is where that part goes.

What gets published

The interesting half of a finding is never the conclusion. It is the reasoning: why that endpoint looked wrong, which assumption turned out to be false, and what changed when it finally broke. For every bug that lands, there is a much longer list of attempts that went nowhere — and that list is usually the part another researcher can actually use.

So a write-up here carries:

Why we looked there — the code-audit note or the traffic observation that narrowed the surface
Reproduction — what the vulnerable build does, and what the patched build does instead
The dead ends — what should have worked, did not, and why
Variant analysis — whether the same pattern survives somewhere else in the codebase

Disclosure rules

Nothing before the patch. A write-up goes up after the vendor ships a fix and agrees to publication. Reports that are merely accepted do not get named here, not even by reference number.
Proof of concept up to reproduction, no further. We include what is needed to show the flaw is real. We do not publish finished tooling that takes over an account as-is.
No one else’s data. Real tokens, real user identifiers, and anything belonging to a third party that surfaced during testing get removed or replaced.

The third rule is the one that actually bites. A single screenshot attached to a write-up will happily include a stranger’s email address in the corner. That is why publication gets its own review pass rather than being a step in the author’s own checklist.

What we will cover

Authentication and authorization boundaries in web applications, the API contract between mobile clients and their backends, IPC and privilege boundaries in desktop software, the Windows and Linux kernels, and open source code audit. The same surfaces listed on the home page.

Methodology posts will be mixed in — specifically, what measurably improved after we put an LLM in the pipeline and what stubbornly did not. There is a lot of noise in that space right now, and very little of it reports the failure rate.

Work is still queued behind vendor patches. We do not pick the order. The vendors do.