ClawHub
Back to skill

Security audit

modal-gpu

Security checks for vulnerabilities and agentic risk

Overview

This is a documentation-only skill for using Modal cloud GPUs; it is purpose-aligned, but users should handle Modal tokens carefully and pin dependencies for reproducibility.

Install only if you intend to use Modal for remote GPU work. Prefer Modal's secure interactive authentication flow where possible, avoid placing real token secrets in shell history or shared logs, revoke any exposed tokens, and pin dependency versions before using these examples in production or with sensitive datasets.

A.I.G

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (2)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:34
Finding

Unpinned Third-Party Dependencies Create Supply-Chain Risk

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:34, SKILL.md:45-49, references/getting-started.md:14-18, references/getting-started.md:66-69, references/data-download.md:13-18, references/common-issues.md:47, references/common-issues.md:54-58, and references/results.md:69-74
Vulnerability Type: Unpinned third-party dependencies
Risk Level: Medium

The documentation recommends installing several packages without fixed versions or integrity hashes.

bash
pip install modal
python
image = modal.Image.debian_slim(python_version="3.11").pip_install(
    "torch",
    "einops",
    "numpy",
)

Other examples use the same pattern and additionally install huggingface_hub without a version constraint:

python
image = modal.Image.debian_slim(python_version="3.11").pip_install(
    "torch",
    "einops",
    "numpy",
    "huggingface_hub",
)

Technical Analysis

Package names without exact version constraints resolve to mutable upstream releases. Consequently, two executions of the same documented command can install different code. If an upstream account, release process, package registry, or dependency is compromised, following these instructions could introduce attacker-controlled code into the local environment or Modal image.

No typo-squatted package, untrusted package index, or currently malicious dependency was identified. The risk arises from the lack of reproducible version and integrity controls rather than evidence that the named packages are malicious.

Attack Path

  1. An attacker compromises an upstream package, its maintainer account, release pipeline, or a transitive dependency.
  2. The attacker publishes a malicious release under a package name referenced by the documentation.
  3. A user runs pip install modal or builds a Modal image using the unpinned pip_install() declarations.
  4. The package resolver selects the compromised release ...[truncated 761 chars]
Remediation
View remediation

Remediation Suggestions

  1. Pin every direct dependency to a reviewed exact version, for example modal==X.Y.Z.
  2. Maintain a lock file that records resolved transitive dependencies.
  3. Use package hashes where the installation workflow supports them, such as a hash-locked requirements file.
  4. Configure package installation to use only approved registries and prohibit unexpected extra indexes.
  5. Periodically scan dependencies for known vulnerabilities and update pins only after testing and review.
  6. Use minimal isolated build environments and avoid exposing runtime secrets during dependency installation.
  7. Document a controlled upgrade process so users do not need to install mutable latest releases.

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:35
Finding

Modal Secret Is Passed Through Command-Line Arguments

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:35, references/getting-started.md:41, and references/common-issues.md:100
Vulnerability Type: Credential exposure through command history and process arguments
Risk Level: Medium

The same credential configuration command is recommended in three locations:

bash
modal token set --token-id <id> --token-secret <secret>

Technical Analysis

If users replace the placeholders directly in the command, the Modal token secret becomes part of the shell command line. Depending on the operating system and shell configuration, it may be retained in shell history, terminal session logs, audit records, command telemetry, or process argument listings while the command is executing.

The repository does not contain a hard-coded credential and does not transmit the token to an unrelated destination. The issue is the insecure credential-entry pattern presented to users.

Attack Path

  1. A user substitutes a real Modal token ID and secret into the documented command.
  2. The shell records the completed command in its history, or the operating system exposes its arguments through process inspection or auditing.
  3. Another local user, process, support bundle, backup, or log collector obtains that record.
  4. The observer extracts the Modal token credentials.
  5. The observer authenticates to Modal using the stolen token.
  6. The attacker performs actions permitted by that token, potentially including submitting workloads, accessing associated resources, or consuming paid compute capacity.

Impact Assessment

Successful exploitation can compromise the Modal account or workspace resources accessible to the exposed token. The attacker’s effective privileges are bounded by the token’s permissions but may include workload submission, application management, access to related cloud resources, and unauthorized consumption of paid GPU capacity. Any secrets or d ...[truncated 81 chars]

Remediation
View remediation

Remediation Suggestions

  1. Prefer Modal’s interactive credential setup mechanism if it reads secrets through a hidden prompt.
  2. If supported, read the token from a protected secret manager or secure file rather than placing it directly in command-line arguments.
  3. Avoid examples that encourage users to substitute real secrets into literal shell commands.
  4. Clearly warn that secrets must not be committed to scripts, copied into tickets, or retained in shell history.
  5. Restrict credential-file permissions to the owning user and apply least-privilege scopes to tokens.
  6. Document token rotation and revocation procedures for credentials that may have been exposed.
  7. Advise affected users to remove exposed commands from history and relevant logs, while noting that deletion from one history file may not remove backups or centralized audit records.

SkillSpector

Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (1)

Missing User Warnings

Low
Category
Not specified by scanner
Confidence
89% confidence
Finding

The skill instructs users to set Modal API credentials directly on the command line without any warning about secure secret handling. This can lead to accidental exposure through shell history, screenshots, shared terminals, logs, or copied commands, especially because the skill targets cloud execution and credentialed remote infrastructure.

Content

No source excerpt is available for this finding.