CVE-2026-56227: Capgo SSRF Vulnerability

CVE-2026-56227 Overview

CVE-2026-56227 is a Server-Side Request Forgery (SSRF) vulnerability in Capgo versions before 12.128.2. The flaw resides in the webhook URL validation logic, which fails to block loopback and internal network addresses. Organization administrators can configure webhooks pointing to localhost or 127.0.0.1, and the Capgo backend issues outbound requests to those destinations when the webhook fires. Error responses from these internal requests are disclosed back to users, enabling reconnaissance of internal services. The issue is classified under CWE-918.

Critical Impact
Authenticated organization admins can probe internal-only services through the Capgo backend, leaking information about loopback-bound applications and internal network endpoints.

Affected Products

Capgo versions prior to 12.128.2
Self-hosted Capgo deployments exposing webhook configuration to organization admins
Capgo backend services performing outbound webhook delivery

Discovery Timeline

2026-06-20 - CVE-2026-56227 published to NVD
2026-06-22 - Last updated in NVD database

Technical Details for CVE-2026-56227

Vulnerability Analysis

The vulnerability stems from incomplete URL validation when Capgo accepts webhook destinations from organization administrators. The backend treats any syntactically valid URL as a delivery target, including hostnames and IP literals that resolve to the server itself or to internal network ranges. When a webhook event fires, the Capgo backend issues an HTTP request to the supplied URL using its own network position. Responses, including error messages and status codes, are surfaced to the requesting user. Attackers with admin privileges in a tenant can therefore use Capgo as a proxy to reach 127.0.0.1, localhost, or other RFC1918 endpoints reachable from the application server.

Root Cause

The webhook URL validation routine lacks a deny list for loopback addresses, link-local ranges, and private network blocks. There is no DNS resolution check to detect hostnames that resolve to internal IPs. Error responses from outbound requests are reflected to the user instead of being sanitized, providing an oracle for probing internal services.

Attack Vector

An authenticated user with organization admin privileges configures a webhook with a URL such as http://127.0.0.1:6379/ or http://localhost:8080/admin. When the webhook event triggers, the backend connects to the internal endpoint and returns the resulting error or response data. The attacker iterates across ports and paths to map internal services, identify metadata endpoints, or interact with unauthenticated services bound to localhost. See the GitHub Security Advisory GHSA-48hc-53hv-6x3f and the VulnCheck Advisory on SSRF for additional technical context.

Detection Methods for CVE-2026-56227

Indicators of Compromise

Webhook configurations referencing 127.0.0.1, localhost, 0.0.0.0, ::1, or RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Outbound HTTP requests from the Capgo backend to its own loopback interface
Unexpected webhook delivery error messages returned to admin users that include internal service banners or stack traces
Cloud metadata service requests originating from the Capgo application host

Detection Strategies

Audit the webhooks table or equivalent configuration store for URLs containing loopback hostnames or private IP literals.
Inspect outbound proxy or egress firewall logs for backend-initiated connections to internal addresses correlated with webhook events.
Review application logs for webhook delivery errors that expose response bodies from non-public endpoints.

Monitoring Recommendations

Alert on any webhook creation or update event where the destination resolves to a private, loopback, or link-local address.
Monitor backend egress traffic and flag connections to 169.254.169.254 or other cloud metadata endpoints.
Track changes to organization webhook configurations through admin audit logs.

How to Mitigate CVE-2026-56227

Immediate Actions Required

Upgrade Capgo to version 12.128.2 or later on all self-hosted instances.
Enumerate existing webhook configurations and remove any pointing to loopback, link-local, or internal addresses.
Rotate any secrets that may have been accessible through internal services reachable from the Capgo backend.

Patch Information

The issue is fixed in Capgo 12.128.2. The patch enforces validation that rejects loopback, link-local, and private IP destinations and resolves hostnames before issuing outbound requests. Refer to the GitHub Security Advisory GHSA-48hc-53hv-6x3f for the upstream fix.

Workarounds

Place the Capgo backend behind an egress proxy that blocks connections to loopback and RFC1918 ranges until patching is complete.
Restrict the organization admin role to trusted operators and review webhook creation activity.
Strip response bodies from webhook delivery error messages surfaced to end users.

bash

# Example egress filtering with iptables to block backend SSRF to internal ranges
iptables -A OUTPUT -m owner --uid-owner capgo -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner capgo -d 169.254.0.0/16 -j REJECT
iptables -A OUTPUT -m owner --uid-owner capgo -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner capgo -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner capgo -d 192.168.0.0/16 -j REJECT