ClawHub
Back to skill

Security audit

XRP

Security checks for vulnerabilities and agentic risk

Overview

This XRP helper is only documentation, but it contains unsafe key and transaction-status guidance that could cause financial loss if followed.

Review this skill carefully before installing. It has no code execution or persistence, but do not rely on its regular-key or transaction-finality guidance for real XRP transfers: treat all signing keys as highly sensitive, and verify transaction hashes in a validated ledger before retrying or replacing payments.

A.I.G

Vulnerability Patterns
  • 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
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
Findings (2)

other

Error
Location
SKILL.md:53
Finding
Misleading Characterization of Regular Keys as Limited-Risk Credentials## Vulnerability Details **File Location**: `SKILL.md`, line 53 **Vulnerability Type**: Unsafe financial security guidance **Risk Level**: High ### Vulnerable Content ```markdown - Regular key allows delegation without exposing master key — good for trading with limited risk ``` ### Technical Analysis The guidance describes an XRPL regular key as suitable for trading with “limited risk,” but does not explain that it remains a sensitive signing credential with broad authority over the account. Separating a regular key from the master key can support key rotation and protect the master credential, but it does not make the regular key safe to disclose to an exchange, trading service, automated agent, or other untrusted party. A user following this statement could incorrectly interpret the regular key as a restricted API key that is limited to trading operations. The skill provides no warning against sharing the key and does not describe transaction authorization boundaries, credential isolation, revocation procedures, or multisigning controls. ### Attack Path 1. An attacker or malicious trading service asks the victim to provide a regular key, claiming it is a limited-risk trading credential. 2. The victim relies on the skill's characterization and discloses or insecurely configures the regular key. 3. The attacker uses the key to authorize account transactions within its actual signing authority. 4. The attacker transfers assets, changes account settings, or otherwise exercises unauthorized control before the victim rotates or removes the key. ### Impact Assessment Exploitation requires obtaining the regular private key or seed, but no access to the master key is necessarily required. The resulting scope can include unauthorized signing authority over the associated XRPL account, potentially causing loss of XRP or issued assets and unauthorized account changes. The exact consequences depend on the account configuration an ...[truncated 28 chars]
Remediation
## Remediation Suggestions Replace the statement with guidance that accurately describes the sensitivity and authority of regular keys. For example: ```markdown - A regular key can authorize account transactions without exposing the master key, but it is still a highly sensitive signing credential with broad account authority. Never share it or treat it as a restricted trading API key. Store it securely, rotate it if exposed, and consider multisigning or purpose-built constrained authorization controls when delegating operations. ``` Additionally: - Explicitly state that private regular keys and seeds must never be disclosed to trading platforms or support personnel. - Document how to remove or rotate a compromised regular key. - Recommend hardware-backed storage or an isolated signer. - Explain that multisigning improves separation of authority but must be configured and tested carefully. - Avoid describing credentials as “limited risk” unless enforceable technical restrictions are clearly identified.

other

Warning
Location
SKILL.md:25
Finding
Contradictory Guidance About Queued and Pending Transactions## Vulnerability Details **File Location**: `SKILL.md`, lines 25 and 46 **Vulnerability Type**: Unsafe financial operational guidance **Risk Level**: Medium ### Vulnerable Content ```markdown - No mempool or pending state — transactions either succeed immediately or fail ``` ```markdown - "terQUEUED" — transaction queued due to account limit, will process shortly ``` ### Technical Analysis The first statement categorically claims that XRPL transactions have no pending state and either succeed immediately or fail. The later statement acknowledges that a transaction can return `terQUEUED` and remain queued for later processing. These instructions are operationally inconsistent. A preliminary submission response must not be treated as equivalent to a final validated-ledger result. If a user assumes that a non-immediate success means final failure, the user may create and submit another payment before determining whether the original queued transaction was eventually validated. ### Attack Path 1. A user submits a payment and receives a `terQUEUED` or another non-final submission result. 2. The user relies on the assertion that there is no pending state and concludes that the payment failed permanently. 3. Without checking the validated ledger or the original transaction hash and sequence, the user creates another payment for the same obligation. 4. The original queued transaction is subsequently validated. 5. The newly created payment is also submitted and may validate, resulting in an unintended duplicate transfer. An attacker could encourage this behavior by falsely claiming that a delayed payment failed and pressuring the victim to submit a replacement before ledger validation is checked. ### Impact Assessment This issue does not grant system privileges or execute code. Its impact is financial and operational: users may submit duplicate transfers, misreport payment status, or take incorrect recovery actions. ...[truncated 160 chars]
Remediation
## Remediation Suggestions Replace the categorical statement with guidance that distinguishes submission responses from final ledger validation. For example: ```markdown - Do not treat a submission response as final settlement. A transaction may be queued, rejected provisionally, or later included in a validated ledger. Before retrying, check the original transaction hash, account sequence, LastLedgerSequence, and validated-ledger result. - "terQUEUED" means the transaction was accepted into the local transaction queue but has not yet reached a final validated result. Monitor it until validation or definitive expiry before creating a replacement payment. ``` The skill should also instruct users to: - Record the transaction hash and sequence for every submission. - Verify the transaction against a validated ledger before retrying. - Avoid creating a second transaction for the same payment obligation merely because confirmation is delayed. - Use an appropriate `LastLedgerSequence` so transaction expiry can be determined. - Clearly distinguish preliminary engine results from final validated transaction metadata.

SkillSpector

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.