Repository navigation
fix(security): SSRF guard checks resolved addresses, pins connection (v0.12.299) - #506
Conversation
…he connection isBlockedSsrfHost() checked the hostname as written, so public names that resolve to private addresses (localtest.me, 127.0.0.1.nip.io, 169.254.169.254.nip.io) passed, and fetch() re-resolved the name to connect, leaving a DNS-rebinding window. Each hop now resolves the host, refuses if any address is blocked, and connects only to the vetted addresses. Behind an upstream proxy the request still goes through it, with the resolve-time check.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: 🔵 Low · up to
|
img2img
image/maskURL downloads:ssrfSafeFetchchecked only the literal hostname, so public names resolving to private addresses (localtest.me,127.0.0.1.nip.io,169.254.169.254.nip.io) passed, andfetch()re-resolved to connect (DNS-rebinding window). Reported externally.lookupoverride on node:http(s) — no second resolution. Host/SNI/cert still use the hostname. No undici dependency (undici 8 does not load on Node < 22.15).CLAWROUTER_ALLOW_PRIVATE_FETCH=1unchanged.Verified live:
localtest.meand127.0.0.1.nip.ioare refused; public HTTPS through a redirect still returns 200. Release bump to 0.12.299 included.Summary by CodeRabbit