🔒️ Add SSRF_ALLOWED_HOSTS env for self-hosted internal APIs#2474
Open
klinux wants to merge 2 commits intobaptisteArno:mainfrom
Open
🔒️ Add SSRF_ALLOWED_HOSTS env for self-hosted internal APIs#2474klinux wants to merge 2 commits intobaptisteArno:mainfrom
klinux wants to merge 2 commits intobaptisteArno:mainfrom
Conversation
Self-hosted deployments often have legitimate internal corporate APIs on RFC1918 ranges (10/8, 172.16/12, 192.168/16). Since v3.14 the SSRF mitigation introduced for CVE-2025-64709 blocks every private range unconditionally, which prevents HTTP Request blocks from reaching those APIs without exposing them to the public internet. This adds an opt-in `SSRF_ALLOWED_HOSTS` env var (comma-separated list of hostnames). When the URL's hostname matches an entry, the validator skips the **RFC1918 private-range checks only**. Every other protection remains active even for allowlisted hosts: - link-local 169.254.0.0/16 (the actual CVE vector → metadata services) - loopback 127.0.0.0/8 and IPv6 ::1 - 0.0.0.0/8 - IPv6 link-local fe80::/10 and unique local fc00::/7 - cloud metadata hostnames (metadata.google.internal etc.) - localhost (production) - decimal/hex/octal IP encoding - IMDS bypass headers (X-aws-ec2-metadata-token*, Metadata-Flavor) This means even if an attacker controls DNS for an allowlisted hostname and points it to 169.254.169.254, the link-local check still fires. The allowlist intentionally narrows what's relaxed: corp LAN access, not metadata-service access. Allowed hosts can also be passed via the new `allowedHosts` parameter (symmetric with `lookupHost`); the env var is the default. Tests cover: RFC1918 hostnames pass when listed, link-local/loopback still block for listed hosts, default behavior preserved when env unset, case-insensitive matching, no subdomain wildcarding.
|
@klinux is attempting to deploy a commit to the Typebot Team on Vercel. A member of the Team first needs to authorize it. |
Owner
|
@codex review |
|
Codex Review: Didn't find any major issues. 👍 ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
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
2 participants
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
Self-hosted deployments often have legitimate internal corporate APIs on RFC1918 ranges (10/8, 172.16/12, 192.168/16) — e.g., a backend chat API exposed only on the internal cluster network. Since v3.14, the SSRF mitigation introduced for CVE-2025-64709 / GHSA-8gq9-rw7v-3jpr blocks every private range unconditionally, which prevents HTTP Request blocks (and Function blocks via fetch) from reaching those APIs without exposing them to the public internet.
The advisory itself listed hostname allowlisting as one of the recommended mitigations (item #5: "Implement an SSRF-safe proxy or apply hostname allowlists for outgoing requests"), and this PR implements it as an opt-in env var.
What changes
SSRF_ALLOWED_HOSTS(comma-separated hostnames) parsed inpackages/envvalidateHttpReqUrlnow accepts anallowedHostsparameter (symmetric with the existinglookupHostinjection point); the env var is the defaultvalidateIPAddressis called with{ allowPrivateRanges: true }, which only skips the RFC1918 range checks (10/8, 172.16/12, 192.168/16)What the allowlist does NOT relax
Every other protection remains active even for allowlisted hosts:
This is the deliberate design: even if an attacker controls DNS for an allowlisted hostname and points it to 169.254.169.254, the link-local check still fires. The allowlist intentionally narrows what's relaxed — corp LAN access, not metadata-service access.
Test plan
Use case
Currently, self-hosters facing this hit dead-ends: their internal corp DNS resolves to 10.x, the validator rejects it, and the only escape valves are (a) expose the API publicly (security regression — adds attack surface), (b) downgrade to ≤ v3.13.x (re-introduces the vulnerable code path), or (c) maintain a fork with the validator patched (fragile, breaks on every upgrade). An opt-in env var resolves this without weakening the core mitigation.
I'm opening a companion issue (#2475) explaining the use case in more detail and to gather feedback if a different design is preferred — happy to iterate.