Back to skill

Security audit

Skill

Security checks across malware telemetry and agentic risk

Overview

This is a disclosed autonomous wallet skill, but it exposes high-impact financial signing and trading powers with weak scoping and risky installation/runtime trust boundaries.

Review this skill carefully before installing. Use only isolated hot wallets with limited funds, pin and verify package and CLI versions, set absolute verified paths for external binaries, avoid mnemonics unless required, and require human confirmation for transfers, approvals, trades, withdrawals, bridging, staking, and proxy upgrades.

Vulnerability Patterns
  • Tool Hijacking and SpoofingModifies or replaces tools so legitimate-looking calls execute attacker logic
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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:84
Finding
Unpinned Global Installation of a Security-Critical Wallet Dependency<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:80-88` and `SKILL.md:133-136` **Vulnerability Type**: Supply-chain exposure through an unpinned third-party dependency **Risk Level**: Medium ### Vulnerable Code ```json "install": [ { "id": "node", "kind": "node", "package": "evalanche", "bins": ["evalanche-mcp"], "label": "Install evalanche (npm)", }, ], ``` ```bash npm install -g evalanche ``` ### Technical Analysis The Skill directs users to install the latest registry-selected version of the `evalanche` npm package globally. Neither the installation metadata nor the setup command specifies an exact version, integrity hash, lockfile, verified source commit, or other immutable package identifier. The package is security-critical because it receives private keys or mnemonic phrases and can sign transactions, transfer assets, trade, bridge tokens, approve token spending, call arbitrary contracts, and upgrade UUPS proxies. Because the reviewed project contains only `SKILL.md`, the actual npm package implementation and its transitive dependency tree were not available for inspection. Global installation also expands the consequences of a supply-chain compromise: npm lifecycle scripts and the installed executable run under the installing user's account and may remain available to later sessions. This does not prove that the current package is malicious. It creates an unsafe trust boundary in which a future package release, compromised publisher account, malicious transitive dependency, or altered registry response could change the executed code after this Skill has been reviewed. ### Attack Path 1. An attacker compromises the npm publisher account, package distribution process, or a dependency used by `evalanche`. 2. The attacker publishes a malicious release under the legitimate package name. 3. A user or agent follows the documented `npm install -g evalanche` instruction. 4. npm selects the malic ...[truncated 1140 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Replace the unversioned package reference with an exact, audited version; do not use a floating range or `latest`. 2. Provide and verify the expected npm integrity hash or package signature before installation. 3. Use a lockfile and review the complete resolved transitive dependency tree. 4. Prefer a project-local installation over a global installation to reduce persistence and executable-shadowing risks. 5. Disable npm lifecycle scripts during installation where compatible, then explicitly run only reviewed setup steps. 6. Tie the package release to a reviewed source commit and document a reproducible-build or provenance verification process. 7. Include the security-critical implementation in the auditable Skill artifact, or otherwise provide immutable source references for every installed release. 8. Run the wallet process under a dedicated, least-privileged operating-system account with access only to its required keystore and network resources. 9. Re-audit each dependency update before changing the pinned version. ]]>

T07 · Tool Hijacking and Spoofing

Error
Location
SKILL.md:129
Finding
PATH-Resolved Polymarket Executable Receives Wallet Signer Material<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:67-71` and `SKILL.md:125-129` **Vulnerability Type**: Executable hijacking through unsafe PATH resolution **Risk Level**: High ### Vulnerable Code ```json { "name": "EVALANCHE_POLYMARKET_CLI_BIN", "description": "Absolute path to the official polymarket CLI binary. Optional if `polymarket` is already on PATH.", "required": false, }, ``` ```markdown ### Polymarket CLI Authenticated Polymarket MCP tools use the official `polymarket` CLI. Production agents should pin the binary path with `EVALANCHE_POLYMARKET_CLI_BIN`; otherwise Evalanche resolves `polymarket` from `PATH`. Signer material is passed through the child process environment and never through CLI arguments. ``` ### Technical Analysis Authenticated operations allow the `polymarket` executable to be selected through the process `PATH`. A name resolved through `PATH` does not establish that the selected file is the official CLI: an executable in an earlier directory can shadow the legitimate binary. The risk is amplified because signer material is deliberately inherited through the child process environment. Avoiding command-line arguments prevents exposure through process argument listings, but it does not protect secrets from the child process itself. Any executable selected under the name `polymarket` can directly read its environment. Pinning an absolute binary path is merely recommended for production rather than enforced for all authenticated operations. Even an absolute path should additionally be verified for expected ownership, permissions, signature, or cryptographic digest. ### Attack Path 1. An attacker gains the ability to place or replace an executable in a directory that appears before the legitimate Polymarket CLI in `PATH`. This could occur through a writable project directory, compromised dependency, user-local binary directory, or manipulated service environment. 2. The attacker names the executable `polymar ...[truncated 1477 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Prohibit PATH fallback for every authenticated Polymarket operation. 2. Require `EVALANCHE_POLYMARKET_CLI_BIN` to contain an absolute, canonical path before signer-dependent tools can run. 3. Verify the executable against an allowlisted cryptographic digest or trusted publisher signature before every launch or installation update. 4. Validate that the binary and all parent directories have trusted ownership and are not writable by untrusted users. 5. Launch the process with a minimal allowlisted environment rather than inheriting the parent environment. 6. Avoid giving raw private keys or mnemonic phrases to subprocesses. Prefer a narrowly scoped signing interface, hardware-backed signer, isolated signing service, or IPC protocol that approves only validated transaction payloads. 7. Run the CLI in a sandbox with restricted filesystem access, outbound network policy, and operating-system privileges. 8. Pin the exact CLI version and verify its provenance through a reproducible release artifact. 9. Fail closed if binary identity, path validation, signer isolation, or environment sanitization cannot be completed. 10. Log the verified executable path, version, and digest without logging signer material. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Rogue AgentSelf-Modification, Session Persistence
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Findings (5)

