Repository navigation
fix(security): block IPv4-mapped IPv6 SSRF targets in URL-normalized … - #29
Merged
Merged
Conversation
…hex form The WHATWG URL parser rewrites embedded IPv4 in IPv6 hosts to hex before the guard sees them: http://[::ffff:169.254.169.254]/ arrives as [::ffff:a9fe:a9fe]. isBlockedIpv6 only matched the dotted ::ffff:a.b.c.d form, so loopback / private / cloud-metadata targets written this way passed checkOutboundUrl — an SSRF bypass on the HTTP Request node. - ssrf.ts: decode hex-embedded IPv4 (::ffff:x:y mapped and deprecated ::x:y compatible) and re-apply the IPv4 block rules - tests: new cases go through checkOutboundUrl (the engine's call path), covering hex/expanded IPv6 forms plus decimal/octal/hex IPv4 hosts (already safe via parser normalization); red before, green after - tutorial 01: A5 note + post-release finding + parser-differential lab Found while pointing the builder validation panel at the same guard.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Merged
csupenn
added a commit
that referenced
this pull request
Sep 26, 2026
## Description
Promote dev → main.
- fix(security): SSRF guard now blocks IPv4-mapped IPv6 targets in the
URL
parser's hex form, e.g. [::ffff:a9fe:a9fe] = cloud metadata (#29)
- test(security): validation-engine covered 0% → 100% lines; builder
Validation panel now uses the same SSRF/cycle rules the server enforces
(#30)
- chore(ci): coverage thresholds made honest and blocking; contributor
docs
refreshed (#28)
## Testing
Combined dev verified locally: type-check clean, lint 0 errors, test:ci
603 tests +
coverage thresholds, build OK.
## Security Impact
Closes an SSRF bypass on the HTTP Request node. Residual: DNS rebinding
(documented).
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.
guard as [::ffff:a9fe:a9fe]. The guard only recognized the dotted form, so a workflow's HTTP Request node could reach
loopback, private network or cloud-metadata addresses written this way.
that real requests go through.
after. They also confirm decimal, octal and hex IPv4 hosts (like http://2130706433/) were already blocked.
finding and a new lab exercise on it; the claim is true again.
…hex form
The WHATWG URL parser rewrites embedded IPv4 in IPv6 hosts to hex before the guard sees them: http://[::ffff:169.254.169.254]/ arrives as [::ffff:a9fe:a9fe]. isBlockedIpv6 only matched the dotted ::ffff:a.b.c.d form, so loopback / private / cloud-metadata targets written this way passed checkOutboundUrl — an SSRF bypass on the HTTP Request node.
Found while pointing the builder validation panel at the same guard.