Back to skill

Security audit

spawnxchange-awal

Security checks for vulnerabilities and agentic risk

Overview

The skill is a transparent guide for using a wallet CLI to buy, sell, upload, and manage marketplace listings, with financial and publishing risks disclosed enough for normal user review.

Install only if you are comfortable using awal for USDC payments, uploading the exact archive you choose, and trusting the pinned npm wallet CLI. Review archives carefully for secrets before listing, avoid logging command lines that contain listing bodies, and confirm item IDs before deletion or payment.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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
Findings (2)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:108
Finding
Global wallet CLI installation without cryptographic dependency verification## Vulnerability Details **File Location**: `SKILL.md`, lines 108–116 **Vulnerability Type**: Supply-chain exposure through a globally installed npm dependency **Risk Level**: Medium **Affected code:** ```bash npm install -g awal@2.12.1 awal --version ``` The surrounding instructions explain that this CLI signs payments: ```text Pinning matters here: this CLI signs payments, so resolving it through `npx` without a version would fetch whatever the registry serves at the moment you run it. Newer versions are usually fine — read the upstream release notes before moving the pin. ``` ### Technical Analysis The exact version pin is a useful safeguard against unexpected upgrades, but it does not authenticate the package contents against a project-controlled digest, signature, or lockfile. The skill directs the operator to install the package globally, potentially giving npm package installation and lifecycle scripts access to all resources available to the invoking user. This is particularly sensitive because `awal` is subsequently trusted to authenticate a wallet and sign USDC payment authorizations. A compromised npm account, malicious package version present before review, registry/source substitution, or compromised transitive dependency could place attacker-controlled code in the wallet execution path. A global installation also exceeds the minimum filesystem scope required to execute a project-specific CLI. Depending on the npm configuration and user account, it may require elevated installation privileges or modify a shared executable location. The skill does not instruct the user to use `sudo`, so administrative compromise is not guaranteed, but the installed package receives the privileges of whichever account performs the command. ### Attack Path 1. An attacker compromises the package publication pipeline, a dependency resolved by `awal@2.12.1`, or the registry/source used by npm. 2. The operator follows th ...[truncated 1131 chars]
Remediation
## Remediation Suggestions - Avoid a global installation where possible. Install the CLI into a dedicated, unprivileged project directory or isolated container. - Distribute and verify a project-controlled SHA-256 digest or trusted package signature before execution. - Provide a lockfile or equivalent dependency manifest that fixes the complete transitive dependency graph, not only the top-level package version. - Use npm provenance and signature verification when supported, and document the expected publisher and registry. - Initially install with lifecycle scripts disabled, where compatible: ```bash npm install --ignore-scripts --save-exact awal@2.12.1 ``` If lifecycle scripts are required, document and audit each script before allowing it to run. - Never recommend running the installation with `sudo`; use an unprivileged account with minimal access to unrelated credentials and files. - Verify the resolved package metadata and executable before entering wallet credentials or authorizing payments. - Prefer a vendor-supplied signed binary or a reproducible build whose digest can be independently checked.

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:358
Finding
Proprietary archive contents are exposed through process command-line arguments## Vulnerability Details **File Location**: `SKILL.md`, lines 358–385 **Vulnerability Type**: Sensitive-data exposure through process arguments **Risk Level**: Medium **Affected code:** ```bash python3 build_listing_body.py \ --archive ./my-artifact.zip \ --title "Invoice Parser" \ --description-file ./description.txt \ --tech-stack "Python, pdfplumber, Pydantic" \ --price-usdc 10 \ --out ./listing-body.json ``` ```bash awal x402 pay "$SX/api/v1/items" \ -X POST -d "$(cat ./listing-body.json)" \ -h '{"Content-Type":"application/json"}' \ --max-amount 50000 --json ``` The request body has the following documented structure: ```json { "compression": "zip", "file": "<base64 of the archive>", "metadata": { "title": "Invoice Parser", "description": "Parses PDF invoices into structured JSON...", "tech_stack": "Python, pdfplumber, Pydantic", "prices": { "USDC": 10 } } } ``` ### Technical Analysis `$(cat ./listing-body.json)` expands the complete JSON document before `awal` starts and supplies it as one command-line argument. The document includes a base64 representation of the entire code archive. Base64 is an encoding, not encryption, so any observer that obtains the argument can reconstruct the original archive. Process arguments may be visible through process inspection facilities such as `/proc`, process-monitoring software, audit logs, endpoint security products, crash diagnostics, or privileged process-listing tools. Visibility to unrelated unprivileged users depends on operating-system hardening and `/proc` configuration, but same-user and administrative monitoring exposure remains relevant. Uploading the selected archive to SpawnXchange is necessary for the declared selling functionality and is explicitly disclosed. The vulnerability is not the intended HTTPS upload itself; it is the unnecessary placement of the complete artifact in th ...[truncated 1789 chars]
Remediation
## Remediation Suggestions - Do not place the request body or archive contents in a command-line argument. - Add or use a wallet CLI option that reads the body from standard input: ```bash awal x402 pay "$SX/api/v1/items" \ -X POST --data-stdin \ -h '{"Content-Type":"application/json"}' \ --max-amount 50000 --json < ./listing-body.json ``` - Alternatively, support a file-reference option such as `--data-file ./listing-body.json` that opens the file internally rather than expanding it in the shell. - If `awal` cannot accept standard input or a file body, do not use this workflow for archive uploads. The document already mentions alternative wallet skills with file-upload support; make that the required route rather than limiting this warning only to larger files. - Create `listing-body.json` with restrictive permissions and remove it securely after a successful upload: ```bash umask 077 # Build and upload the request. rm -f ./listing-body.json ``` - Keep the explicit archive review and secret-scanning guidance, but clarify that automated checks are advisory and cannot guarantee removal of all confidential material. - Disable command-line collection for this operation in process accounting, shell tracing, CI logs, and observability agents where feasible. - Retain the HTTPS-only destination restriction and require explicit operator confirmation of the archive path, destination host, price, and payment limit before uploading.
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.