Hydra's October 2026 Instantiate Vulnerability Explained: Config Is Code

The config stops being data and becomes a program, and whoever writes it can run code on your machine. That is the core of the Hydra instantiate vulnerability, fixed again on 25 October 2026.

Picture a common setup. A small machine learning team has a training tool that downloads a shared model folder from a public model hub. The folder holds weights plus a config.yaml, and the tool builds the model by passing that config to Hydra's instantiate(). The setup is made up, but the advisories describe exactly this pattern.

Everyone on the team thinks of config.yaml as settings: a learning rate, a layer count. Hydra reads one key in it, _target_, as the name of a Python function or class to import and call. Whoever wrote the folder decides that name.

We follow this one training tool through the guide. First the words, then the three advisories, then why each patch was bypassed, then what to do.

• Hydra: an open-source Python library, published on PyPI as hydra-core, that builds an app's settings from YAML files and command-line overrides. The advisories' main example is loading machine learning models.
• YAML: a plain-text format for settings, with keys and values on separate lines. Hydra configs are YAML files.
• instantiate(): a Hydra function that reads a config block and creates the object it describes. Its sibling call() does the same thing under another name.
• _target_: the key inside a config block that holds a dotted Python path, such as myapp.Optimizer. Hydra imports that path and calls it.
• Remote code execution (RCE): an attacker making your program run code of their choice. Here it needs a victim to load the attacker's config.
• Blocklist: a list of names that are refused; everything else is allowed. Hydra's code calls it a blacklist.
• Allowlist: a list of names that are permitted; everything else is refused. Hydra 1.4 calls it an execution whitelist.
• GHSA: a GitHub Security Advisory ID, such as GHSA-wf6j-7hvr-gr93. CVE IDs are the global numbering for the same kind of record.

The Hydra instantiate vulnerability is the risk that untrusted config picks a dangerous callable through _target_. Three GitHub-reviewed advisories cover it, each rated High with a CVSS score of 7.8 out of 10.

The first advisory describes the pattern itself. The second and third each describe a way around the previous fix. Together they are a clean case study of why name blocklists struggle.

Hydra is not a network service, so nobody can attack it directly over the internet. The CVSS vector says local access and user interaction: someone has to load the bad config. In our training tool, that someone is the engineer who downloads the model folder.

It reads the _target_ string, imports the module part, looks up the last part as an attribute, and calls it with the other keys as arguments. Hydra's own docs describe the lookup as a mix of import and getattr.

Here is a harmless module standing in for the training tool's code. The greet function prints a line, so you can see that loading config made code run.

# myapp.py: a harmless stand-in for your project's code
import importlib

class Optimizer:
    def __init__(self, lr: float = 0.1):
        self.lr = lr

    def __repr__(self):
        return f"Optimizer(lr={self.lr})"

def greet(name: str = "world"):
    print(f"[side effect] greet() ran for {name}")
    return f"hello {name}"

def call_by_name(module: str, name: str, arg):
    # A generic dispatcher: the real function is data, not the _target_.
    return getattr(importlib.import_module(module), name)(arg)

Now a config that uses it, and the code that loads it. This is exactly what the training tool does with a downloaded config.yaml.

from hydra.utils import instantiate
from omegaconf import OmegaConf

cfg = OmegaConf.create("""
optimizer:
  _target_: myapp.Optimizer
  lr: 0.01
hello:
  _target_: myapp.greet
  name: config-file
""")
print(instantiate(cfg.optimizer))
print(instantiate(cfg.hello))

Run it next to myapp.py on hydra-core 1.3.8. You should see three lines: Optimizer(lr=0.01), then the side-effect line from greet, then hello config-file. We got identical output on 1.3.3, before any fix.

The call runs with everything your process can touch: files, environment variables, cloud credentials, the GPU box itself. The first advisory lists reading credentials and changing files as possible effects.

Because Python has far more ways to run code than any list can name. Each fix banned the routes people had reported, and the next report used a route nobody had listed.

An analogy helps. A blocklist is a guard with a list of banned visitors; anyone not on the list walks in. An allowlist is a guest list; anyone not on it waits outside. Hydra's targets are the visitors, and the list lives in Hydra's code.

Where the picture breaks: real visitors cannot change their names, but one Python function can be reached under many dotted names. That makes the banned-visitor list even weaker than the analogy suggests.

Round one: 1.3.4 bans the obvious names

Hydra 1.3.4, published to PyPI on 4 July 2026, added a set of 64 exact names plus two prefixes, os.exec and os.spawn. It covered names like os.system, subprocess.run, builtins.eval and importlib.import_module.

