Back to skill

Security audit

plaid

Security checks for vulnerabilities and agentic risk

Overview

The skill is coherent, but it routes Plaid financial credentials and account data through a third-party CLI with weakly documented credential and token protections.

Review the upstream plaid-cli source before installing, prefer sandbox or narrowly scoped Plaid credentials, avoid plaintext config where possible, restrict ~/.plaid-cli permissions, do not print tokens into transcripts or logs, and replace the /tmp cron example with a private per-user state directory if monitoring is used.

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 (3)

T08 · Insecure Dependencies

Error
Location
SKILL.md:5
Finding
Unreviewed Third-Party CLI Handles Plaid Credentials and Financial Data<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 5 and 14 **Vulnerability Type**: Third-party dependency and supply-chain exposure **Risk Level**: High ### Vulnerable Code ```yaml metadata: {"clawdis":{"emoji":"💳","requires":{"bins":["plaid-cli"]},"install":[{"id":"go","kind":"go","module":"github.com/jverdi/plaid-cli@0.0.2","bins":["plaid-cli"],"label":"Install plaid-cli (go)"}]}} ``` ```text Install - `go install github.com/jverdi/plaid-cli@0.0.2` ``` ### Technical Analysis The Skill instructs users to download, compile, and execute a third-party Go module from a personal GitHub namespace. The dependency is version-pinned, which limits unexpected upgrades, but the project contains neither the dependency source nor a checksum or provenance policy through which auditors can verify the executable's behavior. This binary receives highly sensitive Plaid client secrets and access tokens and processes financial account, balance, and transaction information. It also requires network access for the declared functionality. Consequently, a malicious or compromised dependency would have both access to sensitive data and an available exfiltration channel. The audit did not establish that the named package is malicious. The vulnerability is the trust and supply-chain boundary created by automatically installing an unreviewed external executable for a security-sensitive role. ### Attack Path 1. An attacker compromises the upstream repository, release process, module source, or maintainer account associated with `github.com/jverdi/plaid-cli`. 2. A user follows the Skill instructions and runs `go install`. 3. The resulting executable runs under the user's account. 4. The user exports Plaid credentials or stores them in the CLI configuration and invokes the binary. 5. The compromised executable reads the credentials, tokens, account records, balances, and transactions that it legitimately handles. 6. It transmits those assets to an attacker-con ...[truncated 627 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Review and vendor the exact dependency source used by the Skill. 2. Record and verify immutable source or artifact hashes in addition to pinning a version. 3. Prefer an official, actively maintained Plaid client or a dependency with established provenance and security maintenance. 4. Generate reproducible builds and publish signed artifacts or attestations. 5. Run the CLI in an isolated environment with access only to the required configuration and data directories. 6. Restrict outbound network access to documented Plaid API and account-linking endpoints where operationally possible. 7. Use narrowly scoped, environment-specific credentials and establish rapid credential and token rotation procedures. 8. Re-audit the dependency before changing its version. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:17
Finding
Plaintext Plaid Credentials and Tokens Lack Documented Filesystem Protection<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 17–25 and 54 **Vulnerability Type**: Insecure storage and disclosure of sensitive credentials **Risk Level**: High ### Vulnerable Code ```text Setup - Export `PLAID_CLIENT_ID`, `PLAID_SECRET`, and `PLAID_ENVIRONMENT` (sandbox or production). - Optional: `PLAID_LANGUAGE` (en, fr, es, nl), `PLAID_COUNTRIES` (US, CA, GB, IE, ES, FR, NL). - Optional config file: `~/.plaid-cli/config.toml`. ```toml [plaid] client_id = "..." secret = "..." environment = "sandbox" ``` - Data directory: `~/.plaid-cli` (stores tokens and aliases). ``` ```text - Avoid `plaid-cli tokens` unless explicitly requested; it prints access tokens. ``` ### Technical Analysis The documented configuration stores the Plaid client secret in a plaintext TOML file. The data directory also stores access tokens, but the Skill does not require restrictive directory or file permissions, encryption at rest, an operating-system credential manager, or checks against symbolic links and unintended ownership. The Skill further documents a command that prints access tokens. Although it warns against using that command unless requested, printed tokens could still be captured in terminal history, agent transcripts, CI logs, shell redirection, screen recordings, or monitoring systems. Environment variables are preferable to hardcoding secrets in commands, but they remain accessible to the invoked process and may be exposed through process inspection or diagnostic capture depending on the platform. The main avoidable issue is the suggested plaintext configuration and unspecified protection of the token directory. ### Attack Path 1. A user follows the optional configuration example and writes a Plaid client secret to `~/.plaid-cli/config.toml`. 2. The CLI stores linked-account access tokens under `~/.plaid-cli`. 3. The files are created with permissions influenced by the user's environment because the Skill does not enforce se ...[truncated 1089 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Store Plaid secrets and access tokens in an operating-system credential manager or dedicated secrets service rather than a plaintext TOML file. 2. If file storage is unavoidable, create `~/.plaid-cli` with mode `0700` and credential files with mode `0600`. 3. Validate that the credential directory and files are owned by the current user and are not symbolic links before reading or writing them. 4. Separate aliases and non-sensitive settings from secrets so ordinary configuration can be backed up without copying credentials. 5. Redact tokens from all normal command output and require an explicit, interactive confirmation before revealing a complete token. 6. Warn users not to place token output in logs, transcripts, tickets, or shell history. 7. Document credential revocation, token rotation, and secure deletion procedures. 8. Prefer short-lived or narrowly scoped credentials where supported and keep sandbox and production secrets strictly separated. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:43
Finding
Predictable Shared Temporary Files Permit Symlink and State-Tampering Attacks<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 43–51 **Vulnerability Type**: Unsafe temporary-file handling **Risk Level**: Medium ### Vulnerable Code ```bash state=/tmp/plaid.txids next=/tmp/plaid.txids.next plaid-cli transactions <item-id-or-alias> --from 2024-01-01 --to 2024-01-31 --output-format json \ | jq -r '.[].transaction_id' | sort > "$next" if [ -f "$state" ]; then comm -13 "$state" "$next"; fi mv "$next" "$state" ``` ### Technical Analysis The monitoring example uses fixed, predictable filenames in the globally shared `/tmp` directory. The shell redirection to `"$next"` follows symbolic links and truncates an existing destination before writing. No private directory is created, exclusive file creation is not used, ownership is not checked, and concurrent invocations are not locked. The risk increases because the Skill recommends cron scheduling. An attacker who can predict execution times may pre-create one of the paths, substitute a symbolic link, race the script, or alter the stored transaction-ID list. Platform protections such as sticky-directory semantics or protected-symlink settings may reduce some variants, but the example cannot rely on those controls being present or correctly configured. ### Attack Path 1. A local attacker identifies that the user periodically runs the documented monitoring command. 2. Before execution, the attacker creates `/tmp/plaid.txids.next` as a symbolic link to a file writable by the victim, or creates and manipulates the predictable state files. 3. The scheduled shell opens `"$next"` through output redirection. 4. If symbolic-link traversal is permitted, the linked target is truncated and overwritten with transaction IDs under the victim's privileges. 5. The final `mv` can replace or corrupt the expected state file. 6. Alternatively, the attacker injects or removes transaction IDs from the state, causing false alerts or suppressing detection of new transactions. ### Impact Asses ...[truncated 492 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Store persistent state in a private per-user directory such as `${XDG_STATE_HOME:-$HOME/.local/state}/plaid-cli`, created with mode `0700`. 2. Use `mktemp` to create a unique temporary file inside that protected directory. 3. Register a shell `trap` to remove temporary files on exit or interruption. 4. Verify directory ownership and reject symbolic links or unexpected file types. 5. Set a restrictive `umask`, such as `077`, before creating files. 6. Write the complete new state to a uniquely named file and atomically rename it only after successful processing. 7. Use a lock file or `flock` to prevent concurrent cron executions from corrupting state. 8. Avoid placing financial identifiers in a globally readable temporary directory. ]]>
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • 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

Static analysis

No suspicious patterns detected.