#8228: fix(link-understanding): block private IPs and internal hostnames in URL extraction
stale
Cluster:
SSRF Protection Enhancements
## Summary
Fixes SSRF vulnerability in link understanding module by reusing the robust URL validation from `infra/net/ssrf.ts`.
## The Problem
The `isAllowedUrl()` function in the link understanding module only blocked `127.0.0.1`, leaving the system vulnerable to Server-Side Request Forgery (SSRF) attacks. An attacker could send messages containing URLs to internal network addresses, cloud metadata endpoints, or internal domains, potentially exposing sensitive data like AWS IAM credentials or internal service information.
**Blocked before:** Only `127.0.0.1`
**Attack vectors that were not blocked:**
- `http://localhost/admin` - localhost hostname
- `http://169.254.169.254/latest/meta-data/` - AWS/GCP instance metadata
- `http://10.0.0.1/internal` - Private RFC1918 addresses
- `http://server.local/api` - .local domains
- `http://metadata.google.internal/computeMetadata/v1/` - GCP metadata
## Changes
- `src/link-understanding/detect.ts`: Import and use `isBlockedHostname()` and `isPrivateIpAddress()` from the existing SSRF protection module instead of the insufficient hostname check
- `src/link-understanding/detect.test.ts`: Add comprehensive tests for all SSRF attack vectors
## Test Plan
- [x] `pnpm build && pnpm check && pnpm test` passes
- [x] New tests validate blocking of:
- localhost hostname
- Cloud metadata endpoints (169.254.169.254)
- Private IP ranges (10.x, 172.16-31.x, 192.168.x)
- .local and .internal domains
- metadata.google.internal
## Related
- [CWE-918](https://cwe.mitre.org/data/definitions/918.html) - Server-Side Request Forgery
- Internal audit ref: VULN-010
---
*Built with [bitsec-ai](https://github.com/bitsec-ai). AI-assisted: Yes. Testing: fully tested (test written before fix). Code reviewed and understood.*
<!-- greptile_comment -->
<h2>Greptile Overview</h2>
<h3>Greptile Summary</h3>
This PR hardens `extractLinksFromMessage` URL filtering by replacing a single-hostname check (`127.0.0.1`) with the shared SSRF helpers in `src/infra/net/ssrf.ts` (`isBlockedHostname`, `isPrivateIpAddress`). It adds targeted tests covering localhost, cloud metadata IPs, RFC1918 ranges, and internal TLDs, aligning link-understanding’s allowlist logic with the repo’s broader SSRF protections.
<h3>Confidence Score: 5/5</h3>
- This PR is safe to merge with minimal risk; it narrows allowed URLs using shared SSRF utilities and includes matching tests.
- Changes are small and localized (hostname validation only) and reuse existing, already-reviewed SSRF logic for blocked hostnames and private IP detection. Added tests cover the new blocked cases and should prevent regressions.
- No files require special attention
<!-- greptile_other_comments_section -->
<!-- /greptile_comment -->
Most Similar PRs
#19525: security: add SSRF validation for external URLs
by Mozzzaic · 2026-02-17
86.2%
#8305: fix(browser): add SSRF protection to browser navigation
by yubrew · 2026-02-03
82.4%
#16197: feat(ssrf): enhance protection with comprehensive cloud metadata bl...
by bianbiandashen · 2026-02-14
82.3%
#23598: fix(msteams): add SSRF protection to attachment downloads via redir...
by lewiswigmore · 2026-02-22
79.0%
#11086: fix(mattermost): allow private network for inbound media download
by oskarmodig · 2026-02-07
78.6%
#8339: fix(tts): validate ElevenLabs base URL against allowlist
by yubrew · 2026-02-03
78.2%
#11812: fix: MSTeams attachment fetch follows redirects before allowlist ch...
by coygeek · 2026-02-08
77.0%
#5278: fix(browser): prevent DNS rebinding in extension relay HTTP endpoints
by webvijayi · 2026-01-31
76.0%
#19042: Security: add URL allowlist for web_search and web_fetch
by smartprogrammer93 · 2026-02-17
75.7%
#23596: fix(msteams): add SSRF validation to file consent upload URL
by lewiswigmore · 2026-02-22
75.5%