EUVD-2026-41916
GHSA-vxgm-5rmg-5w8g
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-exploitable via build-time HTTP; AC:H because attacker must control an allow-listed host or its DNS; scope change to internal hosts drives C:H with no integrity or availability impact.
Primary rating from Vendor (https://github.com/gohugoio/hugo).
CVSS VectorVendor: https://github.com/gohugoio/hugo
Lifecycle Timeline
3DescriptionCVE.org
Commit: 86fbb0f7a8 - _security: Validate redirects against security.http.urls_ Affected versions: v0.91.0 (when security.http.urls was introduced) through v0.161.1. Fixed in: v0.162.0. Severity: Only relevant for sites that rely on security.http.urls as a trust boundary - e.g. CI builds that fetch remote resources but want to constrain which hosts can be reached. Not an issue if you fully trust every URL passed to resources.GetRemote.
Description. resources.GetRemote enforces security.http.urls on the URL it is called with, but until v0.162.0 it did not re-validate intermediate URLs on HTTP 3xx redirects. An allowed server (or an attacker controlling its DNS or response) could therefore redirect the request to a host that the policy was meant to forbid - for example, http://localhost/ or an internal IP - and Hugo would fetch from the redirected target. The same bypass also lifted any host-shape restriction the operator had put in place.
Mitigation. v0.162.0 installs a CheckRedirect on the HTTP client used by resources.GetRemote that re-runs security.http.urls on every redirect target and caps the redirect chain at 10 hops. No configuration change is required.
AnalysisAI
HTTP redirect validation bypass in Hugo v0.91.0-v0.161.1 allows the resources.GetRemote build-time HTTP client to follow 3xx redirects to hosts explicitly forbidden by the security.http.urls allow-list, enabling server-side request forgery (SSRF) against internal network targets. Build pipelines that rely on security.http.urls as a trust boundary - for example, CI systems that fetch from semi-trusted external hosts while restricting access to internal metadata services or private IP ranges - are the primary risk population. No public exploit has been identified at time of analysis, and exploitation requires an attacker to control or manipulate an already-permitted external host.
Technical ContextAI
Hugo is a Go-based static site generator (pkg:go/github.com/gohugoio/hugo). The resources.GetRemote function issues build-time HTTP requests using Go's standard net/http client. Since v0.91.0, Hugo exposes a security.http.urls configuration key - a regex allow-list in hugo.toml - to constrain which remote hosts resources.GetRemote may contact; this is especially useful in CI/CD pipelines fetching third-party assets. The root cause (CWE-918: Server-Side Request Forgery) is that the original implementation validated only the *initial* request URL against the allow-list. No CheckRedirect hook was installed on the HTTP client, so any HTTP 3xx response issued by an allowed host could silently redirect the client to a denied target (e.g., http://localhost/, http://169.254.169.254/) without triggering a policy check. The fix in commit 86fbb0f7a8bbb93e2e916390de9e5a4f24bf9f50 installs a CheckRedirect callback that re-invokes CheckAllowedHTTPURL on every intermediate redirect URL and enforces a hard cap of 10 redirect hops.
RemediationAI
Upgrade Hugo to v0.162.0 or later, which installs a CheckRedirect hook on the resources.GetRemote HTTP client that re-validates every redirect target URL against security.http.urls and caps redirect chains at 10 hops. No configuration change is required alongside the upgrade. The release is available at https://github.com/gohugoio/hugo/releases/tag/v0.162.0 and the fix commit is 86fbb0f7a8bbb93e2e916390de9e5a4f24bf9f50. If an immediate upgrade is not feasible, a compensating control is to configure the Hugo HTTP client to disable redirect following at the network perimeter (e.g., via a forward proxy that blocks 3xx pass-through to internal RFC-1918 or link-local ranges); note this may break legitimate redirect-dependent resources and requires proxy infrastructure. Alternatively, auditing every URL passed to resources.GetRemote in templates and confirming none resolve to externally controlled hosts reduces the attack surface, but does not eliminate the underlying bypass.
Same weakness CWE-918 – Server-Side Request Forgery (SSRF)
View allVendor StatusVendor
SUSE
Severity: ModerateShare
External POC / Exploit Code
Leaving vuln.today