GHSA-2cp2-2r3c-7p7r is a high-severity (CVSS 7.8) Code Injection vulnerability in hydra-core. A fix is available for hydra-core — see the affected versions and patch details below.
Hydra: hydra.utils.instantiate with untrusted config can lead to code execution
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-2cp2-2r3c-7p7r.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-2cp2-2r3c-7p7r by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 382,795 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
hydra-coreReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
hydra.utils.instantiate() resolves and calls Python objects from config. If an
application passes untrusted config to instantiate(), an attacker who controls
_target_ and its arguments can cause arbitrary code execution in the consuming
process.
Hydra is not a network service. Exploitation requires a consuming application,
library, or user workflow to load attacker-controlled config, CLI overrides, or
model metadata and pass it to hydra.utils.instantiate().
Details
Hydra's instantiate API is designed to construct objects and call functions from configuration. For example:
component:
_target_: package.module.Class
arg: value
When this config is passed to hydra.utils.instantiate(), Hydra resolves
_target_ and calls it with the provided arguments.
This is intended for trusted application configuration. However, if untrusted
input controls _target_, the config becomes a callable-selection mechanism. A
malicious config can select a callable capable of executing code or commands and
provide attacker-controlled arguments.
This issue is the same general class of problem discussed by Unit 42 for downstream AI/ML libraries such as NVIDIA NeMo, where untrusted model metadata was passed into Hydra instantiate:
https://unit42.paloaltonetworks.com/rce-vulnerabilities-in-ai-python-libraries/
Hydra 1.3.4 includes a blacklist for some dangerous _target_ values. That
blacklist is defense-in-depth and is not a complete security boundary. The
blacklist is not present in the released hydra-core 1.3.3 package, so this
issue should not be described as a bypass of a released 1.3.3 blacklist.
Impact
A successful attack can execute code in the process that calls
hydra.utils.instantiate(). The impact is limited to the privileges and
environment of that process.
Potential impact includes:
- Reading files, credentials, environment variables, or data accessible to the process
- Modifying files, outputs, checkpoints, or application state writable by the process
- Terminating or disrupting the process
Affected Usage
Applications and libraries are affected when they pass untrusted or semi-trusted
config, model metadata, CLI overrides, or other externally controlled data to
hydra.utils.instantiate() without constraining which targets may be
instantiated.
Trusted application-owned configuration is not affected in the same way.
Remediation
Hydra 1.3.4 hardens the existing behavior by adding a blacklist of obvious dangerous targets. It is a substantial security improvement, and users remaining on the 1.3 release line should upgrade to 1.3.4 or a newer version.
The unreleased Hydra 1.4 development line uses an allowlist-based instantiation model that fully addresses this vulnerability class. The allowlist must come from trusted application code or another trusted channel, not from the untrusted config being instantiated.
Applications that consume untrusted or semi-trusted config should not pass it
directly to hydra.utils.instantiate(). They should validate _target_ values
against a trusted allowlist before instantiation.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | hydra-core | all versions | 1.3.4pip install --upgrade 'hydra-core==1.3.4' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for hydra-core, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update hydra-core to 1.3.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-2cp2-2r3c-7p7r is resolved across your whole dependency graph.
Workarounds
Stop passing untrusted input into the interpreter or shell: call the affected binary with an argument array rather than a composed command string, reject anything outside a strict allowlist of expected values, and run the component under an account that cannot reach beyond the work it legitimately does.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
To mitigate this issue, applications using the Hydra framework should be configured to only process configuration, CLI overrides, or model metadata from trusted sources. Avoid passing untrusted or unvalidated input to `hydra.utils.instantiate()` to prevent arbitrary code execution.Source: Red Hat security advisory for GHSA-2cp2-2r3c-7p7r (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat AI Inference Server 3.4 | rhaii/vllm-cpu-rhel9:1790075793 | RHSA-2026:70965 |
| Red Hat AI Inference Server 3.4 | rhaii/vllm-cuda-rhel9:1790090131 | RHSA-2026:70979 |
Frequently Asked Questions
Is GHSA-2cp2-2r3c-7p7r in your dependencies?
Find it across PyPI, including transitive dependencies.