CVE-2026-75926 in Hugo
Summary
by MITRE • 08/18/2026
Hugo 0.161.0 placed the Node asset pipelines behind the Node.js permission model so that code running through PostCSS, Babel, or TailwindCSS could not reach the file system outside the project directory. Hugo 0.162.0 added tailwindcss to the AllowChildProcess default in config/security/securityConfig.go, which makes nodePermissionArgs in common/hexec/exec.go append --allow-child-process whenever the tool being launched is named tailwindcss. TailwindCSS loads the site's tailwind.config.js through require at startup, so top-level code in that file executes inside the permitted Node process and can call child_process to spawn a shell. The spawned process is not a Node process and inherits none of the permission flags, so it runs with the full privileges of the account performing the build. Building a site whose theme, module, or starter template supplies the Tailwind configuration therefore yields arbitrary command execution rather than the confined file access the permission model was introduced to enforce. Hugo 0.165.0 removes tailwindcss from the default security.exec.allow list, so the tool is no longer launched under the default configuration.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability in Hugo versions prior to 0.165.0 represents a critical failure in process isolation and permission enforcement within its static site generation pipeline. While version 0.161.0 introduced Node asset pipelines with the intent of restricting file system access via the Node.js permission model, this security boundary was effectively bypassed through improper handling of child processes spawned by specific build tools. The core issue lies in how Hugo manages external tool execution when using TailwindCSS as part of its post-processing workflow for CSS assets. By design, Hugo attempts to confine code running through PostCSS, Babel, or TailwindCSS so that it cannot access files outside the project directory, thereby preventing unauthorized data exfiltration or modification of system-critical files during the build process.
The technical flaw originates in version 0.162.0 when tailwindcss was added to the AllowChildProcess default configuration within security/securityConfig.go. This addition causes Hugo's execution logic in common/hexec/exec.go to append the --allow-child-process flag whenever TailwindCSS is launched. While this flag permits Node.js scripts to spawn child processes, it does not extend these permissions to the spawned children themselves. Consequently, when a site’s theme, module, or starter template includes a tailwind.config.js file that executes top-level code during startup, any invocation of child_process.spawn within that configuration will launch an external shell process. This newly created shell inherits none of the restrictive permission flags applied to the parent Node process and instead runs with the full privileges of the user account performing the build operation.
This architectural oversight results in arbitrary command execution capabilities for anyone who can influence the content or theme of a Hugo site built using vulnerable versions. An attacker could supply a malicious tailwind.config.js file within a theme, module, or starter template that utilizes Node’s child_process API to execute system commands. Because these commands run with elevated privileges rather than being confined by the intended sandboxing mechanisms, they can read sensitive configuration files, modify source code, install malware, or pivot further into internal networks depending on the build environment's security posture. This scenario aligns closely with CWE-78 Improper Neutralization of Special Elements used in an OS Command and reflects ATT&CK techniques related to command and script interpretation as well as process injection through legitimate system utilities.
The operational impact is severe because it undermines the fundamental trust model of static site generation where content authors are expected not to have server-level access. If a malicious theme or module is adopted, particularly in automated CI/CD pipelines running with high privileges such as root or administrator accounts, the resulting build process becomes an attack vector for complete system compromise. The vulnerability persists across versions 0.162.0 through 0.164.x because the default configuration continues to permit child processes for TailwindCSS without adequately isolating those subprocesses from host-level permissions.
Mitigation requires upgrading immediately to Hugo version 0.165.0 or later, where tailwindcss has been removed from the default security.exec.allow list. This change ensures that by default, TailwindCSS is not launched with child process privileges unless explicitly configured otherwise by administrators who understand the risks involved. For environments unable to upgrade instantly, disabling Node asset pipelines entirely or configuring strict allowlists for external tool execution can reduce exposure. Additionally, auditing all themes and modules for malicious tailwind.config.js files containing dynamic code execution patterns provides a defensive layer against supply chain attacks leveraging this specific flaw.