T09 · Insecure Skill Coding Practices
- 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: HighComplete 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.
