Description

Hugo is a static site generator. In versions after v0.123.0 and before v0.165.0, symlinks in parent directories were not dropped during direct resource lookups, allowing path confinement to be bypassed. An attacker who can place — or who convinces a site author to place — a symlink inside a mounted directory (for example, in a locally vendored theme under themes/) can cause functions that perform direct lookups, such as resources.Get and os.ReadFile, to follow that symlink and read files outside the intended project boundaries, disclosing their contents in the built site. Themes mounted as Go modules fetched from GitHub have symlinks stripped on download and are not affected, and multi-directory walks (e.g. content/asset walking) are not affected. This issue is an incomplete-fix follow-up to GHSA-c3wq-j5vh-68rc and GHSA-fw87-fv5r-9fpw; it is fixed in v0.165.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.3",
  "pubDate": "2026-09-11T12:16:56.310Z",
  "pubdate": "2026-09-11T12:16:56.310Z",
  "executiveSummary": "This vulnerability is a path traversal flaw in the Hugo static site generator, specifically involving improper handling of symbolic links during direct resource lookups. The issue exists in versions v0.123.1 through v0.164.x, where the system fails to adequately confine file access to project boundaries.\nBy leveraging symlinks placed within mounted directories, such as a locally vendored 'themes/' directory, an attacker can coerce Hugo's resource-handling functions—specifically 'resources.Get' and 'os.ReadFile'—to traverse outside the intended project root. This allows for the unauthorized disclosure of sensitive files present on the host system during the static site build process, which are subsequently embedded into the generated site output.\nThe vulnerability represents an incomplete fix for previous security patches (GHSA-c3wq-j5vh-68rc and GHSA-fw87-fv5r-9fpw). The risk is significant for users who rely on untrusted themes or external contributions. Exploitation requires an attacker to successfully introduce a crafted symlink into a directory that Hugo processes. Note that files fetched via Go modules are exempt due to symlink stripping during download, and multi-directory walks are unaffected. The flaw is addressed in Hugo version v0.165.0.",
  "technicalDetails": "The vulnerability stems from insufficient path validation within Hugo's file system abstraction layer when performing direct resource lookups. While Hugo is designed to operate within a sandboxed project environment, the logic governing direct lookups—specifically via functions like 'resources.Get' and 'os.ReadFile'—fails to recursively resolve and validate symlinks located in parent directories against the project root boundary.\nIn affected versions (v0.123.0 < version < v0.165.0), the build engine performs file operations without explicitly enforcing a check to ensure that the resolved path of a symlink remains within the project's working directory. If a site author or contributor adds a symbolic link to a directory that is mounted within the project (such as a directory inside 'themes/'), Hugo's resource resolver follows this pointer during the build process.\nThe attack flow proceeds as follows: 1) An attacker introduces a malicious symlink into a project directory (e.g., 'themes/victim-theme/static/link-to-etc-passwd'). 2) The attacker triggers a build process, perhaps by submitting a pull request or convincing a developer to use the compromised theme. 3) Hugo's resource-loading mechanisms, when encountering the symlink, resolve the path to the target file on the host's filesystem (e.g., '/etc/passwd'). 4) Because the check is performed on the symlink path rather than the resolved absolute path, the system deems the file valid for inclusion. 5) Hugo reads the contents of the target file and embeds the sensitive data into the static build artifacts. 6) The sensitive information is then published, leading to unauthorized information disclosure.\nThis vulnerability is constrained to direct lookups; standard file walking mechanisms used for content and asset generation include robust path containment that prevents this behavior. The distinction is critical: only explicit lookups are susceptible. Because the vulnerability is scoped to the build-time environment, authentication requirements are limited to the access necessary to modify the source repository or the local theme files. No network exposure is required for the exploit to execute; the disclosure occurs at the moment the build succeeds. The fix in v0.165.0 enforces mandatory symlink resolution and validation against the expected root directory, ensuring that any resolved path falling outside the project boundaries is explicitly blocked."
}