PayLobster

• Outcome: Review
• Latest audit: Sep 10, 2026 · 4:12 PM UTC
• Version: 4.6.0

Overview

This payment skill is mostly coherent, but it asks agents to handle real wallet authority and financial transfers with insufficient safety boundaries around confirmations, private keys, and package execution.

Review this carefully before installing. Use only low-value dedicated wallets, prefer hosted or hardware/TEE-backed signing over raw private keys, require manual confirmation for every transfer, swap, bridge, subscription, fiat ramp, or escrow release, pin and review any npm packages before running them, and never place real private keys or merchant secrets in chat, shell history, logs, or client-side code.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (2)

T08 · Insecure Dependencies

Error

• Location: SKILL.md:464
• Finding: Unpinned Third-Party Packages Execute with Wallet Signing Authority## Vulnerability Details **File Location**: `SKILL.md`, lines 464-470 and 690-699 **Vulnerability Type**: Supply-chain exposure through unpinned executable dependencies **Risk Level**: High ### Vulnerable Code ```bash # SDK npm install pay-lobster viem # CLI npm install -g @paylobster/cli # Self-hosted MCP server npm install @paylobster/mcp-server ``` ```json { "mcpServers": { "paylobster": { "command": "npx", "args": ["@paylobster/mcp-server"], "env": { "PAYLOBSTER_PRIVATE_KEY": "0x...", "PAYLOBSTER_NETWORK": "mainnet" } } } } ``` ### Technical Analysis The installation and execution commands do not pin immutable package versions. In particular, `npx` can resolve and execute a package version from the npm registry at runtime. The document does not require a lockfile, package-integrity verification, trusted artifact hash, or source review. This becomes security-critical because the MCP server is explicitly launched with `PAYLOBSTER_PRIVATE_KEY` in its environment. Any code executed by that package runs with access to the process environment and can read the wallet key. It can also communicate over the network, invoke signing operations, or submit transactions. A package registry compromise, compromised maintainer account, malicious update, or dependency-level supply-chain compromise could therefore turn the documented installation path into wallet compromise. No evidence establishes that the named packages are currently malicious. The vulnerability is the unsafe trust and execution model applied to mutable third-party dependencies that receive sensitive wallet authority. ### Attack Path 1. An attacker compromises the npm package, one of its transitive dependencies, or a maintainer publishing account. 2. The attacker publishes a malicious version under the existing package name. 3. A user follows the documented unpinned `npm install` ...[truncated 1304 chars]
• Remediation: ## Remediation Suggestions 1. Pin exact package versions in all installation and execution examples, including every `npx` invocation: ```bash npm install pay-lobster@4.6.0 viem@EXACT_VERSION npm install -g @paylobster/cli@4.6.0 npm install @paylobster/mcp-server@1.5.0 npx --yes @paylobster/mcp-server@1.5.0 ``` 2. Commit and enforce a lockfile with integrity metadata. Use `npm ci` rather than mutable production installation workflows. 3. Verify package provenance, signatures, registry origin, and integrity hashes before execution. 4. Review the package and its transitive dependencies before granting access to wallet credentials. 5. Do not provide a raw private key to the MCP process. Prefer a hardware wallet, TEE-backed signer, remote signer, or narrowly scoped signing service. 6. Use a dedicated low-value wallet with explicit per-transaction and daily spending limits. 7. Restrict the process's filesystem and network access through sandboxing or container isolation. 8. Monitor package updates and on-chain activity, and provide an immediate key-rotation and permission-revocation procedure.

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:583
• Finding: Wallet Private Key Exposed Through Command-Line Arguments## Vulnerability Details **File Location**: `SKILL.md`, line 583 **Vulnerability Type**: Sensitive credential exposure through process arguments and shell history **Risk Level**: High ### Vulnerable Code ```bash # Authenticate paylobster auth --private-key 0x... ``` ### Technical Analysis The documented authentication pattern instructs users to provide a wallet private key directly as a command-line argument. Command-line secrets can be retained or exposed through several operating-system and operational channels: - Interactive shell history files. - Process listings and process-inspection interfaces while the command runs. - Terminal session recording and audit tooling. - CI/CD logs and command tracing. - Wrapper scripts, telemetry, crash reports, or support transcripts. A wallet private key is a bearer credential with irreversible signing authority. Unlike a password protected by server-side access controls, possession of the key is sufficient to sign transactions independently. Exposure therefore cannot be mitigated merely by changing an application password; the wallet must be replaced and its permissions migrated or revoked. ### Attack Path 1. A user substitutes a real wallet private key for the placeholder and runs the documented command. 2. The shell records the complete command in its history, or the operating system exposes it in the process argument list. 3. Another local user, monitoring process, CI log reader, terminal-recording administrator, or later attacker obtains the recorded argument. 4. The attacker imports the recovered private key into a wallet or signing library. 5. The attacker signs and broadcasts unauthorized transactions. 6. The attacker transfers assets or exercises any treasury, escrow, token-allowance, and contract permissions associated with the wallet. ### Impact Assessment An attacker who recovers the private key obtains full cryptographic control over the corresponding ...[truncated 555 chars]
• Remediation: ## Remediation Suggestions 1. Remove the `--private-key` authentication example from the documentation. 2. Provide an interactive hidden-input prompt that does not echo or persist the key. 3. Prefer hardware wallets, TEE-backed wallets, operating-system keychains, or external signing services so the raw key never reaches the CLI. 4. If noninteractive automation is required, integrate with a protected secret manager and pass a short-lived credential through a restricted file descriptor or supported secret-injection mechanism. 5. Avoid storing raw keys in shell environment variables where feasible, because process environments may also be exposed. 6. Ensure logs, debug output, exception handlers, and telemetry redact wallet credentials. 7. Recommend dedicated low-value operational wallets with spending limits rather than primary wallets. 8. Document an incident-response procedure requiring immediate wallet migration, token-allowance revocation, treasury-role revocation, and monitoring after suspected exposure.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (6)

