Back to skill

Security audit

OpenPayment

Security checks for vulnerabilities and agentic risk

Overview

This skill does what it says, but it asks agents to create real crypto payment links through Bash with user-provided fields and has under-scoped proxy behavior.

Install only if you trust the OpenPayment npm package and are comfortable creating production Base USDC payment links from agent-collected inputs. Before use, confirm every amount, wallet address, network, description, and any PROXY resource URL, and avoid letting the agent interpolate untrusted text directly into Bash commands.

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:28
Finding
Unpinned Global Installation of a Third-Party npm Package<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:28-34` **Vulnerability Type**: Unpinned third-party dependency installed globally **Risk Level**: Medium ### Vulnerable Code ```markdown ## Install ```bash npm i -g openpayment ``` ``` ### Technical Analysis The skill instructs users or agents to install the `openpayment` npm package globally without specifying an exact version or verifying package integrity. Consequently, installation resolves to whichever package version the npm registry currently exposes under that name. Because the dependency's source is not included in the audited project, its installation scripts, transitive dependencies, and runtime behavior cannot be verified from this artifact. npm packages may execute lifecycle scripts during installation. Global installation also exposes the package across the user's environment and may execute installation logic with all privileges available to the npm process. This is a supply-chain weakness rather than evidence that the current `openpayment` package is malicious. ### Attack Path 1. An attacker compromises the upstream package, a maintainer account, or a relevant transitive dependency. 2. The attacker publishes a malicious package version under the expected package name. 3. A user or agent follows the skill instructions and runs `npm i -g openpayment`. 4. npm retrieves the latest matching version without enforcing a reviewed version or integrity value. 5. Malicious lifecycle scripts or package code execute with the privileges of the installing user. 6. The malicious package can access data and resources available to that account and remains available as a globally installed command until removed. ### Impact Assessment Successful exploitation could execute arbitrary code with the privileges of the account performing installation. Depending on that account's permissions, the affected scope could include user files, environment variables, agent credentials, network-accessible ...[truncated 291 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Pin the dependency to an exact reviewed version rather than installing the latest release: ```bash npm install --global openpayment@<reviewed-exact-version> ``` 2. Verify the package's provenance and integrity before installation, including the publisher, repository, release history, and npm integrity metadata. 3. Maintain a lockfile or equivalent controlled dependency manifest where the execution environment permits it. 4. Prefer a project-local installation over a global installation to reduce system-wide exposure. 5. Execute the package in an isolated, least-privileged environment with restricted filesystem, credential, and network access. 6. Disable npm lifecycle scripts where compatible with the package: ```bash npm install --ignore-scripts openpayment@<reviewed-exact-version> ``` 7. Review the pinned package and its transitive dependencies before approving upgrades. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:37
Finding
Shell Command Injection Through User-Controlled CLI Arguments<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:37-46, 200-209` **Vulnerability Type**: Shell command injection **Risk Level**: High ### Vulnerable Code ```bash openpayment create \ --type "<PAYMENT_TYPE>" \ --price "<AMOUNT>" \ --payTo "<EVM_ADDRESS>" \ --network "<NETWORK>" \ [--resourceUrl "<HTTPS_URL_FOR_PROXY>"] \ --description "<DESCRIPTION>" ``` ```markdown ## Workflow for Handling User Requests The first time the skill runs, explain to the user what payment types and networks are allowed. 1. **Identify missing info** you need: amount (`--price`), receiver wallet address (`--payTo`). If `--type=PROXY`, also require `--resourceUrl`. 2. **Infer defaults**: type defaults to `SINGLE_USE`, network defaults to `eip155:8453` (Base Mainnet). 3. **Confirm info** with the user before creating. 4. **Run the command** using the bash tool. 5. **Present the payment URL** clearly to the user so they can share it. ``` ### Technical Analysis The workflow directs the agent to collect values from a user and interpolate them into a command executed through Bash. User-controlled values include the description and, for proxy payments, the resource URL. Surrounding input with double quotes does not make arbitrary data safe for shell evaluation. Bash still evaluates command substitutions such as `$(command)` and backtick expressions inside double-quoted strings. Shell parsing and expansion happen before the `openpayment` process receives its arguments. The document states that the CLI validates fields before making an API call, but CLI validation cannot prevent this issue because injected shell expressions execute before the CLI starts. The documented maximum description length and HTTPS URL checks likewise provide no protection if they are implemented only inside the CLI. For example, if a raw description containing `$(attacker_command)` is inserted into the template and the resulting command is executed by Bash, Bash evaluates `attacker_ ...[truncated 1606 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Do not construct a shell command by concatenating or interpolating user-controlled strings. 2. Invoke the executable through a shell-free process API that accepts an argument array, conceptually: ```text executable: openpayment arguments: - create - --type - validatedType - --price - validatedPrice - --payTo - validatedAddress - --network - validatedNetwork - --description - rawDescriptionAsOneArgument ``` 3. Validate all values before process invocation: - Restrict type and network to documented allowlists. - Validate the amount as a bounded positive decimal. - require the wallet address to match `0x` followed by exactly 40 hexadecimal characters. - Enforce the description's length limit. - Parse proxy URLs with a URL parser, require HTTPS, and consider restricting private, loopback, link-local, and metadata-service destinations. 4. If a Bash tool is unavoidable, pass data as positional parameters to a fixed script rather than embedding it in executable command text. Use robust shell escaping implemented by a trusted library and never rely on double quotes alone. 5. Update the workflow to explicitly prohibit direct interpolation and require confirmation to display the validated, structured parameters rather than a shell-rendered command. 6. Add regression tests using descriptions and URLs containing `$()`, backticks, quotes, semicolons, newlines, glob characters, and leading hyphens. ]]>
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (3)

Vague Triggers

Medium
Confidence
96% confidence
Finding
The trigger guidance is very broad and includes generic phrases like creating a payment link or accepting USDC, which can cause the skill to activate in contexts where the user did not specifically intend to use this tool. In an agent environment, over-triggering can route ordinary payment-related conversations into execution paths that create real crypto payment requests on mainnet, increasing the chance of mistaken or unauthorized actions.

Whitespace Padding

Medium
Category
Prompt Injection
Content
## Payment Types

| Type         | When to use                                                                                 |
| ------------ | ------------------------------------------------------------------------------------------- |
| `SINGLE_USE` | One-time payment with fixed price (e.g., a specific order, invoice)                         |
| `MULTI_USE`  | Fixed price, can be paid multiple times (e.g., recurring product)                           |
Confidence
70% confidence
Finding
Large whitespace padding was detected (a block of blank lines or a long run of spaces). This can push injected instructions below or to the right of the visible area so a human reviewer never sees them while the agent still reads them. Manual review of the hidden content is recommended.

Context-Inappropriate Capability

Medium
Confidence
90% confidence
Finding
The skill explicitly supports `PROXY` payment links that invoke a private upstream API after settlement, which extends behavior beyond simple payment-link generation into triggering server-side actions. That increases risk because an agent could be induced to create links that cause real backend effects against user-supplied endpoints, potentially enabling SSRF-like abuse, unintended API invocation, or creation of payment-gated actions without sufficient review.

Static analysis

No suspicious patterns detected.