Affected: Homebrew: dvc

## Summary

Hydra passed its Python logging configuration to `logging.config.dictConfig()`. Python's logging configurator can resolve and invoke importable classes and factories named by configuration, including handler `class` values and formatter, filter, handler, queue, and listener `()` factories.

This logging path was not mediated by Hydra's target policy. In versions that already protected `instantiate()`, logging resolution bypassed those controls because it did not use `instantiate()`.

An attacker who can control a Hydra logging configuration can use a custom class or factory to execute code with the application's privileges when Hydra configures logging.

## Fix

Hydra now applies its target policy to callable resolution and invocation in Hydra-configured Python logging. It authorizes custom factories, handlers, formatters, filters, queues, listeners, aliases, discovery results, and callable results before they can be used.

Hydra 1.3.6 uses the hardened blacklist. The Hydra 1.3 blacklist is a best-effort, defense-in-depth measure. It is not a complete security boundary and does not make untrusted logging configuration safe.

Hydra 1.4.0.dev9 introduces the execution whitelist as the recommended primary boundary, with the blacklist retained as a deprecated compatibility fallback. When an execution whitelist is supplied, Hydra automatically permits targets used by its built-in logging configurations, while custom logging integrations must be explicitly authorized b…

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.

Affected: PyPI: hydra-core

## Summary

Hydra passed its Python logging configuration to `logging.config.dictConfig()`. Python's logging configurator can resolve and invoke importable classes and factories named by configuration, including handler `class` values and formatter, filter, handler, queue, and listener `()` factories.

This logging path was not mediated by Hydra's target policy. In versions that already protected `instantiate()`, logging resolution bypassed those controls because it did not use `instantiate()`.

An attacker who can control a Hydra logging configuration can use a custom class or factory to execute code with the application's privileges when Hydra configures logging.

## Fix

Hydra now applies its target policy to callable resolution and invocation in Hydra-configured Python logging. It authorizes custom factories, handlers, formatters, filters, queues, listeners, aliases, discovery results, and callable results before they can be used.

Hydra 1.3.6 uses the hardened blacklist. The Hydra 1.3 blacklist is a best-effort, defense-in-depth measure. It is not a complete security boundary and does not make untrusted logging configuration safe.

Hydra 1.4.0.dev9 introduces the execution whitelist as the recommended primary boundary, with the blacklist retained as a deprecated compatibility fallback. When an execution whitelist is supplied, Hydra automatically permits targets used by its built-in logging configurations, while custom logging integrations must be explicitly authorized b…

libxml2: Stack Buffer Overflow in xmllint Interactive Shell Command Handling sqlite: SQLite: Arbitrary code execution via crafted FTS5 full-text search data sqlite: SQLite: Arbitrary code execution and crash via heap-based buffer overflow in FTS5 python: cpython: CPython: tarfile extraction filter bypass allows escaping the destination directory pip: pip: Arbitrary file installation via malicious package indexes GDBusServer: glib2: GDBusServer pre-authentication DoS via unbounded SASL line buffering xdgmime: heap-based buffer overflow in _xdg_mime_magic_parse_magic_line() in xdgmimemagic.c urllib3: urllib3: Information disclosure via cross-origin redirects forwarding sensitive headers urllib3: urllib3: Denial of Service due to excessive HTTP response decompression vim: Vim: Arbitrary Code Execution via crafted directory names vim: Vim: Arbitrary code execution via crafted step-definition patterns oauthlib: oauthlib: Unsafe JSONP callback injection in RevocationEndpoint allows arbitrary JavaScript response generation oauthlib: oauthlib: Timing attack vulnerability in PKCE code_verifier/code_challenge comparison allows authorization code recovery vim: Vim: Arbitrary code execution via Python omni-completion acl: Symlink traversal privilege escalation via libacl functions linux-pam: Plaintext password recovery via timing discrepancy in pam_userdb module vim: Vim: Out-of-bounds Write in Spell File Word Count vim: Vim: Denial of Service via stack out-of-bounds write in spell_soun…