Hydra's Four October Advisories: The Config Blocklist Isn't a Boundary

On 7 October 2026, the Hydra project published four high severity advisories for hydra-core and its Optuna sweeper plugin. Hydra is the Python configuration framework that shows up in a lot of ML training code, and its instantiate() function builds objects from a _target_ field in YAML. Each advisory describes a way for a configuration to execute code despite the blocklist added to stop exactly that.

The maintainers are direct about what this means. In their words, the Hydra 1.3 blocklist "is a best-effort, defense-in-depth measure. It is not a complete security boundary and does not make untrusted configuration safe to instantiate." The 1.4 line introduces an execution whitelist as the recommended boundary.

What's affected

• CVE-2026-106442 (CVSS 7.8): the target blocklist introduced for CVE-2026-68508 missed execution wrappers such as timeit.timeit, deserialization through pickle.loads, and generic dispatch or alias targets that hide the real callable. Affects hydra-core 1.3.4 up to 1.3.6 and 1.4.0.dev0 up to dev9. Fixed in 1.3.6 and 1.4.0.dev9.
• CVE-2026-106441 (CVSS 7.8): Hydra passed its logging configuration to Python's logging.config.dictConfig(), which can import and call classes and factories named in the config. That path never went through Hydra's target policy. Affects versions before 1.3.6 and 1.4.0.dev0 up to dev9. Fixed in 1.3.6 and 1.4.0.dev9.
• CVE-2026-106439 (high): the blocklist lived in mutable module-level state. One _target_ entry could resolve a method like .discard() on that set, remove an entry, and a sibling entry could then instantiate the removed target. Affects 1.3.4 through 1.3.6 and 1.4.0.dev4 through dev9. Fixed in 1.3.7 and 1.4.0.dev10.
• CVE-2026-106440 (CVSS 7.8): hydra-optuna-sweeper resolved hydra.sweeper.custom_search_space with hydra.utils.get_method(), which applies no policy, and then called it. Affects 1.2.0 up to 1.3.0 and 1.4.0.dev4 up to dev10. Fixed in hydra-optuna-sweeper 1.3.0 and 1.4.0.dev10.

PyPI shows hydra-core 1.3.7, hydra-optuna-sweeper 1.3.0 and both 1.4.0.dev10 releases were uploaded on 14 September 2026. A 1.4.0rc1 followed on 10 October.

How to check if you're exposed

Versions:

pip show hydra-core hydra-optuna-sweeper 2>/dev/null | grep -E '^(Name|Version)'

Any hydra-core release below 1.3.7 is affected by at least one advisory, and so is hydra-optuna-sweeper 1.2.x. But the real question is the one the maintainers keep repeating: does any configuration you instantiate come from someone you don't fully trust?

Find where configs and overrides enter:

grep -rnE 'instantiate\(|OmegaConf\.load|compose\(|get_method\(|get_class\(' --include=*.py . | head -50
grep -rnE 'custom_search_space' --include=*.yaml --include=*.py .

Configs are untrusted in more places than people expect:

• A training platform or job launcher that lets users submit YAML or command-line overrides.
• Configs pulled from a model hub, a shared bucket or a pull request, and run in CI.
• Experiment configs stored in a database that several teams can write to.
• A notebook that loads a colleague's config file from a shared drive.

If configs only ever come from your own reviewed repository and are run by the people who wrote them, the advisories describe a risk you already accepted. If any of the cases above apply, treat them as code execution paths.

What to do now

1. Upgrade hydra-core to 1.3.7 or later and hydra-optuna-sweeper to 1.3.0 or later. If you track the 1.4 development line, use 1.4.0.dev10 or later.
2. Don't rely on the 1.3 blocklist to make untrusted configs safe. The advisories say it isn't designed to.
3. On 1.4, supply an execution whitelist from trusted Python code that names only your application's intended targets. The maintainers call this the recommended primary boundary.
4. Validate untrusted configs against a schema before they reach instantiate(), and reject any _target_, logging handler class or () factory key you didn't expect.
5. Run user-submitted training jobs in isolated containers with no credentials beyond what the job needs, assuming the config can run code.
6. Treat config changes in pull requests like code changes in review.

Why it matters

Configuration files that name callables are code. Hydra's _target_, Python's logging dictConfig and plugin loaders all share that property, and a denylist over "dangerous callables" in a language as dynamic as Python will always have gaps. Four advisories in one day, including one where the config edits the denylist itself, make that hard to argue with.

The useful shift is from asking "is this config malicious?" to "who can write configs that this process instantiates?". ML platforms increasingly let many people launch jobs with their own overrides. That turns a developer convenience into a remote code execution surface unless you add a real boundary, either a whitelist or an isolated runtime.

Try it yourself

Pick one training repository and list every place a config or override can come from. Mark each source as trusted or untrusted. Then see how a pull request gate can block risky dependency versions before they merge:

Click through it at your own pace, or open it full screen.

Quick check

Sources

• GHSA-rqx7-p7vv-w7hr: Hydra instantiate target blacklist bypasses permit code execution (CVE-2026-106442)
• GHSA-c3wx-c55w-pxjq: Hydra logging configuration permits unsafe callable resolution (CVE-2026-106441)
• GHSA-mwj6-rfh8-7qf4: Mutable instantiate policy sets allow target blocklist bypass (CVE-2026-106439)
• GHSA-5jjj-9xc3-rm56: Optuna custom_search_space resolves untrusted callables (CVE-2026-106440)
• Hydra v1.3.7 release
• hydra-core on PyPI
• hydra-optuna-sweeper on PyPI