Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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…
Recommended action: Upgrade to 1.4.0rc3 (pre-release) or 1.3.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.4.0.dev10 (pre-release) or 1.3.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.4.0.dev9 (pre-release) or 1.3.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.4.0.dev9 (pre-release) or 1.3.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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…
Recommended action: Upgrade to 1.3.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.