Threat database

hydra-ray-launcher 1.1.0.dev1 before 1.2.2 and 1.4.0.dev4 before 1.4.0rc2 contains an arbitrary module import vulnerability via the ray_pkg_version OmegaConf resolver passing input to importlib.import_module(). Attackers controlling configuration values or command-line overrides can supply a ray_pkg_version interpolation to import any installed module, triggering its import-time side effects in the application process.

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

CVE-2026-106441 is a high-severity code injection vulnerability in the hydra-ecosystem hydra project. The issue arises because Hydra passed its Python logging configuration directly to logging.config.dictConfig() without applying its target policy, allowing resolution and invocation of arbitrary importable classes and factories. This flaw enables an attacker who can control the logging configuration to execute arbitrary code with the application's privileges during logging setup. The vulnerability affects Hydra versions before 1.3.6 and prerelease versions from 1.4.0.dev0 up to but not including 1.4.0.dev9. Hydra 1.3.6 and later apply a hardened blacklist, and 1.4.0.dev9 and later introduce an execution whitelist to control callable invocation securely. Users are advised to upgrade to 1.3.6 or 1.4.0.dev9 or later and avoid composing logging configurations from untrusted sources.

A high-severity vulnerability (CVE-2026-106440) exists in the hydra-ecosystem hydra framework, specifically in the hydra-optuna-sweeper package versions 1.2.0 up to but not including 1.3.0 and 1.4.0.dev4 up to but not including 1.4.0.dev10. The issue involves unsafe reflection where externally controlled input can specify a dotted path to Python code that is resolved and invoked without proper execution policy enforcement. This allows an attacker controlling Optuna sweep configuration or command-line overrides to execute arbitrary Python code with the application's privileges, bypassing trusted execution whitelists. The vulnerability is fixed in versions 1.3.0 and 1.4.0.dev10.

CVE-2026-106439 is a high-severity vulnerability in hydra-ecosystem's hydra affecting versions 1.3.4 through 1.3.6 and 1.4.0.dev4 through 1.4.0.dev9. It involves unsafe reflection where mutable module-level state used for target blocklists can be manipulated via configuration to remove blocked targets and instantiate them, bypassing intended execution restrictions. The vulnerability affects the legacy/default path without an execution whitelist and allows a configuration controlling multiple sibling _target_ entries to mutate the blocklist and invoke otherwise blocked targets. The issue is fixed in hydra-core 1.3.7 and 1.4.0.dev10. Users are advised to upgrade and avoid passing untrusted configuration to instantiate().