CVE-2026-100692 in Hugo
Summary
by MITRE • 09/26/2026
Hugo is a static site generator. In versions after v0.123.0 and before v0.166.0, Hugo's symlink confinement checks stopped at the mount root itself, so a theme or module checked into themes/ (or a vendored module) could contain a symlink at a mount root (for example themes/mytheme/assets -> /some/dir/outside). Files behind such a symlink were readable during a site build through resources.Get, resources.Match and similar functions, and could be published to public/ via static mounts, bypassing the rule that theme and module mount sources must be local paths. Modules fetched via Go modules are not affected because Go module zips cannot contain symlinks, and this is not an escalation for the main project, which may already mount absolute paths by configuration. Fixed in v0.166.0, where symlinked mount roots and symlinked directories between the mount root and the module directory are treated as non-existent for all modules. As a workaround, inspect themes/ and vendored modules for symlinks at mount roots before building, or replace symlinks with explicit mounts.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
Hugo is a widely adopted static site generator that relies on strict file system confinement to ensure security during the build process. In versions released after v0.123.0 and prior to v0.166.0, a critical flaw existed in how Hugo enforced symlink confinement checks for themes and modules. The vulnerability stems from an incomplete validation mechanism where the check stopped at the mount root itself rather than traversing into it. This design oversight allowed malicious or misconfigured themes and vendored modules placed within the themes directory to contain symbolic links located directly at a mount root, such as linking assets directories to paths outside the project scope like /some/dir/outside.
The operational impact of this vulnerability is significant because Hugo provides functions such as resources.Get and resources.Match that are commonly used by theme developers to access and process site assets. Due to the flawed confinement logic, files located behind these symlinks became readable during the build process even though they resided outside the allowed local paths. Furthermore, if static mounts were configured in a way that exposed these accessible files, content from arbitrary directories on the host file system could be published into the public output directory. This effectively bypassed the security rule intended to restrict theme and module mount sources exclusively to local project paths, creating a potential path traversal scenario where sensitive internal data or configuration files not meant for publication could be inadvertently included in the generated site.
This vulnerability is classified under CWE-22 as Improper Limitation of a Pathname to a Restricted Directory because it allows access to resources outside the intended directory structure through symbolic link manipulation. From an offensive security perspective, this behavior aligns with ATT&CK technique T1083 File and Directory Discovery, as it enables enumeration and retrieval of files from arbitrary locations on the file system during the build phase. It is important to note that modules fetched via Go modules are not affected by this issue because the underlying zip format used for Go module distribution does support symbolic links in a way that prevents them from being extracted or utilized in this manner, thereby neutralizing the attack vector for remote dependencies. Additionally, this vulnerability does not constitute an escalation of privilege for the main Hugo project itself since the primary configuration may already permit mounting absolute paths by design; however, it remains a critical security flaw for users relying on third-party themes and modules that assume strict local confinement.
The issue was resolved in version v0.166.0 through a comprehensive update to the symlink handling logic. In this fixed release, Hugo treats any symlinked mount roots as well as any symlinks located between the mount root and the module directory as non-existent for all modules. This change ensures that symbolic links are effectively ignored during path resolution, preventing access to external files regardless of their location relative to the theme or module structure. To mitigate this risk in environments running vulnerable versions before upgrading, administrators should manually inspect the themes/ directory and any vendored modules for symlinks located at mount roots prior to initiating a build process. Alternatively, replacing these symbolic links with explicit configuration mounts that point directly to local paths can eliminate the vulnerability without requiring an immediate software update until maintenance windows allow for version upgrades.