hydra-core

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.unsafe_load 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 unsafe_load finding is directly reproduced. PyYAML 6.0.3 full_load 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.safe_load, yaml.safe_load_all, yaml.safe_dump, and yaml.safe_dump_all 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).

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.unsafe_load 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 unsafe_load finding is directly reproduced. PyYAML 6.0.3 full_load 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.safe_load, yaml.safe_load_all, yaml.safe_dump, and yaml.safe_dump_all 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).

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.unsafe_load 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 unsafe_load finding is directly reproduced. PyYAML 6.0.3 full_load 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.safe_load, yaml.safe_load_all, yaml.safe_dump, and yaml.safe_dump_all 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).

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.unsafe_load 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 unsafe_load finding is directly reproduced. PyYAML 6.0.3 full_load 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.safe_load, yaml.safe_load_all, yaml.safe_dump, and yaml.safe_dump_all 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).

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/execution_whitelist/

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/execution_whitelist/

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.unsafe_load 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 unsafe_load finding is directly reproduced. PyYAML 6.0.3 full_load 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.safe_load, yaml.safe_load_all, yaml.safe_dump, and yaml.safe_dump_all 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).

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.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.

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.unsafe_load 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 unsafe_load finding is directly reproduced. PyYAML 6.0.3 full_load 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.safe_load, yaml.safe_load_all, yaml.safe_dump, and yaml.safe_dump_all 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).

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.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.

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.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.

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/execution_whitelist/

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/execution_whitelist/

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.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.

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/execution_whitelist/

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/execution_whitelist/

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.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.

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/execution_whitelist/

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/execution_whitelist/

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.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.

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/execution_whitelist/

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/execution_whitelist/

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.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.

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/execution_whitelist/

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/execution_whitelist/

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.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.

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/execution_whitelist/

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/execution_whitelist/

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/execution_whitelist/

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/execution_whitelist/

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/execution_whitelist/

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.

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/execution_whitelist/

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/execution_whitelist/

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/execution_whitelist/

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.

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/execution_whitelist/

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.

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/execution_whitelist/

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.

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/execution_whitelist/

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.

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/execution_whitelist/

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.

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/execution_whitelist/

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.

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/execution_whitelist/

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.

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/execution_whitelist/

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.

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/execution_whitelist/

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.

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/execution_whitelist/

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.

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/execution_whitelist/

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.

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/execution_whitelist/