Back to skill

Security audit

Paytoll

Security checks for vulnerabilities and agentic risk

Overview

This skill is coherent in purpose, but it gives an unpinned npm MCP server a raw wallet private key and lets it make paid calls automatically.

Install only with a dedicated wallet containing minimal funds, and understand that the MCP package receiving `PRIVATE_KEY` is fetched by npm without a pinned version in this artifact. Review or pin the MCP server yourself before use, monitor the wallet, and avoid using any main wallet or broadly funded key.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (1)

T08 · Insecure Dependencies

Error
Location
SKILL.md:4
Finding

Unpinned Third-Party Package Executes with Wallet Private Key Access

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, line 4
Vulnerability Type: Unpinned dependency execution with exposure of sensitive wallet credentials
Risk Level: High

Vulnerable Code

yaml
metadata: {"mcpServers":{"paytoll":{"command":"npx","args":["-y","paytoll-mcp"],"env":{"PRIVATE_KEY":"${PRIVATE_KEY}"}}}}

Technical Analysis

The Skill invokes npx -y paytoll-mcp without pinning the package to a specific, reviewed version. No lockfile, integrity hash, signed provenance requirement, or bundled implementation is provided in the audited project. Consequently, the code executed at runtime can differ from the code that was previously reviewed.

The downloaded package is also granted direct access to the PRIVATE_KEY environment variable. A compromised npm package release, maintainer account, package dependency, or registry delivery path could introduce arbitrary code that reads and exfiltrates the wallet private key. Linking to a public source repository does not cryptographically establish that the npm artifact being executed was built from the reviewed source.

The documentation claims that the private key remains local and is used only for EIP-712 payment authorizations, but this property cannot be verified from the project because the executable MCP server source and dependency tree are not included.

Attack Path

  1. An attacker compromises the paytoll-mcp npm package, its publishing account, or one of its transitive dependencies.
  2. The attacker publishes a malicious version that contains credential-stealing or unauthorized-signing logic.
  3. When the Skill starts, npx -y paytoll-mcp automatically retrieves the currently resolved package version without interactive confirmation.
  4. The package executes locally with the privileges of the Agent process and receives PRIVATE_KEY in its environment.
  5. The malicious code reads the private key and sends it to an attacker-controlled service, or uses it locally to create ...[truncated 862 chars]
Remediation
View remediation

Remediation Suggestions

  1. Pin paytoll-mcp to an exact, reviewed version rather than resolving the latest available release.
  2. Use a lockfile and verify the integrity hashes of the package and all transitive dependencies.
  3. Require signed package provenance or independently verify that the distributed npm artifact was built from the referenced source revision.
  4. Vendor or bundle an audited implementation where feasible so the effective runtime code is included in the reviewed project.
  5. Run the MCP server inside a restricted container or sandbox with minimal filesystem, environment, process, and network access.
  6. Avoid exposing a raw wallet private key to the package. Prefer an isolated signer that enforces destination, chain, token, amount, frequency, and cumulative spending limits.
  7. Require explicit user approval for each signature or payment authorization, particularly when a destination or payment amount has not previously been approved.
  8. Use a dedicated wallet containing only the minimum required funds, rotate the key if package compromise is suspected, and monitor the wallet for unexpected authorizations or transactions.
  9. Disable or locally allowlist dynamically discovered tools so remote changes cannot silently expand the capabilities exposed by the server.
Vulnerability Patterns
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (1)

Credential Access

High
Category
Privilege Escalation
Confidence
70% confidence
Finding

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Content

Scanner excerpt · SKILL.md (reported line 151)May include surrounding context.

md
- Input: `username` OR `userId` (exactly one)

**`twitter-post`** ($0.015/call)
Post a tweet using the user's own OAuth 2.0 access token. Supports replies and quote tweets.
- Use when: "Post this tweet for me", "Reply to this tweet"
- Input: `text`, `accessToken` (user's OAuth token), `replyToId` (optional), `quoteTweetId` (optional)
- Note: Requires the user's own X API OAuth token with `tweet.write` scope.

Static analysis

No suspicious patterns detected.