CVE-2026-106439 in Hydra
Summary
by MITRE • 10/07/2026
Hydra is a framework for elegantly configuring complex applications. From 1.3.4 until 1.3.7 and 1.4.0.dev10, Hydra stores legacy instantiate target blocklists and related execution-policy collections in mutable module-level state. An attacker who controls multiple sibling target entries can resolve hydra._internal.target_policy.UNCONTROLLED_EXECUTION_TARGETS.discard through instantiate(), remove a denied target, and then invoke that target because sibling nodes are processed in insertion order against the same modified policy. The mutation persists in process-global state and can enable code execution with the application's privileges, while a narrow execution whitelist supplied by trusted Python code is not bypassed by the reported direct mutation path. This issue is fixed in versions 1.3.7 and 1.4.0.dev10.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability identified within Hydra, specifically affecting versions from 1.3.4 through 1.3.7 and version 1.4.0.dev10, represents a critical flaw in the framework's configuration handling mechanism for instantiating objects. Hydra is widely used as a framework to manage complex application configurations, particularly those involving dynamic object instantiation based on YAML or other structured data inputs. The core of this vulnerability lies in how legacy instantiate target blocklists and related execution policy collections are managed internally. These security-critical lists were stored in mutable module-level state rather than being isolated per configuration instance or processed immutably during the resolution phase. This architectural decision created a shared global context where security policies could be inadvertently modified by subsequent operations within the same process, leading to a breakdown in the intended isolation of execution controls.
The technical flaw exploits the order of processing for sibling target entries and the mutability of the internal policy state. When Hydra processes configuration nodes that involve instantiation targets, it evaluates them against an allowlist or blocklist defined in hydra._internal.target_policy.UNCONTROLLED_EXECUTION_TARGETS. In vulnerable versions, this list is mutable at the module level. An attacker who controls multiple sibling target entries within a single configuration structure can manipulate the processing order to their advantage. By placing specific nodes earlier in the sequence, an attacker can trigger code that calls the discard method on the UNCONTROLLED_EXECUTION_TARGETS set via the instantiate function. This action effectively removes denied targets from the blocklist before those targets are subsequently evaluated and executed later in the same configuration tree due to insertion order processing.
This mutation of global state has severe operational implications, primarily enabling unauthorized code execution with the privileges of the application running Hydra. Because the modification persists for the duration of the process, any subsequent instantiation requests that rely on these policies will operate under a compromised security posture where previously blocked targets are now permitted. This effectively bypasses narrow execution whitelists supplied by trusted Python code, as the whitelist itself is dynamically altered during runtime rather than being enforced statically or per-request. The impact is particularly dangerous in multi-tenant environments or applications that process untrusted configuration files, as it allows an attacker to escalate privileges and execute arbitrary code within the context of the vulnerable application.
From a classification perspective, this vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection) due to the ability to bypass execution restrictions and inject unintended targets into the instantiation pipeline. It also relates to CWE-613 Insufficient Session Expiration as it involves improper management of session or process-level security state that persists beyond its intended scope. In terms of MITRE ATT&CK, this behavior is consistent with Tactic TA0005 Defense Evasion and Technique T1211 Exploitation for Defense Evasion, where the attacker modifies system configurations to avoid detection or restriction mechanisms. The specific mechanism of altering global state to bypass access controls can also be viewed through the lens of T1648 Supply Chain Compromise if the configuration is derived from external sources, though it primarily fits within local privilege escalation and defense evasion patterns.
Mitigation for this issue requires immediate upgrading to fixed versions 1.3.7 or later in the 1.3.x series, or version 1.4.0.dev10 and newer releases where the mutable module-level state has been refactored. Developers should ensure that configuration processing isolates security policies per instance rather than relying on shared global variables that can be mutated by untrusted input. Additionally, implementing strict validation of all instantiation targets against a static allowlist before any dynamic resolution occurs can provide an additional layer of defense. Security teams monitoring for this vulnerability should look for signs of unexpected object instantiations or changes in application behavior following the processing of complex configuration files containing multiple sibling nodes with varying target specifications.