CVE-2026-68508

CVE-2026-68508 in the Hydra configuration library exposes a design flaw that has quietly existed since the project's inception: configs can instantiate arbitrary Python callables, and this capability was never framed as a security boundary. The vulnerability lives in Hydra's `_resolve_target()` mechanism, which resolves config-specified strings to actual Python objects and executes them — a feature, not a bug, that shipped without a threat model treating configs as potentially attacker-controlled. Version 1.3.4 adds a blocklist of dangerous callables and a named escape hatch constant, `HYDRA_INSTANTIATE_ALLOWLIST_OVERRIDE`. The escape hatch is the signal. It acknowledges that legitimate applications genuinely require this behavior — loading model checkpoints with baked-in hyperparameters, piping CLI overrides through automation systems, or serving APIs that accept user-submitted configs. The patch doesn't remove the dangerous path; it documents it. Any application that sets this flag (or that existed before the patch with identical behavior) remains exploitable. The deeper problem is positional. Hydra sits at the center of ML pipelines — where model checkpoints flow between research groups, experiment configs get shared across teams, and hyperparameter sweeps produce artifacts replayed by automated systems. One arbitrary-code-execution vector at that junction doesn't expose one application; it exposes every system that touches those configs downstream. This multiplier effect means the vulnerability's actual blast radius extends far beyond the library itself. A version check of "Hydra >= 1.3.4" gives a false sense of security. Scanners will report the library as patched while production systems continue executing arbitrary targets through the documented escape hatch. The blocklist approach catches known dangerous classes but says nothing about gadget chains through permitted, safe-seeming objects — the same curve every deserialization CVE follows. For defenders: audit your codebase for uses of `HYDRA_INSTANTIATE_ALLOWLIST_OVERRIDE` and treat any such configuration as exploitable until proven otherwise. Assume any config arriving from outside your trust boundary — shared experiment artifacts, model registries, external APIs — could reach Hydra's instantiation path. The fix is architectural, not patchable: treat configuration inputs with the same sanitization rigor applied to deserialized data.

Reviewed through automated stages and approved by a human before publication.