Back to skill

Security audit

The Swarm

Security checks for vulnerabilities and agentic risk

Overview

The skill is transparent about joining an external crypto service, but its example asks an agent to manage a wallet and automatically sign server-provided data with limited validation guidance.

Install only if you are comfortable using a dedicated, low-value Solana wallet for this service. Do not reuse a wallet with funds or existing authority, pin and review npm dependencies before running the example, and add strict challenge validation before allowing an agent to sign anything automatically.

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:173
Finding
Unpinned Third-Party Cryptographic Dependencies## Vulnerability Details **File Location**: `SKILL.md`, lines 173-177 **Vulnerability Type**: Supply-chain exposure through unpinned third-party dependencies **Risk Level**: Medium ```javascript const nacl = require('tweetnacl'); const bs58 = require('bs58'); const bip39 = require('bip39'); const { Keypair } = require('@solana/web3.js'); const { derivePath } = require('ed25519-hd-key'); ``` ### Technical Analysis The example delegates wallet generation, key derivation, and cryptographic signing to five npm packages. The Skill does not provide a reviewed `package.json`, lockfile, exact package versions, integrity hashes, or a controlled installation procedure. Because these dependencies process the wallet mnemonic, seed, or private key in memory, compromise or substitution of any relevant package or transitive dependency could expose the wallet. Resolving unconstrained package versions also means that code executed by future installations may differ from the code originally reviewed. ### Attack Path 1. An attacker compromises a named package, one of its transitive dependencies, or the dependency-resolution channel. 2. The agent installs or resolves the affected package without an audited lockfile or integrity enforcement. 3. Malicious installation or runtime code executes with the agent's local privileges. 4. The compromised dependency reads the generated mnemonic, derived seed, private key, or wallet file. 5. The dependency transmits that material to the attacker. 6. The attacker reconstructs the wallet and can authorize transactions using its private key. ### Impact Assessment Successful exploitation could execute arbitrary package code with the privileges of the account running the Skill. It could compromise the locally generated wallet, disclose its mnemonic or private key, and permit theft of any assets assigned to that wallet. Local files and environment data accessible to the same process could also be ex ...[truncated 130 chars]
Remediation
## Remediation Suggestions - Provide a reviewed `package.json` and lockfile containing exact dependency and transitive-dependency versions. - Require deterministic installation with `npm ci` rather than unconstrained package resolution. - Preserve and verify registry integrity metadata and use only the expected official package registry. - Audit dependencies and their installation scripts before use; disable lifecycle scripts where they are unnecessary. - Regularly scan the locked dependency graph for known vulnerabilities and unexpected ownership or publication changes. - Run wallet operations in a restricted environment with minimal filesystem and network access. - Use a dedicated wallet for this service and explicitly warn users not to import or reuse a wallet holding valuable assets.

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:199
Finding
Automatic Signing of Unvalidated Server-Controlled Challenge Data## Vulnerability Details **File Location**: `SKILL.md`, lines 199-210 **Vulnerability Type**: Unvalidated remote input passed to a sensitive cryptographic operation **Risk Level**: Medium ```javascript // Get challenge const challengeRes = await fetch( `${BASE_URL}/api/auth/cli?wallet=${walletAddress}` ); const { challenge } = await challengeRes.json(); // Sign challenge const messageBytes = new TextEncoder().encode(challenge); const signature = nacl.sign.detached(messageBytes, keypair.secretKey); const signatureBase58 = bs58.encode(Buffer.from(signature)); ``` ### Technical Analysis The example signs the `challenge` value returned by the external service without first checking the HTTP status, content type, data type, length, or expected challenge structure. It does not verify that the message contains the intended domain, authentication purpose, wallet address, issuance time, nonce, or valid expiration time. Although the documentation shows an expected challenge format, the executable example does not enforce that format. Consequently, the remote endpoint controls the bytes signed by the wallet key. This exceeds the minimum safe authority required for authentication because the agent should sign only a narrowly defined, validated authentication statement. The code uses a detached Ed25519 signature and does not itself submit a Solana transaction. Nevertheless, automatically signing arbitrary statements creates cross-protocol and authorization risk if another system accepts the resulting signature or if challenge semantics change. ### Attack Path 1. The external service is compromised, returns an unexpected response, or an attacker otherwise gains control over the challenge supplied to the client. 2. The attacker provides a chosen message instead of the expected authentication challenge. 3. The script parses the value and signs it automatically with `keypair.secretKey`. 4. The signature is encoded and subse ...[truncated 838 chars]
Remediation
## Remediation Suggestions - Check that the response has a successful HTTP status and the expected JSON content type before parsing it. - Validate that `challenge` is a string with a strict maximum length. - Define and enforce a versioned challenge schema rather than signing unrestricted text. - Verify the expected service domain, authentication purpose, wallet address, nonce, issuance time, and expiration. - Reject expired challenges, wallet mismatches, duplicate nonces, unknown fields, and messages that do not exactly match the approved canonical format. - Add explicit domain separation so the signature cannot be confused with a transaction or authorization for another application. - Require user approval before signing any challenge that differs from the recognized format. - Use a dedicated, low-value wallet that is not reused by other services. - Avoid logging signatures or complete authentication responses unless necessary, and redact sensitive authentication artifacts from diagnostic output.
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)

External Transmission

Medium
Category
Data Exfiltration
Content
⚠️ **IMPORTANT**: Always use `www.jointheaiswarm.com` — the non-www version redirects and can cause JSON parse errors!

```bash
curl "https://www.jointheaiswarm.com/api/auth/cli?wallet=YOUR_WALLET_ADDRESS"
```

Response:
Confidence
60% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Static analysis

No suspicious patterns detected.