CVE-2026-89259 in Hugo
Summary
by MITRE • 09/11/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/11/2026
Hugo is a widely adopted static site generator that allows developers to create websites using various tools and plugins during the build process. A significant security vulnerability was identified regarding how Hugo handles external tool execution, specifically concerning Node.js-based utilities like TailwindCSS. The core issue stems from an incomplete remediation of a previous privilege escalation flaw tracked as GHSA-x597-9fr4-5857. While earlier versions attempted to restrict the permissions under which these tools operate, the implementation introduced in version 0.161.0 inadvertently created a bypass vector by including TailwindCSS in the default security.exec.allow list with overly permissive Node.js flags. This configuration allows any Node tool invoked during a build to access resources beyond the intended project scope, effectively neutralizing the sandboxing measures designed to contain potential malicious activity within the build environment.
The technical flaw lies in the specific command-line arguments passed when executing TailwindCSS via Node.js. To function correctly, TailwindCSS requires flags such as --allow-addons, --allow-child-process, and --allow-worker. These flags grant the process elevated privileges that include the ability to spawn child processes, load native addons, and utilize web workers. When combined with Hugo's execution model, these permissions allow a compromised or malicious Node tool to read files outside the project's working directory and write data to arbitrary locations on the file system. This behavior directly contradicts the principle of least privilege and undermines the security boundaries established by Hugo’s sandboxing mechanisms. The vulnerability affects all versions of Hugo released after v0.43 up until the fix in v0.165.0, as these versions inherit or retain configurations that permit this level of access for TailwindCSS users.
From an operational impact perspective, this vulnerability poses a severe risk to developers and organizations using Hugo with TailwindCSS. An attacker who can inject malicious code into a project’s build pipeline could exploit this flaw to exfiltrate sensitive data stored outside the immediate project folder, such as configuration files from parent directories or other system resources. Furthermore, the ability to write arbitrary files enables persistence mechanisms or further lateral movement within the host environment if Hugo is run with elevated privileges on the underlying operating system. This scenario aligns with CWE-250, which describes execution with unnecessary privileges, and maps closely to ATT&CK techniques involving command and script interpretation as well as file and directory information discovery. The risk is particularly acute in continuous integration or deployment pipelines where build artifacts are automatically processed without manual oversight of every dependency update.
Mitigation strategies focus on restricting the scope of executable tools allowed by Hugo. For users who do not utilize TailwindCSS, the vulnerability does not apply, provided they maintain a restrictive security.exec.allow list that excludes other potentially dangerous Node-based utilities. However, for those requiring TailwindCSS functionality, the recommended approach is to explicitly define a custom security.exec.allow configuration in the hugo.toml file. By removing tailwindcss from this default allowlist and instead relying on explicit whitisting of only necessary tools with minimal required permissions, administrators can restore effective sandboxing. Alternatively, upgrading to Hugo v0.165.0 or later resolves the issue by permanently excluding TailwindCSS from the default allowed list, forcing users who need it to configure it manually under stricter constraints. This ensures that any external tool execution remains confined within the intended security boundaries of the build environment.