Back to skill

Security audit

Apex Evolution Insight

Security checks for vulnerabilities and agentic risk

Overview

This skill is a paid crypto-signal fetcher, but it asks an agent to use a wallet private key for automatic payments without enough payment-safety guardrails.

Review this before installing. Use only a dedicated low-balance wallet, confirm the expected per-call price before each request, and avoid exposing a primary wallet private key to an agent or client library. Treat every invocation as capable of spending funds.

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

Error
Location
SKILL.md:30
Finding

Automatic Cryptocurrency Payment Using an Unrestricted Private Key

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 30–41
Vulnerability Type: Automatic wallet authorization without explicit approval or enforced transaction limits
Risk Level: High

Vulnerable Code

text
The x402 client handles payment authorisation automatically. No API key, no account, no subscription required — just an EVM wallet with USDC on Base mainnet.

```python
# Example using the x402-python client
from x402.client import x402_get

response = x402_get(
    url="https://apexrunner.ai/signals/apex-evolution-insight",
    private_key=os.environ["EVM_PRIVATE_KEY"]
)
print(response.json())
text

### Technical Analysis

The Skill directs the agent to retrieve a raw EVM private key from the environment and pass it to a third-party x402 client. It explicitly states that payment authorization occurs automatically.

The documented workflow does not require transaction-level user confirmation or enforce the expected chain, recipient, token, payment amount, or cumulative spending limit before signing. Although the document advertises a price of $15 per call, this descriptive text does not cryptographically constrain the payment challenge returned by the remote service.

Supplying an unrestricted private key directly to a client library also expands the trust boundary. A compromised or unexpectedly modified dependency could access the key and potentially sign transactions unrelated to the intended purchase. Similarly, a compromised endpoint, DNS path, or payment response could attempt to induce an unintended payment if the client does not independently enforce strict constraints.

### Attack Path

1. The agent loads `EVM_PRIVATE_KEY` from its environment.
2. The agent passes the unrestricted private key to `x402_get`.
3. The external endpoint returns an x402 payment challenge containing transaction parameters.
4. The client automatically authorizes payment without explicit transaction-l
...[truncated 974 chars]
Remediation
View remediation

Remediation Suggestions

  1. Require explicit user approval after presenting the complete payment details, including the chain, token, recipient, amount, endpoint, and applicable fees.
  2. Enforce a hard per-request payment ceiling of $15 or the current independently verified advertised price. Reject any challenge exceeding that value.
  3. Enforce a cumulative spending limit and rate limit to prevent repeated calls from draining the wallet.
  4. Validate that the payment uses Base mainnet, the expected USDC contract, and an allowlisted recipient before signing.
  5. Use an isolated, low-balance wallet dedicated to this Skill instead of a primary wallet.
  6. Prefer a constrained signer, session key, or narrowly scoped allowance mechanism over exposing an unrestricted private key to the client.
  7. Pin the x402 client to a reviewed version, verify package integrity, and monitor it for supply-chain compromise.
  8. Keep the private key in a secure signer or secret-management service and prevent it from appearing in logs, exceptions, responses, or diagnostic output.
  9. Validate payment challenge fields locally rather than trusting the remote endpoint or client library to enforce security policy.
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)

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
92% confidence
Finding

The skill instructs the agent to use an EVM private key from the environment to authorize a paid network request, but it does not clearly warn about the financial and credential risks of doing so. Even if the x402 client is legitimate, this encourages use of a signing-capable wallet secret for automated outbound requests, which can lead to unintended payments, misuse of funds, or key exposure through poor agent/tooling practices.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.