Bug 2497450 (CVE-2026-58404)

Summary: CVE-2026-58404 github.com/gohugoio/hugo: Hugo: Server-Side Request Forgery (SSRF) via alternate IPv4 encodings
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedKeywords: Security
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in Hugo, a static site generator. The default security policy intended to deny requests to loopback, internal, and cloud-metadata IPv4 addresses could be bypassed. This occurred because the deny rule only matched dotted-decimal notation, allowing alternate IPv4 encodings (integer, hex, or octal) to pass the policy. When a template processes an untrusted URL, this vulnerability could lead to Server-Side Request Forgery (SSRF), enabling access to internal services or cloud-metadata endpoints during the build process.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-07-06 20:01:41 UTC 
Hugo is a static site generator. From v0.162.0 through v0.163.0, the default security.http.urls policy denies requests to loopback, internal, and cloud-metadata IPv4 literals, but the deny rule only matched dotted-decimal notation, so alternate IPv4 encodings of the same addresses, including integer, hex, or octal, passed the policy. When a template passes an untrusted or data-derived URL to resources.GetRemote and the host platform uses the cgo system resolver, these encodings resolve to the blocked address, allowing build-time server-side requests to loopback and internal services, including the cloud-metadata endpoint in hosted or CI builds; the same check is reused on redirects, so the gap also applies to each redirect hop. This issue is fixed in v0.163.1.