CVE-2026-47267: Gogs Git Service SSRF Vulnerability

CVE-2026-47267 Overview

CVE-2026-47267 is a Server-Side Request Forgery (SSRF) vulnerability in Gogs, an open source self-hosted Git service. The flaw exists in versions prior to 0.14.3. The original fix for CVE-2022-1285 blocked webhook URLs whose hostnames resolved to addresses inside the configured localCIDRs. However, the webhook delivery code still followed HTTP redirects, allowing attackers to bypass this control and reach hosts inside restricted CIDR ranges. The issue is tracked under CWE-918: Server-Side Request Forgery and is fixed in Gogs 0.14.3.

Critical Impact
Authenticated users can configure webhooks that redirect to internal network resources, exposing metadata services, internal APIs, and other assets behind the Gogs server.

Affected Products

Gogs versions prior to 0.14.3
Self-hosted Gogs Git service deployments
Gogs instances relying on localCIDRs for webhook URL restrictions

Discovery Timeline

2026-06-24 - CVE-2026-47267 published to NVD
2026-06-25 - Last updated in NVD database

Technical Details for CVE-2026-47267

Vulnerability Analysis

Gogs allows repository administrators to register webhooks that deliver event payloads to arbitrary HTTP endpoints. After CVE-2022-1285, Gogs validated webhook URLs and rejected hostnames that resolved into configured localCIDRs, blocking direct SSRF to internal addresses. The follow-up fix did not extend that validation to HTTP redirects returned by the destination server. When the webhook client received a 3xx response, the underlying HTTP transport in internal/httplib/httplib.go automatically followed the Location header without re-checking the target against localCIDRs. Attackers control an external endpoint that returns a redirect to http://127.0.0.1, http://169.254.169.254, or another internal address, and the Gogs server then issues the follow-up request from inside the trust boundary.

Root Cause

The root cause is incomplete SSRF mitigation. URL validation occurred only on the user-supplied webhook target, not on subsequent redirect destinations resolved by Go's net/http client. Default http.Client behavior follows up to ten redirects unless CheckRedirect is set, so the second-hop request bypassed the localCIDRs filter entirely.

Attack Vector

An authenticated user with permission to create webhooks on a repository registers a webhook pointing to an attacker-controlled external host. When a repository event triggers delivery, the attacker's server replies with an HTTP redirect to an internal target. The Gogs server follows the redirect and issues the webhook payload to the internal address, returning timing and partial response information observable through webhook delivery logs.

// Patch excerpt: internal/httplib/httplib.go
// security: don't follow redirects on webhook delivery (#8263)
var (
	defaultSetting = Settings{
		UserAgent:        "GogsServer",
		ConnectTimeout:   60 * time.Second,
		ReadWriteTimeout: 60 * time.Second,
	}
	defaultCookieJar http.CookieJar
	settingMutex     sync.Mutex
)

Source: Gogs commit 199cf4f

The patch restructures the default HTTP settings and adds an explicit net/http import in internal/database/webhook.go so the webhook delivery path can install a CheckRedirect policy that blocks automatic redirect following.

Detection Methods for CVE-2026-47267

Indicators of Compromise

Webhook delivery records in Gogs targeting external hosts that return 301, 302, 303, 307, or 308 responses.
Outbound HTTP requests from the Gogs server process to RFC1918 addresses, loopback, or cloud metadata IPs such as 169.254.169.254.
Webhook configurations created shortly before unusual internal HTTP traffic from the Gogs host.

Detection Strategies

Review the webhook and hook_task tables for delivery URLs whose final response status or response body indicates redirection to internal endpoints.
Inspect Gogs logs and reverse proxy logs for webhook user-agent GogsServer issuing requests to unexpected destinations.
Run network egress monitoring on the Gogs host and flag connections to internal subnets, link-local ranges, and cloud metadata services.

Monitoring Recommendations

Enable verbose webhook delivery logging and forward records to a centralized log store for correlation with network telemetry.
Audit the list of users with permission to create or edit repository webhooks and alert on bulk webhook creation events.
Baseline outbound traffic from the Gogs server and alert on deviations toward localCIDRs defined in the Gogs configuration.

How to Mitigate CVE-2026-47267

Immediate Actions Required

Upgrade Gogs to version 0.14.3 or later, which disables redirect following during webhook delivery.
Audit existing webhooks and remove any pointing to untrusted or unknown external endpoints.
Restrict who can create webhooks by reviewing repository and organization permissions.

Patch Information

The fix is committed in Gogs commit 199cf4f and discussed in pull request #8263. Details are documented in GitHub Security Advisory GHSA-c4v7-xg93-qf8g. The patch modifies internal/database/webhook.go and internal/httplib/httplib.go to install an HTTP client that does not follow redirects when delivering webhook events.

Workarounds

Place the Gogs server in a network segment with an egress firewall that denies traffic to all internal CIDRs, loopback, and cloud metadata addresses.
Force webhook traffic through an outbound HTTP proxy that performs URL allow-listing and rejects redirects to private address space.
Disable webhook creation for untrusted users until the upgrade to 0.14.3 is deployed.

bash

# Example egress firewall rules blocking SSRF targets from the Gogs host
iptables -A OUTPUT -m owner --uid-owner gogs -d 127.0.0.0/8     -j REJECT
iptables -A OUTPUT -m owner --uid-owner gogs -d 10.0.0.0/8      -j REJECT
iptables -A OUTPUT -m owner --uid-owner gogs -d 172.16.0.0/12   -j REJECT
iptables -A OUTPUT -m owner --uid-owner gogs -d 192.168.0.0/16  -j REJECT
iptables -A OUTPUT -m owner --uid-owner gogs -d 169.254.0.0/16  -j REJECT