Description

Hugo is a static site generator. From v0.161.0, Hugo executes Node tools under Node's permission model, but TailwindCSS — included in the default security.exec.allow list — requires a highly permissive configuration (--allow-addons, --allow-child-process, --allow-worker). As a result, the restrictions intended by the fix for GHSA-x597-9fr4-5857 could still be bypassed, allowing a Node tool invoked during a build to read and write files outside the project's working directory. Affected versions are those after v0.43; the issue was fixed in v0.165.0 by removing tailwindcss from the default security.exec.allow list. Users who do not use TailwindCSS, or who only build trusted sites, are not affected. As a workaround, users can define a restrictive security.exec.allow list in hugo.toml.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-11T12:16:56.480Z",
  "pubdate": "2026-09-11T12:16:56.480Z",
  "executiveSummary": "This vulnerability involves a security sandbox bypass in Hugo (v0.161.0 through v0.164.0) related to the Node.js permission model integration.\nThe issue stems from the inclusion of TailwindCSS in the default 'security.exec.allow' list, which necessitates highly permissive flags ('--allow-addons', '--allow-child-process', and '--allow-worker') that effectively negate the intended security constraints.\nAn attacker capable of influencing the Hugo build process—or who can introduce a malicious dependency into the project's build toolchain—can leverage this configuration to escape the intended execution sandbox.\nSuccessful exploitation allows unauthorized file system access, enabling arbitrary file read and write operations outside the designated project working directory.\nThis vulnerability impacts users relying on Hugo’s default security configurations for build isolation.\nThe risk is high for environments processing untrusted site configurations, as the execution of Node-based build tools is performed with elevated privileges relative to the site's project folder.\nThe vulnerability was addressed in v0.165.0 by removing TailwindCSS from the default allow list, enforcing stricter isolation.",
  "technicalDetails": "The root cause of this vulnerability lies in the conflict between Hugo’s security architecture and the functional requirements of TailwindCSS. Following the implementation of the Node.js permission model introduced in v0.161.0, Hugo intended to restrict the filesystem and process-level capabilities of external build tools. However, the default security policy included TailwindCSS in the 'security.exec.allow' list.\nTailwindCSS, when invoked as a build dependency, requires specific Node.js security flags to function correctly, specifically '--allow-addons', '--allow-child-process', and '--allow-worker'. These flags are inherently broad; they authorize the Node runtime to load native add-ons, spawn arbitrary child processes, and utilize worker threads, effectively bypassing the granular filesystem and process restrictions imposed by the sandbox intended by the fix for GHSA-x597-9fr4-5857.\nThe attack flow begins when Hugo triggers a build process that invokes TailwindCSS. Because the tool is pre-approved in the 'security.exec.allow' list, Hugo executes it with the aforementioned permissive flags. A malicious actor can compromise the project's build toolchain or provide a malicious 'tailwind.config.js' file within a site repository. Once the build process commences, the malicious code runs with the permissions granted to the Node.js runtime.\nBecause the runtime is not restricted to the project root due to the broad nature of the '--allow-addons' and '--allow-child-process' flags, the process can perform directory traversal or manipulate files elsewhere on the host system. This bypasses the logic designed to sequester builds into isolated environments.\nThe vulnerability affects Hugo versions after v0.43, specifically those utilizing the new Node.js permission model introduced in v0.161.0, and persists until the remediation in v0.165.0. No authentication or elevated user privileges are required on the host system; the vulnerability is triggered by the build execution itself, making it particularly dangerous in CI/CD environments where builds of untrusted or third-party Hugo themes are processed.\nPost-exploitation, an attacker can access sensitive configuration files, environment variables, or other project artifacts stored on the build server, potentially leading to full compromise of the build environment or the leakage of sensitive credentials utilized during the static site generation process."
}