Back to skill

Security audit

PayLock Escrow

Security checks for vulnerabilities and agentic risk

Overview

The skill is not clearly malicious, but it guides cryptocurrency escrow and payment-release workflows with weakly scoped authority and under-disclosed financial risk.

Review this skill carefully before installing. It appears to be a PayLock integration guide rather than malware, but it can lead an agent toward cryptocurrency contract creation and fund-release actions; require manual approval for every transaction, verify recipient and contract IDs independently, and avoid exposing private earnings or contract data through agent_id-only dashboard links.

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)

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:35
Finding

Financial State-Change Requests Are Documented Without Authentication or Proof of Authority

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:35-39; references/api.md:27-30; references/api.md:115-121
Vulnerability Type: Missing authentication and authorization controls in documented financial workflows
Risk Level: High

Complete Code Snippet

From SKILL.md:35-39:

bash
### Release funds
```bash
curl -X POST https://paylock.xyz/contract/{id}/release \
  -H "Content-Type: application/json" \
  -d '{"payee":"your-agent-id"}'

From references/api.md:27-30:

markdown
### POST /contract/:id/release — Release funds to payee
```json
{ "payee": "your-agent-id" }
text

From `references/api.md:115-121`:

```markdown
### POST /jobs/:job_id/accept — Accept a bid (client)
```json
{
  "bid_id": "bid-id-from-list",
  "poster_id": "your-id"
}
text

### Technical Analysis

The documented release and bid-acceptance operations change financially significant state, but their examples contain only caller-controlled resource and identity values. They do not specify an authorization header, authenticated session, API credential, wallet signature, nonce, replay protection, or other cryptographic proof that the caller controls the payer or poster identity.

In particular, the release request permits the caller to submit a `payee` value, while the bid-acceptance request relies on a supplied `poster_id`. Identifiers must not be treated as authentication credentials because they may be public, predictable, disclosed through marketplace data, or otherwise obtainable by an unauthorized party.

The repository contains API documentation rather than the remote server implementation. Consequently, this finding confirms that the skill promotes unsafe, apparently unauthenticated request patterns; whether the remote service has undocumented server-side controls could not be verified from the audited files.

### Attack Path

1. An attacker discovers or enumerates a contract ID, job
...[truncated 1298 chars]
Remediation
View remediation

Remediation Suggestions

  • Require authentication for every state-changing endpoint.
  • Require the payer or job poster to sign a canonical transaction payload with the wallet bound to the relevant account.
  • Bind agent and poster identifiers to verified accounts or wallets; never treat a submitted identifier as proof of identity.
  • Include the endpoint, resource ID, intended state transition, recipient, amount, nonce, and expiration time in the signed payload.
  • Validate authorization server-side against the contract or job owner before changing state.
  • Add unique nonces, expiration timestamps, idempotency keys, and replay detection.
  • Reject caller-selected payee values that do not match the immutable payee recorded in the escrow contract.
  • Require explicit human confirmation for irreversible releases and bid acceptance where an AI agent is acting for a user.
  • Maintain tamper-resistant audit logs and notify all affected parties before and after financial transitions.
  • Update every example to show the required authentication or wallet-signature mechanism rather than presenting unauthenticated requests.

T09 · Insecure Skill Coding Practices

Warning
Location
references/api.md:124
Finding

Financial Dashboard Is Explicitly Exposed Without Authentication

Content
View full analysis

Vulnerability Details

File Location: references/api.md:124-128
Vulnerability Type: Unauthenticated exposure of financial and contract information
Risk Level: Medium

Complete Code Snippet

markdown
## Dashboard

https://paylock.xyz/dashboard?agent_id=your-agent-id

text
Earnings, contracts, trust badge — no login required.

Technical Analysis

The documentation explicitly states that a dashboard containing earnings and contract information is available without login. Access is selected through the caller-controlled agent_id query parameter.

Agent identifiers are likely to be public because they are used in agent profiles, contracts, jobs, bids, trust scores, and badges. Therefore, an identifier in the URL does not provide confidentiality or authorization. If the dashboard returns non-public earnings or contract metadata, an unauthenticated user may enumerate agent IDs and retrieve financial activity or business-relationship information.

The repository does not contain the dashboard implementation, so the exact fields returned and resistance to automated enumeration could not be tested. The confirmed issue is the documented absence of authentication for a dashboard described as exposing earnings and contracts.

Attack Path

  1. An attacker obtains agent IDs from public agent listings, trust badge URLs, marketplace jobs, bids, contract links, or predictable naming conventions.
  2. The attacker requests https://paylock.xyz/dashboard?agent_id=TARGET_ID without authenticating.
  3. The attacker repeats the request for additional known or guessed agent IDs.
  4. Dashboard responses are collected and correlated to identify earnings, contract activity, counterparties, or commercial patterns.
  5. The information may then support profiling, targeted fraud, phishing, extortion, or identification of high-value accounts.

Impact Assessment

Exploitation does not directly grant account modi ...[truncated 501 chars]

Remediation
View remediation

Remediation Suggestions

  • Require an authenticated session or signed wallet challenge before displaying private dashboard information.
  • Enforce server-side authorization so a principal can access only dashboards associated with its verified identity.
  • Separate the authenticated financial dashboard from any intentionally public agent profile.
  • Restrict public responses to explicitly non-sensitive fields such as display name, public services, and trust badge.
  • Do not expose earnings, private contracts, counterparties, or transaction details through unauthenticated endpoints.
  • Use non-enumerable internal identifiers where practical, while recognizing that identifier complexity is not a substitute for authorization.
  • Add rate limits, enumeration detection, access logging, and alerts for bulk dashboard retrieval.
  • Review existing dashboard data for prior exposure and notify affected users if sensitive information was publicly accessible.
  • Update the documentation to clearly distinguish public data from authenticated, owner-only financial information.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (4)

Missing User Warnings

High
Category
Not specified by scanner
Confidence
97% confidence
Finding

The skill documents operational steps for creating contracts, verifying delivery, and releasing funds but does not include prominent warnings that these actions may lock or irreversibly release SOL. In a financial escrow context, omission of confirmation and risk warnings makes accidental or socially engineered transfers much more likely and raises the severity compared with ordinary API-invoking skills.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
93% confidence
Finding

The trigger list includes broad, common phrases such as 'escrow', 'release payment', 'create contract', and 'trust score', which can cause the skill to activate in contexts where the user did not intend to initiate a money-moving or contract-related workflow. In a skill that facilitates fund locking and release, unintended activation materially increases the chance of unsafe suggestions or transactional actions being surfaced without adequate user intent validation.

Content

No source excerpt is available for this finding.

External Transmission

Medium
Category
Data Exfiltration
Confidence
60% 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 24)May include surrounding context.

Create escrow contract

bash
curl -X POST https://paylock.xyz/contract \
  -H "Content-Type: application/json" \
  -d '{"payer":"client-id","payee":"your-agent-id","milestone":"Deliver feature X","amount_sol":0.1}'
# Returns: contract_id, deposit_address, payment_link

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
96% confidence
Finding

The API reference explicitly states that the dashboard exposing earnings, contracts, and trust badge data requires no login and is accessed only by an agent_id query parameter. If agent_id values are guessable, enumerable, leaked, or reused across the marketplace API, unauthorized parties can view potentially sensitive business metadata and transaction history, enabling privacy loss, profiling, and targeted abuse.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.