Description

Hydra is a framework for elegantly configuring complex applications. Prior to 1.3.6 and 1.4.0.dev9, Hydra passes Python logging configuration to logging.config.dictConfig() without applying Hydra's target policy to handler class values or 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 issue is fixed in versions 1.3.6 and 1.4.0.dev9.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-10-06T19:18:13.020Z",
  "pubdate": "2026-10-06T19:18:13.020Z",
  "executiveSummary": "Hydra is susceptible to an arbitrary code execution vulnerability stemming from insecure handling of logging configurations.\nThe vulnerability type is categorized as an improper input validation flaw leading to arbitrary object instantiation or function invocation.\nThe issue affects Hydra versions prior to 1.3.6 and 1.4.0.dev9.\nBy controlling the logging configuration, an attacker can bypass existing security policies—specifically those designed to restrict object instantiation—and execute arbitrary importable classes or factories.\nThis vulnerability poses a significant risk, as it allows attackers to execute code under the privileges of the application process.\nExploitation requires the attacker to have the ability to influence or supply a malicious logging configuration that Hydra subsequently processes.\nThe vulnerability arises because the logging path bypasses Hydra's internal 'instantiate()' security controls, directly passing user-supplied configuration data to the Python standard library's 'logging.config.dictConfig()' function without appropriate sanitization or target validation.",
  "technicalDetails": "The root cause of this vulnerability is the insecure delegation of configuration data to Python's logging.config.dictConfig() function. Hydra provides a framework for complex application configuration, but it fails to enforce its established target policy on specific components within the logging subsystem.\nWhen Hydra processes a logging configuration, it accepts various dictionary parameters that define handlers, formatters, filters, and queues. In affected versions, these values—which specify class paths and factory methods—are passed directly to the underlying logging configuration machinery without verifying if the requested objects are authorized or safe for instantiation.\nTypically, Hydra utilizes an 'instantiate()' utility that incorporates a security policy to prevent arbitrary code execution by restricting which classes can be dynamically imported and invoked. However, the logging subsystem bypasses this mechanism entirely. Because dictConfig() is designed to dynamically import and instantiate objects based on strings provided in the configuration dictionary, it acts as a vector for arbitrary code execution.\nAn attacker who controls the application configuration can craft a malicious dictionary containing references to arbitrary, sensitive, or dangerous importable Python classes or factory functions. When Hydra initializes the logging system, it inadvertently triggers the instantiation of these attacker-specified objects. Because the application runs with a specific set of system privileges, the injected code inherits these permissions, potentially allowing for file system access, remote command execution, or other unauthorized system interactions.\nThe attack flow follows these steps: 1) The attacker gains influence over the application's configuration input (e.g., via config files, command-line arguments, or environment variables). 2) The attacker injects a logging configuration schema that specifies a malicious class or factory method as a handler, formatter, or filter. 3) Hydra passes this configuration to logging.config.dictConfig(). 4) The Python logging framework dynamically imports and instantiates the specified malicious class or invokes the specified factory. 5) The payload executes within the context of the application's runtime environment.\nThis vulnerability remains critical because it circumvents the 'instantiate()' protection, making traditional security controls within Hydra insufficient for protecting the logging lifecycle."
}