Impact
This is a critical Remote Code Execution (RCE) vulnerability caused by unsafe use of logging.config.dictConfig() with user-controlled input.
Kedro allows the logging configuration file path to be set via the KEDROLOGGINGCONFIG environment variable and loads it without validation. The logging configuration schema supports the special () key, which enables arbitrary callable instantiation. An attacker can exploit this to execute arbitrary system commands during application startup.
---
Patches
The vulnerability is fixed by introducing validation that rejects the unsafe () factory key in logging configurations before passing them to dictConfig().
Fixed in - Kedro 1.3.0
Users should upgrade to this version as soon as possible.
---
Workarounds
If upgrading is not immediately possible:
- Do not allow untrusted input to control the KEDROLOGGINGCONFIG environment variable - Restrict write access to logging configuration files - Avoid using externally supplied or dynamically generated logging configs - Manually validate logging YAML to ensure it does not contain the () key
These mitigations reduce risk but do not fully eliminate it.
Impact The getversionedpath() method in kedro/io/core.py constructs filesystem paths by directly interpolating user-supplied version strings without sanitization. Because version strings are used as path components, traversal sequences such as ../ are preserved and can escape the intended versioned dataset directory. This is reachable through multiple entry points: catalog.load(..., version=...), DataCatalog.fromconfig(..., loadversions=...), and the CLI via kedro run --load-versions=dataset:../../../secrets. An attacker who can influence the version string can force Kedro to load files from outside the intended version directory, enabling unauthorized file reads, data poisoning, or cross-tenant data access in shared environments.
Patches Yes. Fixed in kedro version 1.3.0. Users should upgrade to kedro >= 1.3.0.
Workarounds Validate version strings before passing them to DataCatalog or the CLI, ensuring they do not contain .. segments, path separators, or absolute paths.
A vulnerability in Kedro version 1.2.0 allows an attacker to exploit path traversal by providing a crafted version string. The getversionedpath() method in kedro/io/core.py directly interpolates user-supplied version strings into filesystem paths without sanitization. This enables an attacker to escape the intended versioned dataset directory and access files outside the expected path. The issue is also reachable through the CLI via the --load-versions parameter, as splitloadversions() in kedro/framework/cli/utils.py does not validate the version string. This vulnerability can lead to unauthorized file reads, data poisoning, cross-project or cross-tenant data access, and broader downstream impacts in environments where Kedro is used with automation or orchestration layers.