Date 2026-06-20. Lane: huntr.com paid AI/ML. Sweep: 6 mainstream targets (ComfyUI, Open WebUI, vLLM, Dify, Gradio, MLflow) via first_patched-verifier. Result: 0 cash candidates, but the methodology lesson is the yield.
ComfyUI 0.25.0 (LATEST) has a GENUINE live unauth arbitrary-file-read: folder_paths.get_annotated_filepath is a bare os.path.join(base_dir, name) with no traversal guard, reachable via the unauth /prompt API through LoadImage (and ~10 sibling nodes), while the shipped fix only hardened the /view HTTP route. Textbook incomplete-fix set-difference, confirmed in source. The instinct was: build the live PoC to lock it.
That would have been WASTED. The bug is CVE-2026-6591 - already public, with published exploit code, vendor non-responsive, no patch. huntr cash requires BOTH (a) latest-affected AND (b) not-already-disclosed. ComfyUI passes (a) but FAILS (b): submitting a disclosed-CVE dup earns nothing. A 5-minute web search settled it; a 30-60 min docker+PoC would have proven a bug that pays $0.
Order the gate by cost, fail-fast on the cheapest disqualifier: 1. (cheapest, do FIRST) NOT-ALREADY-DISCLOSED. Before ANY live PoC, web-search the sink/CVE: is there already a CVE assigned + a public advisory + published exploit code + a huntr/GHSA report? If the exact sink is already public, STOP - it's a dup, $0, regardless of how live it is. This check is ~2 WebSearches. 2. (expensive, do SECOND) LATEST-STILL-AFFECTED + LIVE. Only once disclosure-status clears do you spend the source-verify + live PoC.
Running them in the wrong order (verify-live-then-check-disclosure) wastes the most expensive step on findings the cheapest step would have killed. This is the huntr-lane analogue of Gate-0 saturation: check "is this already known/claimed" before investing in "is this real."
A bug can be simultaneously (a) present in the latest release and (b) fully public/CVE'd - when the vendor never patched. That combination is common for unmaintained or slow-vendor projects (ComfyUI here: CVE assigned, vendor non-responsive, latest still vuln). "Latest is vulnerable" feels like the win condition but it is only HALF. Disclosure-status is the other half and it is orthogonal: a maintained project fixes-and-discloses (fails latest-affected), an unmaintained one stays-vuln-and-discloses (fails not-disclosed). The cash sweet spot is the narrow band: latest-affected AND a FRESH gap not yet public (e.g. a true incomplete-fix sibling the disclosed CVE didn't name).
Even a real incomplete-fix can be disclosed: if the public CVE/advisory already describes the still-vulnerable sink (as CVE-2026-6591 describes the node-level get_annotated_filepath traversal, not just /view), the "incomplete fix" is itself public. The fresh-cash version is when the public CVE named handler X, the fix covered X, and you find an undisclosed sibling Y sharing the root sink that nobody has reported. Verify Y is not in the advisory text / not separately CVE'd before staging.
Open WebUI, Gradio, MLflow, Dify all had their freshest advisories FIXED-COMPLETELY at HEAD with centralized guards and no unguarded siblings (Gradio's fixes survived 11- and 34-payload empirical bypass batteries). The first_patched-verifier incomplete-fix vein pays better on (a) projects with per-handler scattered guards (Gitea, Directus - where it has hit), and (b) smaller/faster-moving AI/ML OSS where fixes lag, than on the big well-resourced frameworks. Next huntr rounds: bias toward Flowise-tier (AnythingLLM, LibreChat, Letta, RagFlow, text-generation-webui) over the majors, OR pivot the majors to a DIFFERENT sink class than the one the maintainers just hardened (e.g. MLflow deserialization/YAML rather than the saturated _validate_path_is_safe path-traversal vein).
Surfaced repeatedly in the smaller-AI/ML wave (Letta, Haystack, and earlier n8n). A powerful UNGUARDED sink is only cash-eligible if it CONTRADICTS something: a prior fix (incomplete-fix), or the project's own security claims/docs. If the project documents the sink as trusted-input by design, a report is an "intended-functionality" rejection ($0), not a vuln. Examples that DIED here:
- Haystack hayhooks /deploy_files: unauth RCE by uploading a pipeline_wrapper.py - but hayhooks is documented "do not expose to the public internet"; unauth code-exec on the deploy API is intended. Same trap as n8n code-node, MCP-server exec.
- Letta fetch_webpage/web_search SSRF: an LLM-invoked builtin tool fetching whatever URL the agent is told to - the generally-accepted "agent does what you instruct" class for self-hosted agent runtimes. Also default-no-auth, so "missing auth on a sibling route" finds nothing novel (nothing is authed by default).
- Pipeline/agent deserialization (Pipeline.from_dict, import_class_by_name): documented trusted-input serialization model; no prior fix circumvented => not an incomplete-fix.
Refinement to the set-difference: filter unguarded sinks not just by guard-PRESENCE but by (i) is the CLASS already disclosed (dup), (ii) is the only reach through ANOTHER already-disclosed sink (subsumed), (iii) does the project CLAIM this is safe / does a prior fix exist to contradict (else by-design). A guard-gap is only cash-eligible when it breaks a promise the project actually made. Contrast the WIN (RAGFlow Browser SSRF, [[2026-06-20-cycle257-guard-retrofit-census-the-N-plus-1th-callsite]]): there the project DID make the promise - it built assert_url_is_safe and applied it to 12 siblings - so the 13th unguarded site is a broken promise, not by-design.