Description

Hydra is a framework for elegantly configuring complex applications. From 1.2.0 until 1.3.0 and 1.4.0.dev10, the hydra-optuna-sweeper package accepts a configuration-controlled dotted path in hydra.sweeper.custom_search_space, resolves it with hydra.utils.get_method(), and later invokes the returned callable in the Hydra controller process. Because get_method() is a trusted-input lookup helper and does not apply the execution policy used by instantiate(), an attacker who controls Optuna sweep configuration or command-line overrides can select importable Python code for execution with the application's privileges, including bypassing a trusted execution whitelist on affected Hydra 1.4 development releases. This issue is fixed in versions 1.3.0 and 1.4.0.dev10.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-10-06T19:18:12.877Z",
  "pubdate": "2026-10-06T19:18:12.877Z",
  "executiveSummary": "The hydra-optuna-sweeper package contains an arbitrary code execution vulnerability stemming from insecure handling of configuration-controlled paths.\nThis vulnerability is classified as an improper neutralization of input during web page generation or similar mechanisms, allowing for unauthorized execution of arbitrary Python code.\nAffected versions include 1.2.0 through 1.3.0 (exclusive) and 1.4.0.dev10 (exclusive).\nAn attacker capable of influencing the configuration—typically through Optuna sweep settings or command-line overrides—can trigger the execution of arbitrary Python callables within the Hydra controller process.\nThe risk is critical as it bypasses intended execution policies and trusted whitelists, potentially granting the attacker the same privileges as the application process itself.\nNo authentication is required if the attacker can modify the environment's configuration files or command-line arguments, making this a significant risk for systems deploying Hydra with user-provided configuration inputs.",
  "technicalDetails": "The vulnerability resides within the hydra-optuna-sweeper component, specifically in how it processes the 'hydra.sweeper.custom_search_space' configuration parameter.\nThe core issue is the reliance on 'hydra.utils.get_method()' to resolve a dotted import path provided as a configuration string. Unlike 'instantiate()', which is designed to handle object creation with integrated security policies and execution whitelists, 'get_method()' functions primarily as a lookup utility to dynamically import and return Python callables without applying security constraints.\nThe attack flow begins when an attacker supplies a malicious dotted path to 'hydra.sweeper.custom_search_space'. Because this path is resolved by 'get_method()', the application attempts to import the specified Python module and retrieve the associated function or class constructor.\nOnce resolved, the Hydra controller process executes the returned callable. Because the process executes this object with the full privileges of the application, the attacker achieves arbitrary code execution within the execution environment of the Hydra controller.\nThis behavior specifically subverts the execution policy mechanisms present in later Hydra 1.4 development releases, effectively bypassing existing security whitelists that were intended to restrict which classes or methods could be instantiated or invoked by the framework.\nThe exploitation path is triggered by the sweeper during the configuration instantiation phase of the Hydra lifecycle. By manipulating the configuration—either via YAML files, environment variables, or direct command-line overrides—an attacker directs the application to load and run arbitrary modules accessible in the current Python environment.\nThe impact includes full remote code execution (RCE) with the application's process context, enabling unauthorized file system access, data exfiltration, or further compromise of the host environment depending on the application's runtime permissions."
}