Hydra Framework EUVD-2026-64130

Exploitation requires that a consuming application passes attacker-controlled configuration data into hydra.utils.instantiate(). The specific trigger is the presence of a _target_ key in Hydra configuration that maps to any Python callable - including dangerous builtins and OS primitives - which is supported by default in all pre-1.3.4 versions with no restrictions whatsoever. Concrete attack surfaces include: CLI override arguments (e.g., +some.key=subprocess.Popen), YAML config files loaded from untrusted paths, and ML model metadata config files bundled with downloaded model checkpoints. Exploitation is limited to deployments where untrusted data reaches a hydra.utils.instantiate() call; applications that load configuration exclusively from fully trusted, internally controlled sources have no meaningful exposure. The CVSS UI:R metric reflects that a user or automated process must actively invoke the Hydra-based application with the malicious config, ruling out passive exploitation. Authentication requirements are not applicable in the traditional sense - the attacker needs the ability to influence configuration inputs, not system credentials.

The CVSS 3.1 score of 7.8 (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) reflects a local attack vector with required user interaction, which partially constrains the attack surface - exploitation requires a user or automated pipeline to execute a Hydra-based application with attacker-influenced configuration. However, the local-vector classification understates real-world risk in ML/AI deployment contexts: model loaders, training scripts, and inference pipelines frequently ingest configuration from remote or third-party sources such as downloaded model checkpoints and config cards, effectively elevating the practical attack vector beyond purely local access. EPSS data was not provided, so exploitation probability cannot be quantified independently. The vulnerability does not appear in CISA KEV, and no public exploit code has been identified at time of analysis. The blocklist-based fix, while extensive, is a defense-in-depth measure rather than a complete architectural remedy - the underlying design of resolving arbitrary callables from configuration remains, making allowlist bypass a plausible future research target. Teams using Hydra in pipelines that consume external model metadata or third-party configs should treat this as a high priority regardless of the local-vector CVSS classification.

An attacker embeds a malicious _target_: subprocess.Popen entry with attacker-chosen shell arguments into a YAML configuration file or ML model metadata card distributed via a model hub or repository. When a developer or automated training pipeline runs a Hydra-based script that ingests this configuration and calls hydra.utils.instantiate(), the framework resolves and executes subprocess.Popen with the attacker-supplied arguments, achieving arbitrary command execution within the application process. No public proof-of-concept has been identified at time of analysis, but the attack pattern is straightforward given the public advisory and the patch diff revealing the precise vulnerable code path.