Summary
Hydra's instantiate() API resolves and invokes Python callables named by the target field in configuration. The target blacklist introduced for CVE-2026-68508 was incomplete.
Representative bypasses included execution wrappers such as timeit.timeit, executable deserialization through pickle.loads, and generic dispatch or wrapper targets that obscured the effective callable. Target aliases, callable-returning helpers, and deferred dispatch could similarly bypass name-based checks.
An attacker who can cause an application to instantiate an untrusted Hydra configuration can use these gaps to execute code with the application's privileges.
Fix
Hydra 1.3.6 expands and hardens the blacklist used by the 1.3 compatibility line. It blocks the reported execution and deserialization surfaces, checks canonical callable identities and aliases, mediates callable results, and blocks generic dispatch and wrapper targets that bypass immediate target checks.
The Hydra 1.3 blacklist is a best-effort, defense-in-depth measure. It is not a complete security boundary and does not make untrusted configuration safe to instantiate.
Hydra 1.4.0.dev9 applies the same hardening and introduces the execution whitelist as the recommended primary security boundary. When a whitelist is supplied, targets are rejected unless trusted Python code authorizes them. If no whitelist is supplied, Hydra preserves legacy behavior with a deprecation warning and the blacklist as a best-effort compatibility fallback. Targets that permit configuration to select or supply executable behavior remain non-whitelistable.
Remediation
Upgrade to Hydra 1.3.6, or to Hydra 1.4.0.dev9 or later when testing the 1.4 prerelease line.
On Hydra 1.3, do not instantiate configuration from untrusted sources. On Hydra 1.4 and later, constrain untrusted configuration with a narrow execution whitelist supplied by trusted Python code.
For Hydra 1.4 execution-whitelist configuration, see: https://hydra.cc/docs/advanced/executionwhitelist/
Summary
Hydra passed its Python logging configuration to logging.config.dictConfig(). Python's logging configurator can resolve and invoke importable classes and factories named by configuration, including handler class values and formatter, filter, handler, queue, and listener () factories.
This logging path was not mediated by Hydra's target policy. In versions that already protected instantiate(), logging resolution bypassed those controls because it did not use instantiate().
An attacker who can control a Hydra logging configuration can use a custom class or factory to execute code with the application's privileges when Hydra configures logging.
Fix
Hydra now applies its target policy to callable resolution and invocation in Hydra-configured Python logging. It authorizes custom factories, handlers, formatters, filters, queues, listeners, aliases, discovery results, and callable results before they can be used.
Hydra 1.3.6 uses the hardened blacklist. The Hydra 1.3 blacklist is a best-effort, defense-in-depth measure. It is not a complete security boundary and does not make untrusted logging configuration safe.
Hydra 1.4.0.dev9 introduces the execution whitelist as the recommended primary boundary, with the blacklist retained as a deprecated compatibility fallback. When an execution whitelist is supplied, Hydra automatically permits targets used by its built-in logging configurations, while custom logging integrations must be explicitly authorized by trusted Python code. If no whitelist is supplied, Hydra warns and preserves legacy fallback behavior.
Remediation
Upgrade to Hydra 1.3.6, or to Hydra 1.4.0.dev9 or later when testing the 1.4 prerelease line.
On Hydra 1.3, do not compose logging configuration from untrusted sources. On Hydra 1.4 and later, constrain custom logging targets with a narrow execution whitelist supplied by trusted Python code. The execution whitelist controls callable selection; it is not general validation of all logging settings.
For Hydra 1.4 execution-whitelist configuration, see:
https://hydra.cc/docs/advanced/executionwhitelist/
Summary
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.DEFAULTBLOCKLISTEDMODULES
In hydra-core 1.3.6, the expanded policy includes mutable collections in:
hydra.internal.targetpolicy
For example:
hydra.internal.targetpolicy.UNCONTROLLEDEXECUTIONTARGETS.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:
python from omegaconf import OmegaConf
from hydra.internal.targetpolicy import UNCONTROLLEDEXECUTIONTARGETS from hydra.utils import instantiate
target = "builtins.eval" assert target in UNCONTROLLEDEXECUTIONTARGETS
try: result = instantiate( OmegaConf.create( { "disarm": { "target": ( "hydra.internal.targetpolicy." "UNCONTROLLEDEXECUTIONTARGETS.discard" ), "args": [target], }, "proof": { "target": target, "args": ["40 + 2"], }, } ) )
assert result["proof"] == 42 assert target not in UNCONTROLLEDEXECUTIONTARGETS finally: UNCONTROLLEDEXECUTIONTARGETS.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.