Ech0 Server-Side Request Forgery (SSRF) Vulnerability
Ech0 is vulnerable to Server-Side Request Forgery (SSRF) via the `fetchPeerConnectInfo` function, which uses `httpUtil.SendRequest` without SSRF protection, allowing authenticated users to make the server request arbitrary URLs, including internal/cloud metadata endpoints.
Ech0, a service developed by lin-snow, is susceptible to a Server-Side Request Forgery (SSRF) vulnerability. The vulnerability lies in the fetchPeerConnectInfo function (internal/service/connect/connect.go) where httpUtil.SendRequest is used instead of SendSafeRequest. This oversight allows authenticated users to craft connections to internal or external services, leading to unauthorized information disclosure. Specifically, attackers can target internal services, cloud metadata endpoints like AWS IMDSv1 (169.254.169.254), GCE metadata, and the Kubernetes API (kubernetes.default.svc.cluster.local). The affected version is any version of ech0 prior to commit 1.4.8-0.20260503040602-091d26d2d942. This vulnerability was reported on May 7, 2026.
Attack Chain
- The attacker authenticates to the Ech0 service.
- The attacker crafts a malicious POST request to
/api/connectsto add a new connection. - In the POST request, the
connect_urlfield is set to a URL pointing to an internal resource, such ashttp://169.254.169.254/latest/meta-data/instance-id(AWS metadata service) orhttp://kubernetes.default.svc.cluster.local:443/api(Kubernetes API). - The Ech0 server receives the POST request and stores the malicious
connect_url. - The attacker triggers a health check on the newly created connection via a request to
/api/connects/health. - The
fetchPeerConnectInfofunction is called with the attacker-controlled URL. httpUtil.SendRequestmakes an HTTP request to the specified internal resource without proper validation.- The response from the internal resource is returned to the attacker, potentially revealing sensitive information.
Impact
Successful exploitation of this SSRF vulnerability allows an attacker to access sensitive internal resources that are normally protected. This includes cloud metadata, such as AWS EC2 instance IDs, IAM roles, and other configuration details. Access to the Kubernetes API could allow for further lateral movement and privilege escalation within the Kubernetes cluster. The number of potential victims is dependent on the deployment scale and network architecture of Ech0 instances, but all authenticated users could potentially trigger the vulnerability.
Recommendation
- Apply the patch or upgrade to a version of Ech0 that includes the fix for this vulnerability (
>= 1.4.8-0.20260503040602-091d26d2d942). - Deploy the Sigma rule
Detect Ech0 SSRF via Connection to Metadata Endpointto identify attempts to exploit this vulnerability by detecting connections to common cloud metadata endpoints. - Monitor network connections for outbound traffic originating from the Ech0 server to internal IP addresses or domains, specifically
169.254.169.254andkubernetes.default.svc.cluster.local, as listed in the IOCs table.
Detection coverage 2
Detect Ech0 SSRF via Connection to Metadata Endpoint
highDetects SSRF attempts in Ech0 by monitoring connections to cloud metadata endpoints.
Detect Ech0 SSRF via Connection to Kubernetes API
highDetects SSRF attempts in Ech0 by monitoring connections to Kubernetes API.
Detection queries are available on the platform. Get full rules →
Indicators of compromise
1
domain
1
ip
| Type | Value |
|---|---|
| ip | 169.254.169.254 |
| domain | kubernetes.default.svc.cluster.local |