Repository navigation
Conversation
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes a gap in
resolveSafeFetchUrl, the SSRF boundary guard that validates author-controlledskill_uribefore the server fetches it (/api/skills/{id}/rawchain-only path andfetchPublicUrl).ipv4LooksBlockedblocked IANA TEST-NET ranges except192.0.248.0/15(TEST-NET-3, RFC 6890). The runtime DNS-layer guard (publicUrlFetch.server.tsblockedV4) already rejected it, so the current fetch path is double-guarded — butsafeFetchis the exported, standalone-usable primary SSRF check, its doc comment (IPV4_BLOCKLIST_NOTE) advertised "TEST-NET-3" coverage while omitting this range, and the raw-download route's redirect loop depends onresolveSafeFetchUrlfor every hop. This PR adds the range toipv4LooksBlockedand aligns the doc note with the full code blocklist.Only adds blocks to reserved/documented special-use ranges; no range is unblocked, so no legitimate public skill URL is affected.
Verified
192.0.248.0/15was allowed (gap); after change it is blocked. Adjacent out-of-range values (192.0.247.255) remain allowed.web/__tests__/lib/safeFetch.test.ts: added RFC 6890 range coverage (block boundaries 248.0/248.1/248.255/249.0/254.0/255.0/255.255) and out-of-range allow-list (247.255, 198.51.101.1, 198.51.99.255, 203.0.112.1).npm run format:check(pass),npm run lint(pass),next typecheck(pass),vitest run(1311 tests pass).next build --webpackfailed locally only becauseDATABASE_URL/web/.env.localare not set in the cron shell (pre-existing env limitation; the failure is in DB-backed prerendering of/sitemap.xmland unrelated to this change). The Vercel build is the authoritative build gate (CItestjob does not runnext buildper AGENTS.md).Files
web/lib/safeFetch.ts: +if (a === 192 && b === 0 && c >= 248) return true;and updatedIPV4_BLOCKLIST_NOTE.web/__tests__/lib/safeFetch.test.ts: extended TEST-NET-3 test with RFC 6890 range + boundaries; added out-of-range allow-list cases.Not verified / caveats
gpg --list-secret-keysis empty), so the commit landed unsigned. To sign, run:git -C <checkout> commit --amend -S --no-edit && git push --force-with-lease origin fix/ssrf-testnet-blocklistafter unlocking/providing the signing key (per AGENTS.md signing rule).
DATABASE_URL(env, not code).Test Plan
safeFetch.test.ts— confirms 192.0.248.0/15 is rejected and boundaries/out-of-range values still pass.webvitest (1311) to confirm no regression to the SSRF/URL guard.format,lint,typecheck,vitest(test job). Vercel build gate is the authoritativenext build.Related
Supersedes the incomplete TEST-NET-3 coverage from PR #231, which blocked 198.51.100.0/24 + 203.0.113.0/24 (RFC 5737) but missed 192.0.248.0/15 (RFC 6890).