Context-Inappropriate Capability

High
Confidence
90% confidence
Finding
`approve_and_call` and especially `upgrade_proxy` materially expand the blast radius from ordinary wallet/DeFi actions to arbitrary token approvals and contract upgrade authority. In an autonomous-agent context, exposing these high-privilege primitives without prominently constraining who may invoke them can enable irreversible asset loss or malicious contract replacement if the agent is steered into unsafe actions.

Vague Triggers

Medium
Confidence
86% confidence
Finding
The activation guidance is extremely broad and covers many common wallet, trading, DeFi, and cross-chain contexts, increasing the chance the skill is invoked when a narrower or read-only tool would be safer. In an autonomous setting, overbroad routing can lead to unnecessary exposure of signing, transfer, approval, and trading capabilities.

Missing User Warnings

High
Confidence
95% confidence
Finding
The skill advertises many irreversible financial actions—token transfers, bridging, swaps, staking, perpetuals, validator operations, and proxy upgrades—without a prominent user-facing warning about finality, slippage, liquidation, bridge failure, or smart-contract risk. Because blockchain transactions are often irreversible, insufficient warnings materially increase the likelihood of harmful operator or agent decisions.

Missing User Warnings

Medium
Confidence
88% confidence
Finding
The documentation normalizes supplying raw private keys and especially mnemonics to the skill without strongly warning that these secrets grant full wallet control and may expose funds across chains. In this context, the risk is elevated because the skill is explicitly designed for autonomous transaction signing and persistent key management.

Session Persistence

Medium
Category
Rogue Agent
Content
1. **First run:** Generates a BIP-39 mnemonic via `ethers.HDNodeWallet.createRandom()`
2. **Encryption:** AES-128-CTR + scrypt KDF (geth-compatible keystore format)
3. **Password derivation:** 32-byte random entropy file via `crypto.randomBytes(32)`
4. **File permissions:** chmod 0o600 (owner read/write only)
5. **Storage location:** `~/.evalanche/keys/` by default

### MCP Server Access Controls
Confidence
84% confidence
Finding
The skill explicitly stores agent keys persistently in `~/.evalanche/keys/`, which creates session persistence for a signing identity beyond a single interaction. Although encrypted-at-rest storage is described, persistent wallet material increases exposure to local compromise, unintended reuse, and long-lived autonomous authority, making this more sensitive than ordinary application state.

VirusTotal

VirusTotal findings are pending for this skill version.

View on VirusTotal

Static analysis

No suspicious patterns detected.