Hydra is a framework for configuring complex applications. Prior to 1.3.6 and 1.4.0.dev9, it passes Python logging configuration to logging.config.dictConfig() without applying Hydra's target policy to handler class values, formatter, filter, handler, queue, and listener factories. An attacker who controls Hydra logging configuration can therefore select an importable class or factory and cause it to be invoked with the application's privileges, even in versions where instantiate() is protected because the logging path does not use instantiate(). This unsafe callable resolution is a classic code‑injection flaw that can lead to arbitrary code execution and full compromise of the application.

Hydra releases that precede version 1.3.6 and the 1.4.0.dev9 development release carry the bug because the framework passes unfiltered logging configuration to dictConfig() without applying Hydra’s target policy. Any deployment that uses those older versions and accepts user‑supplied logging configuration is vulnerable. The issue is resolved in 1.3.6 and later, as well as in 1.4.0.dev9 and newer releases.

The CVSS base score of 7.8 indicates a high importance of this weakness. EPSS score of <1% shows a very low current exploitation probability. The vulnerability is not listed in the CISA KEV catalog. The likely attack vector is any path by which an attacker can influence Hydra’s logging configuration—such as a misconfigured web interface, API, or configuration repository. If the underlying process runs with elevated privileges, execution of the injected callable elevates the attacker to the same level, constituting a severe breach of confidentiality, integrity, and availability.