CVE-2026-35167: 
Python vulnerability analysis and mitigation

CVE-2026-35167 is a path traversal vulnerability in Kedro, a production-ready data science toolbox maintained under the Linux Foundation. The flaw exists in the _get_versioned_path() method within kedro/io/core.py, which constructs filesystem paths by directly interpolating user-supplied version strings without sanitization, allowing traversal sequences such as ../ to escape the intended versioned dataset directory. All Kedro versions prior to 1.3.0 (pip package) are affected. The advisory was published on April 1, 2026, and the CVE was assigned on April 6, 2026. The CVSS v3.1 base score is 7.1 (High) per the GitHub Advisory Database (Github Advisory, Kedro Security Advisory).

The root cause is CWE-22 (Improper Limitation of a Pathname to a Restricted Directory — 'Path Traversal'). The _get_versioned_path() method in kedro/io/core.py directly interpolates user-controlled version strings into filesystem path construction without stripping or validating traversal sequences. This vulnerability is reachable through at least three entry points: catalog.load(..., version=...), DataCatalog.from_config(..., load_versions=...), and the CLI via kedro run --load-versions=dataset:../../../secrets. An attacker with low privileges who can influence the version string can supply payloads such as ../../../secrets to force Kedro to resolve paths outside the intended versioned dataset directory. The fix, implemented in pull request #5442, added string-level checks to validate that version strings do not contain unsafe path components (Github Advisory, Fix PR).

Successful exploitation allows a low-privileged attacker to read arbitrary files outside the intended dataset directory, enabling unauthorized access to sensitive data such as credentials, configuration files, or secrets stored on the filesystem. In multi-tenant or shared Kedro environments, this can result in cross-tenant data access, where one user reads another tenant's data. Additionally, an attacker may poison datasets by causing Kedro to load malicious files in place of legitimate versioned data, compromising data integrity. Availability is not impacted, but both confidentiality and integrity are at high and low risk respectively (Github Advisory, Kedro Security Advisory).

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation at this time (Github Advisory). The EPSS score is approximately 0.022% (6th percentile), indicating a low near-term probability of exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires low privileges (the ability to influence a version string passed to Kedro's data catalog or CLI), making it accessible to any authenticated user of a shared Kedro environment.

1. Identify a target Kedro deployment: Locate a Kedro instance (version < 1.3.0) where the attacker has low-privilege access — for example, the ability to invoke kedro run or call catalog.load() with a custom version string.
2. Craft a malicious version string: Construct a path traversal payload such as ../../../etc/passwd or ../../../secrets that, when interpolated into the versioned path, resolves to a sensitive file outside the dataset directory.
3. Inject via CLI entry point: Execute kedro run --load-versions=dataset:../../../secrets to trigger _get_versioned_path() with the unsanitized version string.
4. Alternatively, inject via Python API: Call catalog.load('dataset_name', version='../../../secrets') or pass the traversal string through DataCatalog.from_config(..., load_versions={'dataset_name': '../../../secrets'}) in a script or notebook.
5. Retrieve the target file: Kedro resolves the traversed path and loads the file contents as if it were a versioned dataset artifact, returning the sensitive file data to the attacker (Github Advisory, Kedro Security Advisory).

• Logs: Kedro application logs or CLI output showing version strings containing .., /, or absolute paths (e.g., ../../../secrets, /etc/passwd) passed to catalog.load(), DataCatalog.from_config(), or kedro run --load-versions.
• File System: Unexpected access timestamps on sensitive files (e.g., /etc/passwd, credential files, .env files) that coincide with Kedro pipeline execution times.
• Process: Kedro process (kedro run) invocations with --load-versions arguments containing path traversal sequences visible in process audit logs (e.g., auditd, syslog).
• Network: In shared/cloud environments, unusual data egress following Kedro pipeline runs that accessed files outside the expected dataset directories.

Upgrade Kedro to version 1.3.0 or later, which includes validation checks in _get_versioned_path() and the CLI argument parser to reject version strings containing .. segments, path separators, or absolute paths (Kedro Security Advisory, Fix PR). As a temporary workaround for environments that cannot immediately upgrade, validate all version strings before passing them to DataCatalog or the CLI, ensuring they do not contain .., /, \, or begin with an absolute path. In shared or multi-tenant environments, restrict who can supply version strings to Kedro pipelines until the patch is applied.

The vulnerability was reported and fixed internally by the Kedro team (contributor ravi-kumar-pilla) with a rapid turnaround — the fix PR (#5442) was merged on March 10, 2026, and the advisory was published April 1, 2026. Maintainer merelcht confirmed the fix worked as expected across multiple entry points including the CLI (Fix PR). A Bluesky post from cyberhub.blog noted the advisory in early May 2026, indicating minor community awareness. No significant media coverage or broader security community debate has been observed.