Description

Hugo versions from v0.161.0 through v0.165.0 run Node.js tools (css.PostCSS, css.TailwindCSS, js.Babel) under the Node.js permission model to restrict file system reads to the project directory and configured mounts. Because the Node.js permission model validates only the lexical path and follows symbolic links that point outside the allowed set, Hugo did not detect symlinks escaping the sandbox. An attacker who can contribute content to a Hugo project (for example via a pull request) can commit a symlink such as assets/css/x.css -> /etc/passwd together with a PostCSS plugin that reads it, allowing any file readable by the Hugo build process to be disclosed and potentially embedded in the published site. This affects builds using the default security configuration; projects that do not invoke Node.js tools are unaffected. Fixed in v0.166.0, which scans allowed paths and fails the build when a symbolic link resolves outside them.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-26T14:16:53.560Z",
  "pubdate": "2026-09-26T14:16:53.560Z",
  "executiveSummary": "A path traversal vulnerability exists in Hugo versions v0.161.0 through v0.165.0, specifically affecting the integration with Node.js-based build tools including css.PostCSS, css.TailwindCSS, and js.Babel.\nThe vulnerability arises from an insecure implementation of the Node.js permission model, which relies on lexical path validation rather than resolution-based validation.\nBecause the sandbox fails to account for symbolic links, an attacker with the ability to contribute content to a Hugo project can bypass file system restrictions.\nBy crafting a malicious symlink that resolves to a restricted location outside the project directory, an attacker can trick the build process into reading sensitive files.\nThe impact includes unauthorized disclosure of arbitrary files accessible to the build process, which may be subsequently embedded into the generated site output.\nThis vulnerability is critical for environments where Hugo builds are triggered by untrusted contributions, such as public pull requests, as it allows for potential exfiltration of sensitive configuration files, environment variables, or system credentials.\nThe issue is resolved in version v0.166.0 by implementing mandatory path resolution checks that invalidate builds containing symlinks escaping defined security boundaries.",
  "technicalDetails": "The vulnerability is rooted in the reliance on lexical path validation within the Hugo-to-Node.js integration layer. When Hugo executes external Node.js tools such as css.PostCSS, css.TailwindCSS, or js.Babel, it attempts to enforce a sandbox using the Node.js permission model. This mechanism is designed to restrict file system access to the project root and explicitly configured mount points.\nThe failure occurs because the validation logic only checks the lexical path of requested files, failing to resolve the real path or inspect the target of symbolic links. When a build process encounters a symlink, it follows the reference without verifying if the underlying destination exists within the allowed scope. This allows a 'path traversal via symlink' attack vector.\nAn attacker can exploit this by committing a symbolic link to the project repository, such as 'assets/css/x.css' pointing to '/etc/passwd'. When the PostCSS plugin processes this directory, it invokes the Node.js build tools. Because the tool trusts the symlink path, it accesses the linked resource (e.g., /etc/passwd) as if it were a legitimate project asset. The build process then reads the content of the target file and incorporates it into the generated site assets.\nThe attack flow follows these steps: 1) The attacker injects a malicious symlink into a directory monitored by Hugo's build system. 2) The attacker includes a PostCSS or similar plugin call in the project configuration that triggers the reading of that symlink. 3) The Hugo build engine invokes the Node.js tool under the weakened permission model. 4) The Node.js tool resolves the symlink, traversing outside the sandbox to the target file. 5) The build tool consumes the unauthorized file content. 6) The sensitive content is rendered into the static site output, potentially exposing it to public access or the build logs.\nThis vulnerability affects versions v0.161.0 through v0.165.0. It requires no specific authentication beyond the ability to contribute code (source control access) and does not rely on network exposure, as the exploitation occurs locally during the site generation process. The root cause is addressed in v0.166.0 by adding a validation layer that resolves all symbolic links to their absolute paths before permitting file access."
}