Date 2026-06-20. Target: RAGFlow Browser-component SSRF (cycle257). This is a CORRECTION lesson - I staged it as a HUNTR CANDIDATE (cash) with "not individually disclosed," and the max-depth deep-drill found it WAS disclosed: open GitHub Issue #15171 (galuis116, 2026-05-23) + open fix PR #15172 name the exact agent/component/browser.py / _prepare_upload_url_file / upload_sources sink. Caught before submission. Reputation protected, but the gate failed on the first pass and must be hardened.
My round-3 disclosure check (and the wave fleet agent) searched: CVE/NVD/cvedetails, GHSA advisories, huntr.com DISCLOSED reports, and general web ("ragflow browser ssrf"). All came back "not individually disclosed" - and that was literally true for those SOURCES. But #15171 is an OPEN GitHub ISSUE - a bug report filed by a researcher, NOT yet a CVE, NOT a GHSA advisory, NOT a huntr-DISCLOSED (public) report, NOT a merged PR. None of my search surfaces indexed it. The general web search didn't rank it. So I concluded undisclosed when a month-old public issue named the exact sink.
Before staging ANY finding as not-yet-disclosed, run ALL of these, searching by the EXACT sink identity (file path + function name + param name), not just the vuln class:
1. OPEN and CLOSED GitHub issues of the repo: search the issues for the file name (browser.py), the function (_prepare_upload_url_file), the param (upload_sources), and the class (SSRF). Open issues are the BIGGEST blind spot - a researcher who reported-but-not-yet-CVE'd lives here. gh issue list -R owner/repo --search "<term>" --state all or WebFetch the issues search URL.
2. OPEN and merged PRs touching the sink file: gh pr list -R owner/repo --search "<file>" --state all. An open fix PR (like #15172) is a dead giveaway someone already found it. Also git log --follow -- <file> if full history is available.
3. CVE/NVD/GHSA advisories (what I did do).
4. huntr.com/repos/
The decisive miss was steps 1-2. A finding is "not individually disclosed" ONLY after the repo's own issues AND PRs are clean for the exact sink. The huntr cash gate is "reported via huntr FIRST and not already disclosed" - an open public issue/PR naming the sink means a maintainer/researcher already has it = dup = $0.
The directive forced an EXHAUSTIVE search by exact sink name across issues+PRs+advisories+CVE+huntr+web. The fast pass searched by class+source-type and stopped at "no CVE/advisory/huntr-disclosed." Lesson: the disclosure gate's THOROUGHNESS must scale with the stakes - a quick class-level search is fine to TRIAGE, but a CASH submission requires the exact-sink-name sweep of open issues+PRs. Make the exact-sink-name issue/PR search a REQUIRED step before any "not disclosed -> stage as candidate" claim, not an optional deep-drill extra.
The hard rule "a finding is only a HUNTR CANDIDATE after a LIVE PoC + the operator's independent pass" plus the operator-ordered deep-drill caught this before any submission. No dup was filed, no standing lost. But relying on a later drill to catch a first-pass miss is fragile - hence promoting the exact-sink-name issue/PR search INTO the standard disclosure gate.