ClawHub
Back to skill

Security audit

Xaman Wallet Integration

Security checks for vulnerabilities and agentic risk

Overview

This is a wallet-integration guide with disclosed third-party SDK and session persistence risks, but no hidden code or malicious behavior in the artifact.

Before installing or using this skill, treat it as a starter guide for Xaman wallet integration. Review the SDK delivery method, avoid unnecessary persistent browser sessions, and require users to verify transaction details in the trusted wallet interface.

A.I.G

Vulnerability Patterns
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • 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
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (2)

T03 · Remote Payload Retrieval and Execution

Error
Location
SKILL.md:12
Finding
Unpinned Remote JavaScript SDK Executes Mutable Third-Party Code## Vulnerability Details **File Location**: `SKILL.md`, line 12 **Vulnerability Type**: Remote, unpinned executable dependency **Risk Level**: High ```html <script src="https://xumm.app/assets/cdn/xumm-oauth2-pkce.min.js"></script> ``` ### Technical Analysis The documented integration loads an unversioned JavaScript file directly from an external CDN. No immutable version, Subresource Integrity hash, or equivalent content verification is specified. The downloaded script executes in the application's origin with the same browser privileges as first-party application code. Because the effective code can change after the Skill has been reviewed, compromise of the CDN, upstream deployment process, DNS path, or provider account could result in arbitrary JavaScript being delivered to application users. This behavior most closely matches remote payload retrieval and execution. ### Attack Path 1. An attacker compromises the CDN asset, its publishing account, or another component capable of changing the remote response. 2. The attacker replaces the SDK response with modified JavaScript. 3. A user visits an application that implemented the documented script tag. 4. The browser retrieves and executes the modified script under the application's origin. 5. The malicious script accesses browser-visible application data, wallet session state, or transaction workflows and transmits or alters that information. ### Impact Assessment Successful exploitation provides arbitrary JavaScript execution in the context of every application page that loads the SDK. The resulting scope can include access to JavaScript-readable wallet session material, application data, DOM content, and authenticated API operations available to the user. In a wallet application, malicious code could also manipulate displayed destinations or transaction-signing requests. The exact privileges remain limited by browser isolation, application permissions, and ...[truncated 44 chars]
Remediation
## Remediation Suggestions - Prefer an audited, explicitly versioned SDK installed through a package manager and committed lockfile. - Pin the dependency to an exact version rather than a floating or unversioned release. - If CDN delivery is unavoidable, use a versioned, immutable URL and a verified Subresource Integrity hash with an appropriate `crossorigin` setting. - Deploy a restrictive Content Security Policy that permits scripts only from explicitly trusted sources and disallows unsafe inline execution. - Monitor upstream releases and CDN integrity, and establish a controlled process for reviewing and updating the SDK. - Isolate wallet integration from unrelated application data where feasible and require users to verify all transaction details in the trusted wallet interface.

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:49
Finding
Wallet Session Material Is Persisted in JavaScript-Readable Local Storage## Vulnerability Details **File Location**: `SKILL.md`, lines 49-51 and line 58 **Vulnerability Type**: Insecure client-side session storage **Risk Level**: Medium ```typescript { redirectUrl: string, // Where to redirect after auth rememberJwt: boolean, // Persist session in localStorage (default: true) storage: Storage, // Custom storage (default: localStorage) implicit: boolean // Use implicit flow (default: false) } ``` ```text The SDK auto-restores sessions. Call `xumm.logout()` before `authorize()` to force fresh login. ``` ### Technical Analysis The documentation states that JWT persistence is enabled by default and that `localStorage` is the default storage mechanism. Data in `localStorage` is readable by any JavaScript executing under the same origin. It does not have the `HttpOnly` protection available to server-managed cookies. This does not independently expose a session to another origin, but it materially increases the consequences of cross-site scripting, a compromised third-party script, or another same-origin JavaScript execution vulnerability. Persistent storage also extends the period during which session material may remain available on shared or compromised devices. ### Attack Path 1. A user authenticates with Xaman and the SDK persists session material in `localStorage`. 2. An attacker obtains JavaScript execution in the application origin through an XSS flaw, compromised dependency, or malicious third-party script. 3. The attacker enumerates the origin's local-storage entries and retrieves accessible authentication or session data. 4. The attacker exfiltrates and attempts to replay that data or uses the compromised page to perform authenticated application actions. 5. Access continues until the affected session expires, is revoked, or is cleared through logout, subject to server-side validation and token restrictions. ### Impact Assessment Exploitati ...[truncated 500 chars]
Remediation
## Remediation Suggestions - Explicitly configure `rememberJwt: false` when persistent browser sessions are not required. - Avoid storing reusable authentication tokens in `localStorage`; prefer short-lived in-memory state or a server-managed session using `Secure`, `HttpOnly`, and appropriate `SameSite` cookies where the integration architecture permits. - Minimize token lifetime and scope, enforce audience and issuer validation, and rotate or revoke sessions after logout or suspected compromise. - Clear wallet-related client storage during logout and provide users with a mechanism to revoke active sessions. - Apply a restrictive Content Security Policy and comprehensive output encoding to reduce XSS risk. - Minimize third-party scripts and audit every script allowed to execute in the application origin. - Document the security tradeoff of session persistence instead of relying on the SDK's persistent default.

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.