Context: prior session staged Bisheng unauth SSRF as source-confirmed + faithful-harness only (full-image E2E left to "a capable host" - the 3.8GB box OOM'd the 6-svc stack). Box upgraded to 15GB/4vCPU this session -> booted the full 9-service stack and closed the live-PoC gap. Disclosure-gate was already PASS+coord-verified (Floor honored: no compute before Gate-0).
Missing-required-param crash INSIDE the sink = clean pre-auth reachability proof. Sending the unauth request with NO file_url made the handler crash at async_file_download ('NoneType'.split) - a stack trace that names the sink file:line and proves the request reached it with no 401/403 and before any auth/operator resolution. Cheaper + more convincing than a full successful fetch for the "is it really unauth + does it really reach the sink" question. Use this first.
Internal-only canary with NO published port = unambiguous SSRF proof + a built-in control. Run the canary as a container on the app's docker network with no host port. The control (curl from the host -> "could not resolve / unreachable") proves the attacker can't reach it directly; the canary's access log showing the fetch FROM THE BACKEND CONTAINER IP (not the attacker IP) with the app's HTTP-client User-Agent proves the server made the request. The from-IP + UA together kill the "maybe the attacker's curl did it" objection.
Error-message status reflection = a semi-blind SSRF read oracle (port scan + path enum) even when full body read-back needs app state. Here fetch-200 -> one error ("not found default_operator", i.e. proceeded past fetch) vs fetch-non-200 -> "returned status code ". That single distinguishable bit lets an unauth attacker map open/closed/filtered internal ports AND enumerate valid metadata paths - so "blind" undersells it. Always probe whether the post-fetch error path leaks the fetched status/length/timing.
Fetch-before-auth ordering means you DON'T need to seed app state to prove the SSRF. Because the sink fires before get_default_operator (which 500s on a fresh un-onboarded DB), the SSRF reproduces on a stock fresh boot - no need to create users, KBs, or configure embeddings. Only the body-reflection-to-attacker amplifier needs an onboarded operator (true of any production instance). Scope honestly: prove what the fresh boot proves; attribute full read-back to production state.
Boot-cost control on a small-core box: the stock entrypoint ran uvicorn --workers 8 -> load avg 14 on 4 vCPU, stuck importing for minutes. Host-mounted entrypoint -> patched to --workers 1 + stopped the celery worker container (not in the SSRF path) -> backend ready in ~1 min. Worker count is irrelevant to the vuln. Generally: identify which of the N services are actually in the vuln's code path and starve the rest of CPU.
169.254.169.254 is a REAL reachable metadata service. The SSRF fetched HTTP 200 from /metadata/v1.json, /metadata/v1/id, /metadata/v1/hostname live - turning a hypothetical "metadata-cred-theft" impact claim into a directly-proven real-metadata reach. When your test host is itself a cloud VM, the link-local metadata endpoint is free live proof (reading your own metadata = authorized). Note the cloud's actual metadata path (DO=/metadata/v1/, AWS=/latest/meta-data/, GCP=/computeMetadata/v1/ w/ header).These 5 techniques generalize to ANY "fetch-a-user-URL" sink behind a thin/absent auth layer (the SSRF-niche-queue class). The canary-with-control + status-oracle + missing-param-crash trio is a fast, high-confidence live-confirm kit. Banked for the next SSRF candidate. Related: [[feedback_cross_fork_portlag_primitive]] is a different vein; this is the SSRF-live-confirm kit.