CVE-2026-35171: 
Python vulnerability analysis and mitigation

CVE-2026-35171 is a critical Remote Code Execution (RCE) vulnerability in Kedro, an open-source Python framework for building data pipelines, caused by unsafe use of logging.config.dictConfig() with user-controlled input. All Kedro versions prior to 1.3.0 are affected. The vulnerability was published by the Kedro maintainers on April 1, 2026, and added to the GitHub Advisory Database on April 3, 2026. It carries a CVSS v3.1 base score of 9.8 (Critical) per NVD, and 10.0 (Critical) per the vendor advisory (GitHub Advisory, Kedro Advisory).

The root cause is improper control of code generation (CWE-94) combined with deserialization of untrusted data (CWE-502). Kedro reads the logging configuration file path from the KEDRO_LOGGING_CONFIG environment variable and passes the parsed YAML content directly to Python's logging.config.dictConfig() without any validation. Python's dictConfig() schema supports a special () key that triggers arbitrary callable instantiation — effectively allowing any Python callable (including os.system or subprocess.Popen) to be invoked with attacker-controlled arguments. An attacker who can control the KEDRO_LOGGING_CONFIG environment variable or write to the referenced configuration file can craft a malicious YAML payload containing the () key to execute arbitrary system commands at application startup, requiring no authentication or user interaction (GitHub Advisory, Kedro Advisory).

Successful exploitation grants an unauthenticated remote attacker arbitrary command execution with the privileges of the Kedro application process, resulting in full confidentiality, integrity, and availability compromise. Attackers can exfiltrate sensitive data (including pipeline credentials, model artifacts, and dataset contents), modify or destroy system files, and disrupt service availability. The attack is triggered at application startup, meaning any deployment environment where the logging configuration can be influenced is at risk, and successful compromise could serve as a foothold for lateral movement within data engineering or ML infrastructure (GitHub Advisory, Kedro Advisory).

As of the time of reporting, there is no public proof-of-concept exploit and no evidence of in-the-wild exploitation (Feedly). The EPSS score is approximately 0.20% (42nd percentile), indicating a relatively low near-term exploitation probability despite the critical severity rating. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported. However, the attack vector is network-accessible, requires no privileges or user interaction, and the exploitation technique (abusing Python's dictConfig() () key) is well-documented in public Python security research, lowering the barrier for exploitation (GitHub Advisory).

1. Reconnaissance: Identify deployments running Kedro versions prior to 1.3.0, particularly those exposed to network access or where environment variables can be influenced (e.g., containerized environments, CI/CD pipelines, or cloud-based ML platforms).
2. Gain influence over environment variable or config file: Obtain the ability to set the KEDRO_LOGGING_CONFIG environment variable to a path of a controlled file, or gain write access to the existing logging configuration file referenced by the application.
3. Craft malicious YAML payload: Create a YAML logging configuration file that uses the () key to invoke an arbitrary Python callable. For example:

version: 1
formatters:
  evil:
    (): subprocess.Popen
    args:
      - ['id']

4. Trigger application startup: Cause the Kedro application to start (or restart), which will load the malicious logging configuration via logging.config.dictConfig() and execute the specified callable with the provided arguments.
5. Achieve code execution: The injected callable executes arbitrary system commands with the privileges of the Kedro process, enabling reverse shell establishment, data exfiltration, or further lateral movement (GitHub Advisory, Kedro Advisory).

• File System: Unexpected or recently modified YAML files in paths referenced by KEDRO_LOGGING_CONFIG; YAML files containing the () key in logging handler or formatter definitions; new scripts or binaries written to the filesystem by the Kedro process.
• Process: Unusual child processes spawned by the Kedro Python process (e.g., bash, sh, curl, wget, python, nc); processes executing shortly after Kedro application startup.
• Logs: Application startup logs showing errors or unexpected output from logging configuration loading; Python tracebacks referencing logging.config.dictConfig with unusual callable names.
• Environment: Presence of the KEDRO_LOGGING_CONFIG environment variable set to an unexpected or external path in process environment listings (/proc/<pid>/environ on Linux).
• Network: Unexpected outbound connections from the Kedro application host to external IPs shortly after startup, potentially indicating reverse shell or data exfiltration activity.

Upgrade to Kedro 1.3.0 or later, which introduces validation that rejects the unsafe () factory key in logging configurations before passing them to dictConfig() (GitHub Advisory). If immediate upgrade is not possible, apply the following mitigations: do not allow untrusted input to control the KEDRO_LOGGING_CONFIG environment variable; restrict write access to logging configuration files to trusted users only; avoid using externally supplied or dynamically generated logging configurations; and manually audit all logging YAML files to ensure they do not contain the () key. Note that these workarounds reduce risk but do not fully eliminate it — patching to 1.3.0 should be prioritized (Kedro Advisory).

The vulnerability was reported by a researcher credited as "Wernerina" and published by Kedro maintainer rashidakanchwala on April 1, 2026 (Kedro Advisory). Coverage appeared on The Hacker Wire, which published a dedicated article on the RCE via unsafe logging configuration (The Hacker Wire). Social media discussion was noted on Bluesky and Mastodon, with security community accounts sharing the advisory. Overall community reaction highlighted the risk of Python's dictConfig() () key as a known but underappreciated attack surface in data engineering frameworks.