Verify, Then Claim — the kill rate behind incomplete-fix hunting

Most write-ups about finding CVEs show you the win. They skip the part that actually does the work: the leads you throw away.

Last month the ledger read 6 submitted, 6 held, 58 killed. That ratio isn't failure — it is the method. If you're not killing most of what you find, you're not verifying; you're guessing, and you'll ship a "critical" that a maintainer closes in thirty seconds with one comment: "that input isn't reachable."

Here's how I actually hunt.

The thesis: a patch guards an instance, not a sink

Fresh, unaudited code is crowded and noisy. Patched code is the opposite — someone has already told you exactly where a dangerous sink lives, in the fix commit. The only question left is the cheap, high-yield one:

Did the fix guard every sibling, path, encoding, and alias that reaches that sink — or just the one instance in the report?

Almost always, it's the latter. Maintainers patch the proof-of-concept in front of them, under time pressure, and the variant space stays wide open. The residual is a new vulnerability with a new ID.

The pipeline

1. Source from patches, not products. Recently-fixed advisories are the map. Read the fix commit, not the advisory text.
2. Diff what the patch actually constrains. A denylist? An allowlist? A check added at one call-site?
3. Ask "complete or merely fix-shaped?" A denylist that misses an alias of the same function. A guard that validates the original host but not the host after a redirect. A URL filter that never normalizes an IPv6 form. A check on the reported endpoint but not its sibling mutation.
4. Verify at the sink. This is the step everyone skips and the step that matters. A regex matching your payload is not a vulnerability. Proving the payload reaches the dangerous operation is. Most leads die right here — and they should.
5. Submit the residual, referencing the incomplete fix, with the reachability proof.

Where it pays

Three veins produce almost everything: SSRF, injection, and broken authorization. They share a property — a single sink with many roads leading to it — which is exactly the shape an incomplete fix leaves exposed. The recurring residual patterns, in the abstract:

• Denylist misses a sibling. The blocked function has an alias; the blocked separator has a cousin.
• Guard checks the wrong moment. Validation runs on the input the user typed, not on the value finally used — after a redirect, a re-parse, or a normalization.
• Filter never normalizes. SSRF allowlists that compare raw strings lose to alternate IP encodings and IPv6 literals.
• Authz added per-instance. A permission check lands on the reported action and not the neighboring one that mutates the same state.

None of these are clever. They're consistent, which is better.

The discipline that makes it credible

Two rules earn the right to claim anything:

• Verify before you rate. A finding has no severity until the sink is reached. "Looks exploitable" is a hypothesis, not a CVE.
• Verify your tooling, too. I once had a detector "confirm" a bug that was an empty-string artifact in my own harness. Trust the result only after you've proven the result.

That discipline is why the kill column is the longest one — and why the few that survive it tend to hold up in triage.

Why I'm not naming this month's findings

Because they're submitted and in triage. Naming a vulnerable target and its exact bypass before the maintainer ships a fix doesn't make me look clever; it hands a working exploit to whoever reads this against software that's still open. The methodology is safe to share. The live bypasses are not — not yet. When they're fixed and disclosed, they get their own posts.

Share the map. Hold the loaded ones until it's safe.