Missing User Warnings

High

• Confidence: 97% confidence
• Finding: The skill advertises high-impact financial actions including payments, swaps, bridges, and fiat ramps but does not prominently require explicit user confirmation, recipient verification, amount/network review, or warn about irreversible loss. In an agent skill context, this omission is dangerous because an LLM or automation layer may treat these operations as routine and initiate value transfer based on ambiguous or manipulated prompts.

Missing User Warnings

High

• Confidence: 99% confidence
• Finding: The natural-language payment interface encourages free-form instructions like 'send 10 USDC to 0xABC' without an explicit safety statement that parsing may be ambiguous or prompt-injected and must be confirmed by a human before signing or submitting a transaction. Because this skill is designed for autonomous agents, natural-language payment execution materially increases the risk of misdirected or unauthorized transfers if the parsed intent is wrong or adversarially influenced.

External Transmission

Medium

• Category: Data Exfiltration

Content

Every PayLobster API is payable via HTTP 402:
```bash
# Discovery endpoint
curl https://paylobster.com/api/x402/discovery

# Agent pays for service automatically
GET /api/v3/reputation?address=0x...

• Confidence: 60% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The merchant flow shows issuance and use of live secret keys such as 'sk_live_...' but does not warn users not to expose these secrets in logs, chats, browser code, or agent transcripts. In an agent environment, generated credentials may be echoed, stored in conversation memory, or reused automatically, enabling account takeover of payment operations if leaked.

External Transmission

Medium

• Category: Data Exfiltration

Content

```bash
# Create link
curl -X POST https://paylobster.com/api/v3/links \
  -H "Content-Type: application/json" \
  -d '{"amount":"10","recipient":"0xABC...","memo":"Code review"}'

• Confidence: 60% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Missing User Warnings

Medium

• Confidence: 88% confidence
• Finding: The fiat on/off-ramp documentation omits clear notice that these flows may trigger KYC/AML checks, share personal and financial data with third-party providers, and create real bank/card settlement consequences. In a payment agent skill, that missing warning can cause users to initiate privacy-sensitive or financially consequential actions without informed consent.

Static analysis

No suspicious patterns detected.