CVE-2026-89258: Hugo before v0.165.0 Symlink Confinement Bypass via resources.Get
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Hugoto a version that resolves this vulnerability.Fixed in v0.165.0 - Compensating control
If upgrading is not immediately possible, avoid using symlinks inside mounted directories (e.g., vendored themes under themes/) that could be followed by direct resource lookups such as resources.Get or os.ReadFile.
Event History
Frequently Asked Questions
Which Hugo deployments are realistically exposed?
Deployments using Hugo after v0.123.0 and before v0.165.0 are exposed if they perform direct resource lookups against a mounted directory that contains an attacker-controlled or author-placed symlink. Locally vendored themes under themes/ are an example of an affected location.
What must an attacker be able to do to exploit this issue?
The attacker must be able to place a symlink in a mounted directory, or persuade a site author to place one there. A direct lookup function such as resources.Get or os.ReadFile must then follow that symlink during the build.
Are themes obtained as Go modules from GitHub affected?
No. Symlinks are stripped when Go module themes are downloaded from GitHub, so those themes are not affected by this issue.
What functionality is affected and what is not?
Direct resource lookups, including resources.Get and os.ReadFile, can follow symlinks outside the intended project boundary. Multi-directory walks, such as content or asset walking, are not affected.
What should teams do if they cannot immediately upgrade?
Review mounted directories, especially locally vendored themes, for symlinks and remove or avoid symlinks that resolve outside the project boundary. Upgrade to Hugo v0.165.0 when possible.