Description

Hydra is a framework for elegantly configuring complex applications. Prior to 1.3.4, hydra.utils.instantiate() resolves and calls Python objects selected by configuration through _resolve_target() in hydra/_internal/instantiate/_instantiate2.py, allowing attacker-controlled target values and arguments to choose dangerous callables. A consuming application, library, CLI workflow, or model loader that passes untrusted configuration, CLI overrides, or model metadata into hydra.utils.instantiate() can therefore execute arbitrary code in its own process, including reading or modifying files and credentials or terminating the process. Version 1.3.4 adds target blocking with an explicit HYDRA_INSTANTIATE_ALLOWLIST_OVERRIDE escape hatch. This issue is fixed in version 1.3.4.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-21T21:17:02.963Z",
  "pubdate": "2026-08-21T21:17:02.963Z",
  "executiveSummary": "An arbitrary code execution vulnerability exists in the Hydra framework prior to version 1.3.4. The vulnerability resides in the hydra.utils.instantiate() function, which insecurely resolves and executes Python objects designated via configuration parameters through _resolve_target() located in hydra/_internal/instantiate/_instantiate2.py.\nIf a consuming application, library, command-line interface workflow, or model loader processes untrusted configuration inputs, command-line overrides, or model metadata using hydra.utils.instantiate(), an attacker can supply malicious target values and arguments to execute arbitrary Python code within the application process.\nThe impact of successful exploitation includes reading, modifying, or deleting sensitive files, compromising credentials, and terminating the host process, leading to a complete compromise of the application's integrity and confidentiality.\nThe risk is particularly high in environments where untrusted user-supplied configurations are dynamically loaded and instantiated. Exploitation requires the application to pass attacker-controlled configuration data into the vulnerable instantiation routine.\nVersion 1.3.4 addresses this risk by introducing strict target blocking mechanisms paired with the HYDRA_INSTANTIATE_ALLOWLIST_OVERRIDE escape hatch for necessary administrative overrides.",
  "technicalDetails": "The vulnerability stems from insecure dynamic object instantiation within the Hydra framework. Specifically, the vulnerable component is the _resolve_target() function implemented in hydra/_internal/instantiate/_instantiate2.py, which is invoked by hydra.utils.instantiate().\nRoot Cause: The function processes configuration objects by dynamically resolving and invoking arbitrary Python callables designated by configuration strings. Without sufficient validation, allowlisting, or restriction on the target values and arguments, the mechanism interprets and executes any reachable Python object specified in the configuration payload.\nAttack Flow: Step 1. The attacker crafts a malicious configuration payload, command-line override, or model metadata containing a target parameter pointing to a dangerous or sensitive Python callable (such as system execution functions or file I/O utilities) along with malicious arguments. Step 2. The consuming application receives the untrusted input and passes it directly to hydra.utils.instantiate(). Step 3. The internal routine _resolve_target() resolves the attacker-specified target object. Step 4. Hydra invokes the target callable with the supplied malicious arguments within the execution context and privileges of the host process.\nAffected Versions: All versions of Hydra prior to 1.3.4 are affected by this insecure instantiation flaw.\nAuthentication and Privileges: No specific authentication is inherently required by the vulnerability itself; however, exploit success depends on the application's exposure to untrusted inputs. The privileges required to execute malicious payloads are equivalent to the permission level of the process running the consuming application.\nPost-Exploitation Impact: Once arbitrary code execution is achieved, an attacker can perform actions including reading or writing arbitrary files on the underlying filesystem, accessing environment variables and credentials stored in memory, and disrupting service operations by terminating the process."
}