{"id":"CVE-2026-106441","aliases":["EUVD-2026-93664","GHSA-c3wx-c55w-pxjq","PYSEC-2026-4221"],"status":"published","title":"Hydra logging configuration permits unsafe callable resolution","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.","severity":{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00165,"percentile":0.05855,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-94"],"published":"2026-10-06T18:53:27Z","modified":"2026-10-28T02:30:56Z","fixes":[{"ecosystem":"PyPI","package":"hydra-core","fixed_in":["1.3.6","1.4.0.dev9"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"PyPI","package":"hydra-core","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.3.6"}]}]},{"source":"ghsa","ecosystem":"PyPI","package":"hydra-core","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.4.0.dev0"},{"fixed":"1.4.0.dev9"}]}]},{"source":"osv","ecosystem":"PyPI","package":"hydra-core","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.3.6"}]}],"versions":["0.1.4","0.1.5","0.1.5rc1","0.10.0","0.11.0","0.11.0rc1","0.11.1","0.11.1rc1","0.11.2","0.11.2rc1","0.11.3","0.9.0","1.0.0","1.0.0rc1","1.0.0rc2","1.0.0rc3","1.0.0rc4","1.0.1","1.0.2","1.0.3","1.0.4","1.0.5","1.0.6","1.0.7","1.1.0","1.1.0.dev1","1.1.0.dev2","1.1.0.dev3","1.1.0.dev4","1.1.0.dev5","1.1.0.dev6","1.1.0.dev7","1.1.0rc1","1.1.1","1.1.2","1.1.2.dev0","1.2.0","1.2.0.dev1","1.2.0.dev2","1.2.0.dev3","1.2.0.dev4","1.2.0.dev5","1.3.0","1.3.0.dev0","1.3.0.dev1","1.3.1","1.3.2","1.3.3","1.3.4","1.3.5"]},{"source":"osv","ecosystem":"PyPI","package":"hydra-core","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.4.0.dev0"},{"fixed":"1.4.0.dev9"}]}],"versions":["1.4.0.dev1","1.4.0.dev3","1.4.0.dev4","1.4.0.dev5","1.4.0.dev6","1.4.0.dev8"]},{"source":"osv","ecosystem":"PyPI","package":"hydra-core","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.3.6"},{"introduced":"1.4.0.dev0"},{"fixed":"1.4.0.dev9"}]}],"versions":["0.1.4","0.1.5","0.1.5rc1","0.10.0","0.11.0","0.11.0rc1","0.11.1","0.11.1rc1","0.11.2","0.11.2rc1","0.11.3","0.9.0","1.0.0","1.0.0rc1","1.0.0rc2","1.0.0rc3","1.0.0rc4","1.0.1","1.0.2","1.0.3","1.0.4","1.0.5","1.0.6","1.0.7","1.1.0","1.1.0.dev1","1.1.0.dev2","1.1.0.dev3","1.1.0.dev4","1.1.0.dev5","1.1.0.dev6","1.1.0.dev7","1.1.0rc1","1.1.1","1.1.2","1.1.2.dev0","1.2.0","1.2.0.dev1","1.2.0.dev2","1.2.0.dev3","1.2.0.dev4","1.2.0.dev5","1.3.0","1.3.0.dev0","1.3.0.dev1","1.3.1","1.3.2","1.3.3","1.3.4","1.3.5","1.4.0.dev1","1.4.0.dev3","1.4.0.dev4","1.4.0.dev5","1.4.0.dev6","1.4.0.dev8"]}],"products":[{"vendor":"hydra-ecosystem","product":"hydra"},{"vendor":"ory","product":"hydra"}],"references":[{"url":"https://github.com/hydra-ecosystem/hydra/security/advisories/GHSA-c3wx-c55w-pxjq","tags":["x_refsource_CONFIRM","advisory","web"]},{"url":"https://github.com/hydra-ecosystem/hydra/pull/3420","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/hydra-ecosystem/hydra/commit/76bfc30ce1f3105416941dd2e3a562568e369120","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/hydra-ecosystem/hydra/commit/ff3e4dba890c29a21d8c2bb867ee87d37ccf21d0","tags":["x_refsource_MISC","fix","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-106441","tags":["advisory"]},{"url":"https://github.com/hydra-ecosystem/hydra/releases/tag/v1.3.6","tags":["web"]},{"url":"https://github.com/advisories/GHSA-c3wx-c55w-pxjq","tags":["advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/106xxx/CVE-2026-106441.json","tags":["advisory"]},{"url":"https://github.com/hydra-ecosystem/hydra","tags":["package"]},{"url":"https://pypi.org/project/hydra-core","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-106441","title":"Hydra logging configuration permits unsafe callable resolution","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.","status":"published","published":"2026-10-06T18:53:27.761Z","modified":"2026-10-07T18:49:30.024Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high","assessor":"cna"}],"cwes":["CWE-94"],"updated_at":"2026-11-02T14:20:04.463704Z"}],"euvd":[{"id":"EUVD-2026-93664","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.","status":"published","published":"2026-10-06T18:53:27Z","modified":"2026-10-07T18:49:30Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T17:27:34.353796Z"}],"ghsa":[{"id":"GHSA-c3wx-c55w-pxjq","title":"Hydra logging configuration permits unsafe callable resolution","description":"## Summary\n\nHydra 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.\n\nThis 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()`.\n\nAn 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.\n\n## Fix\n\nHydra 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.\n\nHydra 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.\n\nHydra 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 by trusted Python code. If no whitelist is supplied, Hydra warns and preserves legacy fallback behavior.\n\n## Remediation\n\nUpgrade to Hydra 1.3.6, or to Hydra 1.4.0.dev9 or later when testing the 1.4 prerelease line.\n\nOn Hydra 1.3, do not compose logging configuration from untrusted sources. On Hydra 1.4 and later, constrain custom logging targets with a narrow execution whitelist supplied by trusted Python code. The execution whitelist controls callable selection; it is not general validation of all logging settings.\n\nFor Hydra 1.4 execution-whitelist configuration, see:\n\nhttps://hydra.cc/docs/advanced/execution_whitelist/","status":"published","published":"2026-10-07T18:03:55Z","modified":"2026-10-07T18:03:56Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high"}],"cwes":["CWE-94"],"updated_at":"2026-11-02T14:41:28.013673Z"}],"nvd":[{"id":"CVE-2026-106441","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.","status":"published","published":"2026-10-06T19:18:13.02Z","modified":"2026-10-07T19:17:32.15Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high","assessor":"secondary"}],"cwes":["CWE-94"],"updated_at":"2026-11-02T14:12:54.809359Z"}],"osv":[{"id":"CVE-2026-106441","title":"Hydra logging configuration permits unsafe callable resolution","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.","status":"published","published":"2026-10-06T18:53:27.761Z","modified":"2026-10-28T02:30:56.931479263Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high"}],"cwes":["CWE-94"],"updated_at":"2026-11-02T15:44:54.583213Z"},{"id":"GHSA-c3wx-c55w-pxjq","title":"Hydra logging configuration permits unsafe callable resolution","description":"## Summary\n\nHydra 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.\n\nThis 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()`.\n\nAn 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.\n\n## Fix\n\nHydra 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.\n\nHydra 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.\n\nHydra 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 by trusted Python code. If no whitelist is supplied, Hydra warns and preserves legacy fallback behavior.\n\n## Remediation\n\nUpgrade to Hydra 1.3.6, or to Hydra 1.4.0.dev9 or later when testing the 1.4 prerelease line.\n\nOn Hydra 1.3, do not compose logging configuration from untrusted sources. On Hydra 1.4 and later, constrain custom logging targets with a narrow execution whitelist supplied by trusted Python code. The execution whitelist controls callable selection; it is not general validation of all logging settings.\n\nFor Hydra 1.4 execution-whitelist configuration, see:\n\nhttps://hydra.cc/docs/advanced/execution_whitelist/","status":"published","published":"2026-10-07T18:03:55Z","modified":"2026-10-15T14:55:50.399421541Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high"}],"cwes":["CWE-94"],"updated_at":"2026-11-02T15:46:44.571161Z"},{"id":"PYSEC-2026-4221","title":"Hydra logging configuration permits unsafe callable resolution","description":"## Summary\n\nHydra 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.\n\nThis 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()`.\n\nAn 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.\n\n## Fix\n\nHydra 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.\n\nHydra 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.\n\nHydra 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 by trusted Python code. If no whitelist is supplied, Hydra warns and preserves legacy fallback behavior.\n\n## Remediation\n\nUpgrade to Hydra 1.3.6, or to Hydra 1.4.0.dev9 or later when testing the 1.4 prerelease line.\n\nOn Hydra 1.3, do not compose logging configuration from untrusted sources. On Hydra 1.4 and later, constrain custom logging targets with a narrow execution whitelist supplied by trusted Python code. The execution whitelist controls callable selection; it is not general validation of all logging settings.\n\nFor Hydra 1.4 execution-whitelist configuration, see:\n\nhttps://hydra.cc/docs/advanced/execution_whitelist/","status":"published","published":"2026-10-15T10:22:48.072402Z","modified":"2026-10-15T14:45:04.402255647Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:52:57.671918Z"}]}}