GHSA-wf6j-7hvr-gr93: High severity pip/hydra-core vulnerability
Summary
Hydra's legacy target blacklist omits PyYAML's unsafe loading surfaces. If an application passes attacker-controlled targets and arguments to instantiate(), a target such as yaml.unsafeload can execute Python code through a config-controlled YAML stream containing Python object-construction tags.
Impact and prerequisites
The attacker must control the relevant target and arguments that the application instantiates. The configured callable executes with the application's process privileges. This is a gap in the best-effort legacy blacklist. It is not a bypass of Hydra 1.4's execution whitelist supplied by trusted Python code.
One realistic exposure is a model downloaded from a third-party repository, such as Hugging Face, that bundles attacker-controlled configuration. When a victim loads the model using application code that passes this configuration to legacy Hydra instantiation without effective target restrictions, the model's metadata can execute code in the victim process. This model-loading attack pattern is documented in the original Hydra advisory GHSA-2cp2-2r3c-7p7r and the associated Unit 42 research. It does not imply that all Hugging Face models or currently patched downstream loaders are affected.
Hydra 1.3's blacklist is defense in depth, not a complete security boundary. Hydra 1.4 is affected on its deprecated no-whitelist legacy path. Installed application wrappers can perform indirect operations beyond a name-based blacklist's coverage; this fix does not make arbitrary configuration safe.
The unsafeload finding is directly reproduced. PyYAML 6.0.3 fullload rejects the demonstrated python/object/apply payload, so the finding does not claim that all PyYAML loading APIs execute that payload.
Remediation
The fix blocks the yaml. target namespace except for the exact yaml.safeload, yaml.safeloadall, yaml.safedump, and yaml.safedumpall functions. Loader classes, constructor registration, general dump/load APIs, and other targets in the namespace remain blocked. Existing canonical-identity checks also cover aliases. The fix preserves Hydra 1.4's explicit unsafe opt-out for trusted use.
Workarounds
Do not pass untrusted configuration to instantiate() or call(). For Hydra 1.4, supply a narrow execution whitelist from trusted Python code. Do not let untrusted configuration select its own execution policy or opt out of checks.
Affected releases
The reported incomplete-remediation stable range is hydra-core 1.3.6 through 1.3.7. The 1.4 prerelease legacy path is also affected, including 1.4.0.dev9, 1.4.0.dev10, 1.4.0rc1, and 1.4.0rc2. The related blacklist advisory GHSA-rqx7-p7vv-w7hr was first patched in 1.3.6 and 1.4.0.dev9; these ranges describe the remaining omission after that remediation.
Credit
Reported by zx (@manus-pi).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/hydra-coreto a version that resolves this vulnerability.Fixed in 1.4.0rc3 - Upgrade
Upgrade
pip/hydra-coreto a version that resolves this vulnerability.Fixed in 1.3.8 - Configuration
Supply a narrow execution whitelist from trusted Python code; do not allow untrusted configuration to select its own execution policy or opt out of checks.
Hydra 1.4 legacy instantiation path execution whitelist = A narrow whitelist supplied by trusted Python code - Compensating control
Do not pass untrusted configuration to instantiate() or call(); ensure attacker-controlled targets and arguments cannot reach these execution paths.
Event History
Frequently Asked Questions
What conditions are required for exploitation?
An attacker must control the target and arguments passed to Hydra's legacy instantiate() mechanism. They can then select yaml.unsafe_load and provide a YAML stream with Python object-construction tags, causing code to run with the application process's privileges.
Are applications using Hydra 1.4's execution whitelist affected by this issue?
No. The issue is a gap in the legacy best-effort blacklist and is not a bypass of Hydra 1.4's execution whitelist when that whitelist is supplied by trusted Python code.
Which deployments are most realistically exposed?
Applications that load untrusted third-party configuration and pass it into legacy Hydra instantiation without effective target restrictions are exposed. One documented pattern is loading a third-party model repository whose bundled metadata controls Hydra configuration.
What can be done if updating is not immediately possible?
Do not pass attacker-controlled targets or arguments to legacy instantiate(), and apply effective restrictions on which targets may be instantiated. Treat configuration bundled with untrusted model repositories as potentially code-executing in this usage pattern.