Back to skill

Security audit

Power Oracle

Security checks for vulnerabilities and agentic risk

Overview

The skill is coherent for a paid workout-power API, but it can send personal fitness data and authorize x402 payments without requiring explicit per-transaction user approval.

Review this skill carefully before installing. It should be used only if you are comfortable sending workout details and body metrics to WorkCapacity, and the agent host should require explicit confirmation before any x402 payment proof is generated or submitted.

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 (1)

T09 · Insecure Skill Coding Practices

Warning
Location
references/api-contract.md:100
Finding

Paid API Transaction May Proceed Without Explicit User Authorization

Content
View full analysis
`. - Keep the same validated payload when you retry. Payment does not change movement validation, required inputs, or split rules. - Follow the live challenge and current server behavior. Current production contract: - Current x402 route prices are published at `GET /v1/payment-requirements` - Authorized `2xx` responses settle the payment - Authorized post-billable `4xx` responses also settle the payment - `5xx` responses do not settle the payment - If the live challenge or server behavior differs, treat the live server behavior as authoritative ``` Related instruction from `SKILL.md:52`: ```markdown - `POST /v1/compute-power` may require an x402 payment challenge. See [references/api-contract.md](references/api-contract.md) for step-by-step examples. ``` ### Technical Analysis The documented workflow tells the agent to build an x402 payment proof and retry a request after receiving an HTTP 402 challenge. It does not require transaction-specific user confirmation before creating or submitting the proof. It also does not establish a maximum price, approved asset, network, recipient, expiration policy, or cumulative spending limit. Fetching public pricing metadata does not itself constitute informed user authorization. The risk is amplified by the documented behavior that an authorized post-billable `4xx` response can settle th ...[truncated 1745 chars]
Remediation
View remediation
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 (4)

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
94% confidence
Finding

The contract requires sending persistent user identifiers plus sensitive body metrics (height, body mass, age, sex, dates) to an external API, but it provides no privacy notice, data-minimization guidance, retention limits, or consent requirements. In an agent setting, this creates a real privacy and compliance risk because the skill operationalizes transmission of personal data without safeguards or user disclosure.

Content

No source excerpt is available for this finding.

External Transmission

Medium
Category
Data Exfiltration
Confidence
89% confidence
Finding

This example instructs posting workout payloads to an external service, which can transmit personal and health-adjacent data off-platform. While external API use is expected for this skill, it is still a genuine data-exfiltration surface because the payload includes identifiers and body metrics and the contract does not pair the transmission with privacy, consent, or redaction controls.

Content

Scanner excerpt · references/api-contract.md (reported line 121)May include surrounding context.

Example challenge flow:

bash
curl -i https://api.workcapacity.io/v1/compute-power \
  -H 'Content-Type: application/json' \
  --data @payload.json

External Transmission

Medium
Category
Data Exfiltration
Confidence
89% confidence
Finding

This example instructs posting workout payloads to an external service, which can transmit personal and health-adjacent data off-platform. While external API use is expected for this skill, it is still a genuine data-exfiltration surface because the payload includes identifiers and body metrics and the contract does not pair the transmission with privacy, consent, or redaction controls.

Content

Scanner excerpt · references/api-contract.md (reported line 121)May include surrounding context.

Example challenge flow:

bash
curl -i https://api.workcapacity.io/v1/compute-power \
  -H 'Content-Type: application/json' \
  --data @payload.json

External Transmission

Medium
Category
Data Exfiltration
Confidence
87% confidence
Finding

The retry example after a 402 payment challenge again sends the same compute payload to the external API, now with a payment proof header. This expands exposure slightly because it combines personal workout data with payment metadata and still lacks any privacy, secret-handling, or domain-validation guidance.

Content

Scanner excerpt · references/api-contract.md (reported line 136)May include surrounding context.

Example retry after payment:

bash
curl https://api.workcapacity.io/v1/compute-power \
  -H 'Content-Type: application/json' \
  -H 'PAYMENT-SIGNATURE: <x402 proof>' \
  --data @payload.json

Static analysis

No suspicious patterns detected.