The "guard-exists-but-unwired" SSRF tell - now a 3-instance validated pattern (2026-06-21)

The pattern

When auditing a "fetch-a-user-URL" sink for SSRF, the strongest finding (and the strongest anti-by-design argument) is when the project HAS AUTHORED an SSRF/internal-IP guard somewhere in its own codebase but FAILS TO CALL IT on the sink you're looking at. The existence of the guard proves intent-to-block-internal -> reaching internal/metadata via the unguarded sink is a DEFECT, not the promised "fetch-a-URL" feature. This defeats the maintainer's #1 rejection ("SSRF in a fetch tool is by-design").

How to detect it (cheap, do it on every SSRF candidate)

Find the sink (grep outbound fetchers: requests/httpx/aiohttp/urllib + selenium scrapers).
Grep the WHOLE repo for an existing guard: is_url_safe|_validate_url|IsInternetIp|private|loopback|169.254|link.?local|allowlist|deny.?list|is_internal.
If a guard EXISTS, find its callers (grep -rn <guardName>). If the SSRF sink you found is NOT among the callers -> "guard-exists-but-unwired" = high-value, by-design-defeating finding.
Confirm no GLOBAL egress proxy/allowlist intercepts the path either.

The 3 validated instances

Bisheng cycle264 (unauth): guards the minio-share-host elsewhere + has scheme/netloc parse, but NO internal-IP/egress restriction on async_file_download -> unauth metadata reach (LIVE-confirmed: real 169.254.169.254 fetch).
openagent cycle265 (authed): authored util/network.go IsInternetIp() (correct private/loopback reject) but its ONLY caller is an unrelated util; web_fetch.go fetches the user URL with zero validation. The unwired guard IS the headline anti-by-design fact.
lollms cycle266 (authed): authored _validate_url (files.py:348, the CVE-2026-0560 fix, blocks private/loopback/link-local + 169.254.169.254) and APPLIES it in _download_image_to_temp - but the ScrapeMaster scrape-url sink (stores.py) + notebook scrape sink never call it. Disciplined sibling in the SAME repo proves the asymmetry.

Why it compounds

It's the cleanest severity-escalator for the SSRF-niche cash vein: it converts a "Low/by-design fetch-a-URL" into a "High unguarded-internal-reach" by citing the project's OWN guard as the standard it failed to meet.
The disciplined sibling (a fetcher that DOES call the guard) is your set-difference anchor - quote it in the report.
Especially common after a FIRST SSRF gets CVE'd: the maintainer point-fixes the ONE reported sink with a new guard fn, then leaves sibling fetchers unwired (the incomplete-fix + SSRF veins intersect here). So: when a repo has a recent SSRF CVE, grep for the guard the fix added and find every OTHER fetcher that doesn't call it. (lollms = exactly this: CVE-2026-0560 added _validate_url to files.py; scrape-url never got it.)

Caveat learned same cycle (lollms)

A heavily-CVE'd / popular target raises private-dup risk (huntr reports are embargoed/invisible until disclosed). The guard-unwired finding can be technically strong AND already privately reported. Flag the saturation-risk honestly; let the operator's independent pass + the platform's dup-detection adjudicate. Don't over-invest live-PoC compute on a popular target pre-greenlight. Related: [[feedback_cross_fork_portlag_primitive]] (the incomplete-fix-after-CVE intersection); the cycle264 live-SSRF-confirm kit (canary-with-control + status-oracle).