Summary
Hydra: Mutable instantiate policy sets allow target blocklist bypass
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.
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)
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.
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.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
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.
Frequently Asked Questions
- What is CVE-2026-106439? CVE-2026-106439 is a high-severity security vulnerability in hydra-core (pip), affecting versions >= 1.3.4, < 1.3.7. It is fixed in 1.3.7, 1.4.0.dev10.
- Which versions of hydra-core are affected by CVE-2026-106439? hydra-core (pip) versions >= 1.3.4, < 1.3.7 is affected.
- Is there a fix for CVE-2026-106439? Yes. CVE-2026-106439 is fixed in 1.3.7, 1.4.0.dev10. Upgrade to this version or later.
- Is CVE-2026-106439 exploitable, and should I be worried? Whether CVE-2026-106439 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-106439 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-106439?
- Upgrade
hydra-coreto 1.3.7 or later - Upgrade
hydra-coreto 1.4.0.dev10 or later
- Upgrade