The check compared the _target_ string with the list, after mapping posix and nt to os. That is a string test, not a test of what the name finally points to.

Round two: 1.3.6 bans wrappers and deserialisers

The second advisory showed that code can run through functions that are not obviously dangerous. Python's timeit.timeit times a statement given as text, so it executes that text.

Python's own pickle docs warn that malicious pickle data can execute arbitrary code during unpickling, so pickle.loads was another route. The advisory also lists aliases and generic dispatch helpers that hide the real callable.

Hydra 1.3.6, published 29 August 2026, grew the list and started checking the resolved function, not just the string. In our test it reports posix.system as os.system, resolved from posix.system.

Round three: 1.3.8 bans PyYAML's unsafe loaders

The third advisory found that yaml.unsafe_load was not on the list. PyYAML's unsafe loader can build Python objects from tags inside the YAML text, so a config could pass it a stream that runs code.

Hydra 1.3.8 bans every target in the yaml module except four functions: safe_load, safe_load_all, safe_dump and safe_dump_all. The advisory notes PyYAML 6.0.3's full_load rejected the demonstrated payload, so not every loader is claimed exploitable.

The route no list can see: your own code

The 1.3.8 source file says it plainly. Trusted installed callables can indirectly dispatch operations that never appear as _target_ values. Our call_by_name helper is such a callable.

With _target_ set to myapp.call_by_name, the real function is chosen by two ordinary config values, module and name. We ran it on 1.3.8 with math and sqrt, and it returned 4.0. The blocklist only ever saw myapp.call_by_name.

Read the table from left to right and you can watch the list chase the reports. The two main banned-name sets grew from 64 names in 1.3.4 to 187 in 1.3.6 and 225 in 1.3.8. In 1.3.8, smaller sets of dispatch and wrapper helpers and 12 name prefixes come on top. Our own dispatcher passes every version.

An allowlist only has to name what your app needs, which is a short list you already know. A blocklist has to name everything dangerous in Python and every installed library, which nobody can know.

For our training tool the needed list might be three or four names: the model class, the optimiser and the data loader. Every other name, including ones invented next year, is refused by default.

An allowlist is only as good as its entries. If you approve a generic dispatcher like call_by_name, you have approved everything it can reach. Keep entries to concrete classes and functions that do one known job.

Every hydra-core release up to and including 1.3.7 is affected by at least one advisory, and so is every 1.4 pre-release before 1.4.0rc3. You need to act if your app passes config you did not write to instantiate() or call().

• Act now: tools that load configs from downloaded models, shared experiment folders, user uploads, pull requests or job queues, then call instantiate() on them.
• Act now: services that accept command-line overrides or model metadata from users and feed them into instantiate().
• Lower risk: an app that only instantiates config files written by your own team and stored in your own repository. The first advisory says trusted, app-owned config is not affected in the same way.
• Still upgrade: libraries built on Hydra may load configs for you. Check whether any dependency calls instantiate() on files you pass in.

Even on 1.3.8, the advisories say the 1.3 blocklist is not a complete security boundary. Upgrading removes the known routes; it does not make untrusted config safe.

