Back to skill

Security audit

Solvera Markets

Security checks for vulnerabilities and agentic risk

Overview

This skill is a disclosed guide for an on-chain marketplace, but it can lead an agent to sign API-built blockchain transactions without sufficiently specific transaction checks.

Review before installing or using with a funded wallet. Use a dedicated low-value wallet, local chain and contract allowlists, pinned ABIs, calldata decoding, transaction simulation, and explicit approval of destination, function, value, token transfers, and allowance changes before signing any transaction.

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:139
Finding

Untrusted API-Generated Transaction Data May Be Signed and Broadcast

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 139–149; related safeguard at line 158
Vulnerability Type: T09: Insecure Skill Coding Practices
Risk Level: High

Vulnerable Code:

json
{
  "data": {
    "to": "0xContract",
    "calldata": "0x...",
    "value": "0"
  },
  "next_steps": [
    { "action": "sign_and_send", "network": "base" }
  ]
}

The only related transaction-validation requirement is:

markdown
- Validate on-chain state before signing transactions.

Technical Analysis

The Skill instructs agents to obtain the transaction destination, calldata, and native value from the remote Solvera API and then proceed with a sign_and_send action. These fields fully define what a blockchain transaction invokes and what authority the signer grants.

Although the documentation tells agents to validate on-chain state, it does not require them to:

  • Independently verify the chain ID and destination contract.
  • Decode and inspect the returned calldata.
  • Allowlist permitted function selectors.
  • Compare decoded arguments with the agent's intended operation.
  • Verify that the transaction does not create unexpected token approvals.
  • Confirm that the native-token value is zero or otherwise expected.
  • Simulate the transaction and inspect resulting asset changes.

Obtaining the expected contract address from /api/config does not provide independent verification because the configuration and transaction builder are served by the same trust domain. If that API or its infrastructure is compromised, both responses could be altered consistently.

Keeping private keys local, as required elsewhere in the Skill, prevents direct key disclosure but does not prevent misuse of those keys through authorization of a malicious transaction.

Attack Path

  1. An agent requests a legitimate offer, fulfillment, or other transaction from a documented write endpoint.

...[truncated 1384 chars]

Remediation
View remediation

Remediation Suggestions

  1. Store the expected chain ID and verified contract addresses in trusted local configuration rather than relying solely on /api/config.
  2. Reject any response whose to address does not exactly match an allowlisted, checksummed contract address for the locally selected network.
  3. Decode calldata locally using a pinned, verified contract ABI.
  4. Allowlist the function selectors appropriate to each requested operation.
  5. Compare every decoded parameter with the original request and current independently queried on-chain state.
  6. Enforce an expected native-token value, normally zero, and reject any unexplained value transfer.
  7. Detect and reject unexpected token approvals, arbitrary external calls, delegate calls, and unlimited allowances.
  8. Simulate the transaction through an independently selected provider before signing and inspect all expected asset and allowance changes.
  9. Present the decoded operation, destination, network, asset deltas, and approval changes for explicit authorization before signing.
  10. Fail closed when calldata cannot be decoded, simulation fails, independently obtained state differs from the API response, or any transaction field is unexpected.
  11. Document these checks as mandatory requirements rather than relying on the general instruction to validate on-chain state.
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • 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

Static analysis

No suspicious patterns detected.