Summary
Hydra passes attacker-controlled logging configuration to Python's logging configuration system without applying Hydra's target restrictions to several classes and factory values. If an attacker can control this configuration, they may cause an importable class or factory to run with the application's privileges.
Hydra passes attacker-controlled logging configuration to Python's logging configuration system without applying Hydra's target restrictions to several classes and factory values. If an attacker can control this configuration, they may cause an importable class or factory to run with the application's privileges.
Affected context
The issue occurs in Hydra deployments that accept or process logging configuration controlled by an untrusted or insufficiently trusted party. The risk is present when logging configuration reaches logging.config.dictConfig() without equivalent restrictions on handler classes, formatters, filters, queues, listeners, or their factories.
The issue occurs in Hydra deployments that accept or process logging configuration controlled by an untrusted or insufficiently trusted party. The risk is present when logging configuration reaches logging.config.dictConfig() without equivalent restrictions on handler classes, formatters, filters, queues, listeners, or their factories.
Exploit preconditions
- Attack surface: Hydra's logging configuration processing path
- Required access: Ability to create, modify, or supply configuration consumed by the application
- Trigger point: Application initialization or reconfiguration when Python logging configuration is applied
- Why exploitation is possible: Importable classes and factory callbacks can be selected through logging configuration and invoked with application privileges without passing through Hydra's protected instantiation policy
- Attack surface: Hydra's logging configuration processing path
- Required access: Ability to create, modify, or supply configuration consumed by the application
- Trigger point: Application initialization or reconfiguration when Python logging configuration is applied
- Why exploitation is possible: Importable classes and factory callbacks can be selected through logging configuration and invoked with application privileges without passing through Hydra's protected instantiation policy
Why this happens
The underlying bug is an incomplete enforcement of a security policy across an indirect object-construction path. Hydra restricts some target instantiation through its own APIs, but the logging path delegates configuration to logging.config.dictConfig() without applying comparable controls to class and factory fields. This maps to CWE-94: Improper Control of Generation of Code, because attacker-influenced configuration can cause selected executable components to be imported and invoked.
The underlying bug is an incomplete enforcement of a security policy across an indirect object-construction path. Hydra restricts some target instantiation through its own APIs, but the logging path delegates configuration to logging.config.dictConfig() without applying comparable controls to class and factory fields. This maps to CWE-94: Improper Control of Generation of Code, because attacker-influenced configuration can cause selected executable components to be imported and invoked.
Potential impact
- An attacker may execute arbitrary code with the application's privileges
- Application secrets and configuration data could be exposed
- The application may be modified, disrupted, or used for lateral movement
- Logging behavior could be altered to conceal malicious activity
- Hosts or workloads running the application could be compromised
- An attacker may execute arbitrary code with the application's privileges
- Application secrets and configuration data could be exposed
- The application may be modified, disrupted, or used for lateral movement
- Logging behavior could be altered to conceal malicious activity
- Hosts or workloads running the application could be compromised
General mitigation guidance
Mitigation generally focuses on reducing trust in logging configuration and ensuring that every dynamic class or factory resolution path applies an explicit security policy.
Common defensive patterns include:
- Accepting logging configuration only from trusted, integrity-protected sources
- Allowing only an explicit, minimal set of approved handlers, formatters, filters, queues, listeners, and factories
- Avoiding arbitrary import and factory resolution from user-controlled configuration
- Validating configuration against a strict schema before invoking logging configuration APIs
- Separating application configuration privileges from runtime identities where practical
- Running applications with least privilege and limiting access to sensitive resources
Mitigation generally focuses on reducing trust in logging configuration and ensuring that every dynamic class or factory resolution path applies an explicit security policy.
Common defensive patterns include:
- Accepting logging configuration only from trusted, integrity-protected sources
- Allowing only an explicit, minimal set of approved handlers, formatters, filters, queues, listeners, and factories
- Avoiding arbitrary import and factory resolution from user-controlled configuration
- Validating configuration against a strict schema before invoking logging configuration APIs
- Separating application configuration privileges from runtime identities where practical
- Running applications with least privilege and limiting access to sensitive resources
How teams detect issues like this
Organizations can look for this weakness through:
- Static analysis rules identifying direct use of
logging.config.dictConfig()with externally influenced input - Code review checks for unrestricted
class,()factory, handler, formatter, filter, queue, or listener values - Data-flow analysis tracing configuration sources to dynamic import or object-construction paths
- Runtime monitoring for unexpected module imports or process activity during logging initialization
- Policy enforcement requiring allowlists and integrity checks for operational configuration
- Automated security review tools that flag dynamic configuration and unsafe factory resolution
Organizations can look for this weakness through:
- Static analysis rules identifying direct use of
logging.config.dictConfig()with externally influenced input - Code review checks for unrestricted
class,()factory, handler, formatter, filter, queue, or listener values - Data-flow analysis tracing configuration sources to dynamic import or object-construction paths
- Runtime monitoring for unexpected module imports or process activity during logging initialization
- Policy enforcement requiring allowlists and integrity checks for operational configuration
- Automated security review tools that flag dynamic configuration and unsafe factory resolution
