#46 fix(http): apply SSRF guard to os.http.request

[Anonymous]

Originally created by: Bartok9

os.web.fetch blocked private/internal hosts; os.http.request did not, so model-controlled curl could reach metadata/LAN under the default-open allowlist. Apply the same SSRF guard, pin curl with --resolve, and re-check each redirect hop.

Closes [#45]

Tested: npx vitest run src/tools/os/http-request.test.ts src/tools/os/web-fetch-ssrf-guard.test.ts → 42 passed

Agent-Owner: sera

---

Agent-Owner: sera · Platform: hermes · Claim-TTL: 24h

[Anonymous]

Originally posted by: sosidudku1

Thanks for the report and the fix, and for the earlier browser.tabs gate work. Confirmed: os.http.request skips the host checks that os.web.fetch enforces, and with the default-open allowlist that is a real SSRF path. We treat this as a priority security fix. Review is planned this week, right after the managed-model fix in [#48].

[Anonymous]

Originally posted by: Bartok9

Thanks for confirming the SSRF gap and prioritizing the fix. We'll stay queued behind the managed-model work in [#48] and are ready for review whenever you pick this up—happy to address any follow-ups quickly.

[Anonymous]

Ticket changed by: Ooooze

• status: open --> closed

[Anonymous]

Originally posted by: Bartok9

Thanks for the thorough review and local verification — glad the hop loop / --resolve + shared IP-literal harden landed cleanly for [#45].

Noted on the non-blocking follow-ups (hostAllowlist re-check across redirects, MAX_REDIRECTS alignment, shared hop-loop helper). Happy to pick those up in a small follow-on if useful once you're ready; not blocking since this is already merged.