Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
MEDIUM severity

GHSA-r2x7-427f-rq69 ech0

MEDIUM

GHSA-r2x7-427f-rq69 is a medium-severity (CVSS 5.5) 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 has SSRF via DNS Resolution Bypass in Webhook URL Validation

Also known asCVE-2026-79671GO-2026-5603
Published
Apr 10, 2026
Updated
Aug 27, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Sep 17, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

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 GHSA-r2x7-427f-rq69.

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs16th percentile — riskier than 16% of all scored CVEsHighest risk

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

How urgent is this, really

GHSA-r2x7-427f-rq69 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.

Where this sits among everything scored

Of 377,166 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.

Real-World Exposure

1 pkg affected
🐹github.com/lin-snow/ech0

Real-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 validateWebhookURL function in webhook_setting_service.go attempts to block webhooks targeting private/internal IP addresses, but only checks literal IP strings via net.ParseIP(). Hostnames that DNS-resolve to private IPs (e.g., 169.254.169.254.nip.io, 10.0.0.1.nip.io) bypass all checks, allowing an admin to create webhooks that make server-side requests to internal network services and cloud metadata endpoints.

Details

The vulnerability is in validateWebhookURL (internal/service/setting/webhook_setting_service.go:180-199):

func validateWebhookURL(rawURL string) error {
    parsed, err := url.Parse(rawURL)
    // ...
    host := strings.ToLower(parsed.Hostname())
    if host == "" || host == "localhost" || strings.HasSuffix(host, ".local") {
        return errors.New(commonModel.INVALID_WEBHOOK_URL)
    }
    if ip := net.ParseIP(host); ip != nil {  // <-- returns nil for hostnames
        if ip.IsLoopback() || ip.IsPrivate() || ip.IsLinkLocalMulticast() ||
            ip.IsLinkLocalUnicast() || ip.IsUnspecified() {
            return errors.New(commonModel.INVALID_WEBHOOK_URL)
        }
    }
    return nil  // hostname passes all checks unchecked
}

net.ParseIP("169.254.169.254.nip.io") returns nil because it is not a literal IP address. The entire private IP check block is skipped, and the function returns nil (valid).

Both HTTP clients that execute webhook requests use standard http.Client / http.Transport with no custom DialContext to verify resolved IPs:

  • TestWebhook (webhook_setting_service.go:169): &http.Client{Timeout: 5 * time.Second}
  • Dispatcher (dispatcher.go:51-58): &http.Client{...Transport: &http.Transport{...}} — no custom dialer

The Dispatcher.HandleObservation (dispatcher.go:67-81) iterates all active webhooks and dispatches without re-validating URLs, so a stored malicious webhook triggers SSRF on every application event.

Execution flow:

  1. Admin calls POST /api/webhook with URL http://169.254.169.254.nip.io/latest/meta-data/
  2. CreateWebhookvalidateWebhookURLnet.ParseIP returns nil → passes validation
  3. Webhook stored in database with is_active: true
  4. On any echo event → Dispatcher.HandleObservationDispatchSendWithRetry → DNS resolves 169.254.169.254.nip.io to 169.254.169.254 → POST to cloud metadata endpoint

PoC

# Step 1: Create a webhook targeting cloud metadata via DNS rebinding
curl -X POST http://localhost:8080/api/webhook \
  -H 'Authorization: Bearer <admin-jwt>' \
  -H 'Content-Type: application/json' \
  -d '{"name":"ssrf-probe","url":"http://169.254.169.254.nip.io/latest/meta-data/","secret":"","is_active":true}'

# Step 2: Trigger SSRF via test endpoint
curl -X POST http://localhost:8080/api/webhook/<webhook-id>/test \
  -H 'Authorization: Bearer <admin-jwt>'

# The server makes an HTTP POST to 169.254.169.254 (AWS metadata).
# net.ParseIP("169.254.169.254.nip.io") returns nil, skipping all IP checks.
# Delivery status and error messages reveal connectivity information.

# For internal network scanning:
# http://10.0.0.1.nip.io:8080/
# http://127.0.0.1.nip.io:6379/

# With is_active:true, every application event automatically dispatches
# to the SSRF target via Dispatcher.HandleObservation (no re-validation).

Impact

  • Cloud metadata access: An admin can reach cloud instance metadata endpoints (AWS 169.254.169.254, GCP, Azure) to steal IAM credentials, instance identity tokens, and configuration data.
  • Internal network probing: Webhooks can scan internal services by observing delivery status (success/failed) and error messages, mapping internal network topology.
  • Persistent SSRF: Active webhooks fire on every application event via the Dispatcher, creating ongoing SSRF without further admin interaction.
  • Scope escalation: Impact escapes the application's security boundary to affect internal infrastructure, despite the application explicitly attempting to prevent this.

Recommended Fix

Replace the hostname-only check with a custom net.Dialer that resolves DNS and validates the resolved IP before connecting. Apply this to both HTTP clients:

import "net"

func safeDialContext(ctx context.Context, network, addr string) (net.Conn, error) {
    host, port, err := net.SplitHostPort(addr)
    if err != nil {
        return nil, err
    }
    ips, err := net.DefaultResolver.LookupIPAddr(ctx, host)
    if err != nil {
        return nil, err
    }
    for _, ip := range ips {
        if ip.IP.IsLoopback() || ip.IP.IsPrivate() || ip.IP.IsLinkLocalUnicast() ||
            ip.IP.IsLinkLocalMulticast() || ip.IP.IsUnspecified() {
            return nil, fmt.Errorf("resolved IP %s is not allowed", ip.IP)
        }
    }
    dialer := &net.Dialer{Timeout: 5 * time.Second}
    return dialer.DialContext(ctx, network, addr)
}

// Use in both TestWebhook and Dispatcher:
client := &http.Client{
    Timeout: 5 * time.Second,
    Transport: &http.Transport{
        DialContext: safeDialContext,
    },
}

This ensures resolved IPs are checked against the private range blocklist regardless of hostname used.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/lin-snow/ech0all versions4.4.3go get github.com/lin-snow/ech0@v4.4.3

Detection & mitigation playbook

Open-source dependency
  1. Detect

    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.

  2. Fix

    Update github.com/lin-snow/ech0 to 4.4.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-r2x7-427f-rq69 is resolved across your whole dependency graph.

  3. 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.

  4. How O3 protects you

    O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-r2x7-427f-rq69 can be triaged on real exposure rather than presence alone.

Tailored to GHSA-r2x7-427f-rq69. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## Summary The `validateWebhookURL` function in `webhook_setting_service.go` attempts to block webhooks targeting private/internal IP addresses, but only checks literal IP strings via `net.ParseIP()`. Hostnames that DNS-resolve to private IPs (e.g., `169.254.169.254.nip.io`, `10.0.0.1.nip.io`) bypass all checks, allowing an admin to create webhooks that make server-side requests to internal network services and cloud metadata endpoints. ## Details The vulnerability is in `validateWebhookURL` (`internal/service/setting/webhook_setting_service.go:180-199`): ```go func validateWebhookURL(rawU
O3 Security · Impact-Aware SCA

Is GHSA-r2x7-427f-rq69 in your dependencies?

O3 Security finds GHSA-r2x7-427f-rq69 across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.

GHSA-r2x7-427f-rq69: ech0 (Medium 5.5) | O3 Security