CVE-2026-82862 in Hulumi
Summary
by MITRE • 08/31/2026
Hulumi versions before v1.3.2 resolve the threat-model helper script from an unsafe root, allowing workspace files to shadow the intended helper script. Attackers can place malicious files in the workspace to execute arbitrary code during local skill execution.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/31/2026
The vulnerability identified in Hulumi prior to version 1.3.2 represents a critical flaw in how the application resolves external dependencies and helper scripts, specifically falling under the category of insecure default configurations within file system operations. The core technical issue stems from the way the threat-model helper script is located during execution. Instead of using an absolute path or resolving the script relative to its own installation directory, Hulumi relies on a search mechanism that includes unsafe root directories in its resolution order. This design choice creates a classic shadowing vulnerability where files present in the current working directory can intercept and override legitimate system resources intended for internal use by the application logic.
From an attacker's perspective, this flaw enables arbitrary code execution through workspace manipulation. When a user initiates local skill execution within Hulumi, the application searches for necessary helper scripts to perform threat modeling tasks. Because the resolution path includes directories that are writable and controlled by the end-user or potentially influenced by external inputs, an adversary can place a malicious script with the same filename as the legitimate helper in one of these shadowing locations. Upon invocation, the operating system's dynamic linker or shell interpreter will prioritize the file found first in the search path, which is often the user-controlled workspace directory over the secure installation directory. Consequently, instead of executing the trusted Hulumi utility, the runtime environment executes the attacker-supplied malicious code with the privileges of the invoking user process.
The operational impact of this vulnerability is severe as it bypasses standard sandboxing or isolation expectations that users might have when running local skills. Since the execution occurs in a context where the user has write access to their workspace files, no additional privilege escalation beyond what the user already possesses on the host system is required for exploitation. This makes the attack vector highly accessible and difficult to detect through traditional perimeter defenses because the malicious activity appears as legitimate application behavior initiated by an authorized user. The attacker gains full control over the execution context of that process, potentially leading to data exfiltration, persistence mechanisms being established within the workspace, or further lateral movement if sensitive credentials are stored in environment variables accessible during script execution.
This vulnerability aligns closely with Common Weakness Enumeration (CWE) identifiers such as CWE-427, which describes Uncontrolled Search Path Element, and CWE-94, specifically the code injection variant where user input influences program control flow through file system manipulation. In terms of the MITRE ATT&CK framework, this behavior facilitates Initial Execution via User Execution or System Services depending on how Hulumi is invoked, but more critically it supports Defense Evasion techniques like Masquerading, as the malicious script mimics a legitimate component to avoid detection by security monitoring tools that might whitelist known application binaries.
Mitigation strategies must focus on hardening file system access patterns within the application codebase. The primary remediation involves refactoring the threat-model helper resolution logic to use absolute paths derived from the executable's location or an explicitly defined, secure configuration directory rather than relying on relative path searches through potentially untrusted directories like the current working directory. Developers should implement strict allow-listing for file resolutions and ensure that application resources are loaded exclusively from verified installation locations. For users unable to immediately upgrade, restricting write permissions on workspace directories where Hulumi operates can reduce the risk of shadowing attacks, although this may impact legitimate workflow functionality. Upgrading to version 1.3.2 or later is the definitive solution as it corrects the path resolution logic to prevent unauthorized file interception and ensures that helper scripts are sourced from trusted locations only.