Back to skill

Security audit

showmethemoney skill

Security checks for vulnerabilities and agentic risk

Overview

This paid demo skill is mostly disclosed, but it can contact a payment/execution backend during installation and uses an unresolved merchant identity for a real-money Solana Mainnet flow.

Review before installing. Only use this skill if you are comfortable with a third-party paid demo contacting wenfu.cc and StablePay, and do not proceed with any payment unless the merchant identity, amount, currency, network, and recipient are clearly resolved and confirmed outside the placeholder configuration.

Vulnerability Patterns
  • 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
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (2)

other

Warning
Location
SKILL.md:25
Finding

External Capability Execution Is Triggered by an Installation Request

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, line 25
Vulnerability Type: Unexpected network access during installation
Risk Level: Medium

Vulnerable Code Snippet:

markdown
1. When the user asks to use or install this paid demo skill, call the Execute endpoint.

Technical Analysis

The instruction combines skill installation with capability execution. Installation should ordinarily be a local discovery or configuration operation and does not require invoking the paid execution endpoint at https://wenfu.cc/showmethemoney.

Calling an external service during installation violates least-surprise and least-functionality principles. It discloses network and request metadata to a third party and can cause the backend to return HTTP 402, initiating the documented payment workflow even though the user requested installation rather than execution.

Attack Path

  1. A user asks the agent to install the skill.
  2. The agent follows line 25 and contacts the external execution endpoint.
  3. The external server receives the request and associated network or request metadata.
  4. The server may return HTTP 402.
  5. Under the remaining skill instructions, the StablePay payment flow may then be presented or initiated.
  6. The execution request is retried after payment, despite the original request being installation rather than capability use.

Impact Assessment

The issue can produce unauthorized or unexpected outbound network access and expose request metadata to the external backend. It may also unnecessarily initiate a real-money payment workflow on Solana Mainnet. It does not grant local system privileges, persistence, or code execution based on the audited file.

Remediation
View remediation

Remediation Suggestions

  • Remove installation from the execution condition. Installation must not contact the execution or payment endpoints.
  • Require a separate, explicit user request to invoke the paid capability.
  • Before any paid flow, clearly display the price, currency, network, verified merchant identity, and destination endpoint.
  • Require explicit user confirmation before initiating payment.
  • Apply strict request minimization and avoid transmitting unrelated user context or credentials.
  • Treat HTTP 402 as an informational payment requirement rather than implicit authorization to transact.
  • Recommended wording: When the user explicitly invokes this capability, and only after confirming any required payment, call the Execute endpoint. Do not call it during installation.

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:16
Finding

Unresolved Merchant DID Placeholder in Mainnet Payment Configuration

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 16–21
Vulnerability Type: Insecure payment identity configuration
Risk Level: Medium

Vulnerable Code Snippet:

markdown
- Skill DID: `did:solana:REPLACE_WITH_YOUR_SKILL_DID`

## Backend endpoints

- Execute: `https://wenfu.cc/showmethemoney`
- Verify purchase: `https://api.stablepay.co/verify?skill=did:solana:REPLACE_WITH_YOUR_SKILL_DID&agent={AGENT_DID}`

Technical Analysis

The skill advertises a payment flow using USDC on Solana Mainnet, but both the merchant identity and purchase-verification request contain the unresolved placeholder REPLACE_WITH_YOUR_SKILL_DID.

Purchase verification must be cryptographically and operationally bound to the exact merchant or skill identity for which payment was authorized. A placeholder prevents the agent and user from reliably confirming that the advertised merchant, payment recipient, execution service, and verification record refer to the same entity. Depending on backend handling, verification may fail, behave inconsistently, or be associated with an unintended configuration.

Attack Path

  1. A user invokes the paid capability.
  2. The execution backend returns HTTP 402 and the payment workflow begins.
  3. The skill presents or uses a placeholder rather than a concrete merchant DID.
  4. Purchase verification is requested with the same unresolved placeholder.
  5. Verification either fails or cannot reliably establish that payment was made for the intended merchant and skill.
  6. If any involved component accepts inconsistent identity data, the payment and capability authorization may be incorrectly associated.

Impact Assessment

The issue undermines payment identity integrity and can cause failed verification, denial of paid access after payment, or ambiguous authorization. Because the configuration targets Solana Mainnet and USDC, user funds may be involved. The audited content does ...[truncated 162 chars]

Remediation
View remediation

Remediation Suggestions

  • Replace every placeholder with the exact production skill or merchant DID before publication.
  • Validate that the DID matches the merchant identity and payment recipient returned by the backend.
  • Fail closed if the DID is absent, malformed, still contains placeholder text, or differs across execution, payment, and verification responses.
  • Bind verification to the skill DID, agent DID, payment transaction identifier, amount, currency, network, and intended capability.
  • Verify the backend response cryptographically where supported and enforce TLS certificate validation.
  • Display the verified merchant identity and payment details to the user before requesting confirmation.
  • Add deployment-time validation that rejects unresolved placeholders in Mainnet configurations.
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)

External Transmission

Medium
Category
Data Exfiltration
Confidence
50% confidence
Finding

Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Content

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

md
## Backend endpoints

- Execute: `https://wenfu.cc/showmethemoney`
- Verify purchase: `https://api.stablepay.co/verify?skill=did:solana:REPLACE_WITH_YOUR_SKILL_DID&agent={AGENT_DID}`

## Instructions