Ech0 CVE-2026-79671

Exploitation requires the attacker to hold admin-level privileges within Ech0 (CVSS PR:H), sufficient to call the webhook creation API (POST /api/webhook). No special non-default configuration is required beyond the webhook feature being enabled, which is part of standard Ech0 functionality. Once the malicious webhook is stored, exploitation recurs automatically on every application event without further attacker interaction. Exploitation is most impactful when Ech0 is deployed in a cloud environment (AWS, Azure, GCP) where the instance metadata service (169.254.169.254) is reachable from the server; in purely on-premises deployments without accessible internal HTTP services, impact is reduced. Limiting factors: admin access is required (not user-level or unauthenticated); the attacker cannot directly read the HTTP response via the webhook creation API - a separate out-of-band channel (attacker-controlled server or SSRF response reflection) is needed to capture exfiltrated data.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:N) scores 5.1 (Medium), and the PR:H metric is the decisive limiting factor - exploitation is confined to users with admin-level access to the Ech0 instance. This substantially reduces real-world risk compared to a network-exploitable unauthenticated SSRF. That said, in cloud-hosted deployments, an admin-level compromise converting to IMDS (Instance Metadata Service) credential theft is a meaningful lateral movement step. Impact metrics (VC:L/VI:L/SC:L/SI:L) are appropriately calibrated: the attacker gains limited read access to internal services and can make limited write-side requests via webhook POST. No EPSS score was provided in the input; given the niche product footprint and PR:H requirement, real-world exploitation probability is expected to be low. Publicly available exploit code (curl PoC in the GHSA advisory) exists, but no CISA KEV listing confirms active exploitation. There is no conflict between stated signals. The primary realistic threat actor is a malicious or compromised admin in a cloud environment.

An admin-level user authenticates to Ech0 and issues a POST /api/webhook request with a URL such as http://169.254.169.254.nip.io/latest/meta-data/iam/security-credentials/. The validateWebhookURL function passes the hostname through net.ParseIP(), receives nil, skips all private-IP checks, and stores the webhook as active. A publicly available curl-based PoC demonstrates this flow. On each subsequent application echo event, the Dispatcher fires the stored webhook, causing the Ech0 server to DNS-resolve the nip.io hostname to 169.254.169.254 and POST to the cloud metadata endpoint, returning temporary IAM credentials or instance identity data to the attacker.