GHSA-MWJ6-RFH8-7QF4
Vulnerability from github – Published: 2026-10-07 20:23 – Updated: 2026-10-07 20:23Summary
Hydra's legacy instantiate() target blocklists and related execution-policy
collections are stored in mutable module-level state. Because _locate() can
resolve attributes on imported objects, a configuration can resolve a mutation
method such as .discard(), modify the active policy, and then instantiate a
target that would otherwise be blocked.
Impact
A configuration controlling multiple sibling _target_ entries can first
remove an entry from a target blocklist and then invoke the removed target.
Sibling nodes are processed in insertion order and consult the same mutable
module-level policy.
This affects the legacy/default path without an execution whitelist. The 1.3 blocklist is a defense-in-depth measure rather than a complete security boundary, and applications must not treat arbitrary untrusted configuration as safe to instantiate or use for Python logging configuration.
Released hydra-core versions 1.3.4 through 1.3.6 and 1.4.0.dev4 through
1.4.0.dev9 are affected. Fixed releases are 1.3.7 and 1.4.0.dev10.
The reported direct mutation path does not bypass an execution whitelist
restricted to intended application targets and supplied by trusted Python
code. During remediation, Hydra additionally hardened generic discovery,
dispatch, introspection, alias, callable-result, and deferred-callable paths
that could otherwise undermine name-only authorization.
Technical details
In hydra-core 1.3.4 and 1.3.5, the mutable blocklist is reachable as:
hydra._internal.instantiate._instantiate2.DEFAULT_BLOCKLISTED_MODULES
In hydra-core 1.3.6, the expanded policy includes mutable collections in:
hydra._internal.target_policy
For example:
hydra._internal.target_policy.UNCONTROLLED_EXECUTION_TARGETS.discard
resolves to the bound set.discard method. The mutation target itself is not
blocked on the legacy path. Once an entry is removed, subsequent authorization
checks observe the modified set.
Other runtime policy collections can be attacked similarly by removing denied entries or adding entries to exception sets. Because the collections are module-level state, a successful mutation persists for the lifetime of the Python process unless explicitly reversed.
Safe reproduction
The behavior in hydra-core 1.3.6 can be demonstrated without invoking a shell
command. The finally block restores the modified process-global state:
from omegaconf import OmegaConf
from hydra._internal.target_policy import UNCONTROLLED_EXECUTION_TARGETS
from hydra.utils import instantiate
target = "builtins.eval"
assert target in UNCONTROLLED_EXECUTION_TARGETS
try:
result = instantiate(
OmegaConf.create(
{
"disarm": {
"_target_": (
"hydra._internal.target_policy."
"UNCONTROLLED_EXECUTION_TARGETS.discard"
),
"_args_": [target],
},
"proof": {
"_target_": target,
"_args_": ["40 + 2"],
},
}
)
)
assert result["proof"] == 42
assert target not in UNCONTROLLED_EXECUTION_TARGETS
finally:
UNCONTROLLED_EXECUTION_TARGETS.add(target)
Remediation
The fix makes runtime policy state immutable and integrity checked, and prevents declarative configuration from accessing or mutating Hydra internals and protected Python implementation state. Target authorization now covers canonical resolved identities, aliases, discovery results, callable results, deferred callables, and runtime arguments.
The patch also rejects configuration-driven code, policy, and process- environment mutation, along with unsafe introspection and formatting traversal that can expose protected runtime capabilities.
Hydra 1.3.7 receives these protections as defense in depth; it does not make untrusted configuration sandboxed. Hydra 1.4 additionally uses a trusted, narrowly scoped execution whitelist as the supported security boundary for declarative instantiation and Hydra-controlled Python logging configuration.
Users should upgrade to hydra-core 1.3.7 on the stable line or
1.4.0.dev10 on the development line.
Workarounds
Do not pass configuration from untrusted sources to instantiate() or to
Hydra-controlled Python logging configuration. The 1.3 release line has no
execution-whitelist facility, so users who cannot upgrade immediately must
restrict configuration input to trusted sources.
On affected 1.4 development releases, applications can also supply a trusted, narrowly scoped execution whitelist from Python code. The whitelist itself must not be derived from untrusted configuration.
Restart any long-running process that may already have instantiated untrusted configuration, because a policy mutation persists in process-global state.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "hydra-core"
},
"ranges": [
{
"events": [
{
"introduced": "1.3.4"
},
{
"fixed": "1.3.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "hydra-core"
},
"ranges": [
{
"events": [
{
"introduced": "1.4.0.dev4"
},
{
"fixed": "1.4.0.dev10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-106439"
],
"database_specific": {
"cwe_ids": [
"CWE-470",
"CWE-693"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-07T20:23:57Z",
"nvd_published_at": "2026-10-06T19:18:12Z",
"severity": "HIGH"
},
"details": "## Summary\n\nHydra\u0027s legacy `instantiate()` target blocklists and related execution-policy\ncollections are stored in mutable module-level state. Because `_locate()` can\nresolve attributes on imported objects, a configuration can resolve a mutation\nmethod such as `.discard()`, modify the active policy, and then instantiate a\ntarget that would otherwise be blocked.\n\n## Impact\n\nA configuration controlling multiple sibling `_target_` entries can first\nremove an entry from a target blocklist and then invoke the removed target.\nSibling nodes are processed in insertion order and consult the same mutable\nmodule-level policy.\n\nThis affects the legacy/default path without an execution whitelist. The 1.3\nblocklist is a defense-in-depth measure rather than a complete security\nboundary, and applications must not treat arbitrary untrusted configuration as\nsafe to instantiate or use for Python logging configuration.\n\nReleased `hydra-core` versions 1.3.4 through 1.3.6 and 1.4.0.dev4 through\n1.4.0.dev9 are affected. Fixed releases are 1.3.7 and 1.4.0.dev10.\nThe reported direct mutation path does not bypass an execution whitelist\nrestricted to intended application targets and supplied by trusted Python\ncode. During remediation, Hydra additionally hardened generic discovery,\ndispatch, introspection, alias, callable-result, and deferred-callable paths\nthat could otherwise undermine name-only authorization.\n\n## Technical details\n\nIn `hydra-core` 1.3.4 and 1.3.5, the mutable blocklist is reachable as:\n\n`hydra._internal.instantiate._instantiate2.DEFAULT_BLOCKLISTED_MODULES`\n\nIn `hydra-core` 1.3.6, the expanded policy includes mutable collections in:\n\n`hydra._internal.target_policy`\n\nFor example:\n\n`hydra._internal.target_policy.UNCONTROLLED_EXECUTION_TARGETS.discard`\n\nresolves to the bound `set.discard` method. The mutation target itself is not\nblocked on the legacy path. Once an entry is removed, subsequent authorization\nchecks observe the modified set.\n\nOther runtime policy collections can be attacked similarly by removing denied\nentries or adding entries to exception sets. Because the collections are\nmodule-level state, a successful mutation persists for the lifetime of the\nPython process unless explicitly reversed.\n\n## Safe reproduction\n\nThe behavior in `hydra-core` 1.3.6 can be demonstrated without invoking a shell\ncommand. The `finally` block restores the modified process-global state:\n\n```python\nfrom omegaconf import OmegaConf\n\nfrom hydra._internal.target_policy import UNCONTROLLED_EXECUTION_TARGETS\nfrom hydra.utils import instantiate\n\ntarget = \"builtins.eval\"\nassert target in UNCONTROLLED_EXECUTION_TARGETS\n\ntry:\n result = instantiate(\n OmegaConf.create(\n {\n \"disarm\": {\n \"_target_\": (\n \"hydra._internal.target_policy.\"\n \"UNCONTROLLED_EXECUTION_TARGETS.discard\"\n ),\n \"_args_\": [target],\n },\n \"proof\": {\n \"_target_\": target,\n \"_args_\": [\"40 + 2\"],\n },\n }\n )\n )\n\n assert result[\"proof\"] == 42\n assert target not in UNCONTROLLED_EXECUTION_TARGETS\nfinally:\n UNCONTROLLED_EXECUTION_TARGETS.add(target)\n```\n\n## Remediation\n\nThe fix makes runtime policy state immutable and integrity checked, and\nprevents declarative configuration from accessing or mutating Hydra internals\nand protected Python implementation state. Target authorization now covers\ncanonical resolved identities, aliases, discovery results, callable results,\ndeferred callables, and runtime arguments.\n\nThe patch also rejects configuration-driven code, policy, and process-\nenvironment mutation, along with unsafe introspection and formatting traversal\nthat can expose protected runtime capabilities.\n\nHydra 1.3.7 receives these protections as defense in depth; it does not make\nuntrusted configuration sandboxed. Hydra 1.4 additionally uses a trusted,\nnarrowly scoped execution whitelist as the supported security boundary for\ndeclarative instantiation and Hydra-controlled Python logging configuration.\n\nUsers should upgrade to `hydra-core` 1.3.7 on the stable line or\n1.4.0.dev10 on the development line.\n\n## Workarounds\n\nDo not pass configuration from untrusted sources to `instantiate()` or to\nHydra-controlled Python logging configuration. The 1.3 release line has no\nexecution-whitelist facility, so users who cannot upgrade immediately must\nrestrict configuration input to trusted sources.\n\nOn affected 1.4 development releases, applications can also supply a trusted,\nnarrowly scoped execution whitelist from Python code. The whitelist itself must\nnot be derived from untrusted configuration.\n\nRestart any long-running process that may already have instantiated untrusted\nconfiguration, because a policy mutation persists in process-global state.",
"id": "GHSA-mwj6-rfh8-7qf4",
"modified": "2026-10-07T20:23:58Z",
"published": "2026-10-07T20:23:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/hydra-ecosystem/hydra/security/advisories/GHSA-mwj6-rfh8-7qf4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-106439"
},
{
"type": "WEB",
"url": "https://github.com/hydra-ecosystem/hydra/commit/0dd18084589a3d3e577d1f1a8a48fb485c94a5e6"
},
{
"type": "WEB",
"url": "https://github.com/hydra-ecosystem/hydra/commit/4720dfca2bde27fa140ec287a05709668fbdf168"
},
{
"type": "PACKAGE",
"url": "https://github.com/hydra-ecosystem/hydra"
},
{
"type": "WEB",
"url": "https://github.com/hydra-ecosystem/hydra/releases/tag/v1.3.7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Hydra: Mutable instantiate policy sets allow target blocklist bypass"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.