1. 1

   Find where config reaches instantiate()

   Search your code for instantiate( and call( from hydra.utils. For each one, write down where the config comes from.

2. 2

   Upgrade hydra-core to 1.3.8

   Pin hydra-core==1.3.8 in your requirements file and reinstall. As of 28 October 2026 it is the latest stable release.

3. 3

   Stop passing untrusted config

   Do not instantiate configs from downloads, uploads or other people's folders. Read plain values from them instead, and choose classes in your own code.

4. 4

   Add your own allowlist where you must accept outside config

   Before calling instantiate(), check every _target_ against a fixed set of names written in Python. The engineer section shows a tested version.

5. 5

   Plan for the 1.4 whitelist

   Hydra 1.4 is a release candidate today. Try it in a test branch, but keep production on the stable 1.3 line until 1.4.0 is final.

Print the installed version first. Then ask instantiate() to resolve a banned name with _partial_: true, which returns a wrapped function without calling it.

import functools
import hydra
from hydra.utils import instantiate
from omegaconf import OmegaConf

print("hydra-core", hydra.__version__)
for target in ["yaml.safe_load", "yaml.unsafe_load"]:
    cfg = OmegaConf.create({"_target_": target, "_partial_": True})
    try:
        result = instantiate(cfg)
        assert isinstance(result, functools.partial)
        print(target, "accepted (not called)")
    except Exception as e:
        print(target, "refused:", type(e).__name__)

On 1.3.8 you should see hydra-core 1.3.8, then yaml.safe_load accepted and yaml.unsafe_load refused with InstantiationException. On 1.3.7, and on 1.3.3, 1.3.4 and 1.3.6 in our tests, both lines say accepted, and you still need the upgrade.

A note on the 1.3 escape hatch: the environment variable HYDRA_INSTANTIATE_ALLOWLIST_OVERRIDE lets trusted operators unblock some names. In our 1.3.8 test it unblocked os.remove but not os.system, which the source marks as never overridable. We found this split in the 1.3.8 source, not the release notes, as of 28 October 2026; pin your version if you rely on it.

Write the approved names in Python, resolve the config, collect every _target_ in it and refuse the whole config if any name is missing from your set. Only then call instantiate().

from hydra.utils import instantiate
from omegaconf import OmegaConf

# Written in code, never read from the config being checked.
ALLOWED_TARGETS = frozenset({"myapp.Optimizer"})

def find_targets(node):
    if isinstance(node, dict):
        if "_target_" in node:
            yield node["_target_"]
        for value in node.values():
            yield from find_targets(value)
    elif isinstance(node, list):
        for item in node:
            yield from find_targets(item)

def safe_instantiate(cfg):
    plain = OmegaConf.to_container(cfg, resolve=True)  # expand ${...} first
    bad = [t for t in find_targets(plain) if t not in ALLOWED_TARGETS]
    if bad:
        raise ValueError(f"refused targets: {bad}")
    return instantiate(cfg)

We tested it on 1.3.8 with four configs. A plain myapp.Optimizer block built Optimizer(lr=0.01). A top-level myapp.greet was refused, and so was math.sqrt hidden in a list inside an allowed block.

The fourth case hid myapp.greet behind an interpolation, a ${t} reference to another key. Resolving first caught it, and the check refused it.

• Exact matches only: comparing whole strings means an alias such as a re-exported name is refused unless you list it yourself.
• Scope: it checks _target_ keys only. Custom OmegaConf resolvers or your own code that imports names from config values are outside it.
• Pass everything through it: if any code path calls instantiate() directly on outside config, the check does nothing for that path.

Hydra 1.4 makes the allowlist the main boundary, under the name execution whitelist. It is in 1.4.0rc3, a release candidate from 25 October 2026, so details may still change before 1.4.0.

You pass the list from trusted Python code, either to instantiate() as _execution_whitelist_, through the execution_whitelist() context manager, or to @hydra.main(execution_whitelist=...).

from hydra.utils import instantiate
from omegaconf import OmegaConf

cfg = OmegaConf.create({"_target_": "myapp.Optimizer", "lr": 0.01})
print(instantiate(cfg, _execution_whitelist_=["myapp.Optimizer"]))

bad = OmegaConf.create({"_target_": "myapp.greet"})
instantiate(bad, _execution_whitelist_=["myapp.Optimizer"])  # raises InstantiationException

We ran these cases on hydra-core 1.4.0rc3 with OmegaConf 2.4.1rc1 on 28 October 2026:

• With no whitelist, instantiate() still works but emits a Python warning that this will become an error in Hydra 1.5.
• With ["myapp.Optimizer"], the Optimizer block builds and myapp.greet is refused as not in the Hydra execution whitelist.
• A config that sets _execution_whitelist_ inside itself is refused: the list must come from trusted code.
• A bare "*" entry is refused. Only trailing package wildcards such as myapp.* are accepted.
• Listing os.system does not help: Hydra says that target cannot be authorised by the whitelist.
• UNSAFE_DISABLE_EXECUTION_CHECKS restores the old allow-everything behaviour, and its name says what it is.

Two cautions from the docs and our tests. A prefix such as myapp.* also covers modules other installed packages add under that name. And our myapp.* run let call_by_name reach math.sqrt, so a wildcard can approve a dispatcher by accident.

Treat it as a trust-boundary question: who controls the input that chooses which code runs? Use this frame.

1. 1

   Name the boundary

   Config from outside our team crosses into a process with credentials. Anything that turns that config into code needs a gate.

2. 2

   Explain the mechanism

   Hydra's instantiate() imports and calls the dotted name in _target_, so control of the file means control of the call.

3. 3

   Compare blocklist and allowlist

   Blocklists fail open on unknown names and needed three releases. Allowlists fail closed and only need the names our app uses.

4. 4

   Place the list correctly

   The allowed names live in code we review, never in the config they guard, and they avoid generic dispatchers.

5. 5

   Add depth

   Run untrusted loading in a container without secrets, prefer safe formats like JSON or safe YAML loaders, and pin library versions.