Nla Create

• Outcome: Review
• Latest audit: Sep 11, 2026 · 6:06 PM UTC
• Version: 1.0.0

Overview

The skill does what it claims, but it asks agents to handle blockchain wallet operations in ways that can expose private keys or create unsafe transactions.

Review this skill carefully before installing. Use a dedicated low-value wallet, avoid pasting private keys into chat or command lines, verify the nla package source and version, and independently confirm the network, token, amount, oracle, and transaction details before signing.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (3)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:7
• Finding: Unpinned Globally Installed Third-Party CLI<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:7` **Vulnerability Type**: Unpinned third-party dependency and unsafe global installation **Risk Level**: Medium ### Vulnerable Code Snippet ```yaml compatibility: Requires nla CLI installed (npm install -g nla). Requires a funded Ethereum wallet and access to an EVM chain. ``` ### Technical Analysis The skill requires installation of the unscoped `nla` npm package without specifying an exact version, integrity hash, verified source repository, or trusted publisher. The suggested global installation also allows npm package lifecycle scripts to execute with the installing user's privileges. Because no version is pinned, the code installed during one deployment may differ from the version reviewed during the audit. A malicious publication, compromised maintainer account, dependency compromise, or package-name takeover could therefore introduce arbitrary code into the environment. The affected CLI subsequently processes wallet information and submits blockchain transactions, making supply-chain integrity particularly important. ### Attack Path 1. An attacker compromises the `nla` package, one of its transitive dependencies, or its publishing account. 2. The attacker publishes a malicious package version containing an installation lifecycle script or modified CLI implementation. 3. A user follows the skill documentation and executes `npm install -g nla`. 4. npm downloads the latest matching package and may execute attacker-controlled lifecycle scripts. 5. The malicious code executes with the user's privileges and can inspect local files, environment variables, wallet configuration, or transaction parameters. 6. Later `nla` commands may spoof transaction details, steal credentials, or redirect escrow operations. ### Impact Assessment Successful exploitation provides code execution with the privileges of the user installing or invoking the CLI. The accessible scope may include user files, environ ...[truncated 265 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Pin the CLI to a specific audited version rather than installing the latest release. - Record and verify package integrity hashes through a lockfile or equivalent integrity mechanism. - Document the official package registry, publisher identity, and source repository. - Prefer a project-local installation over a global installation. - Review the CLI and its transitive dependencies before use. - Disable npm lifecycle scripts where compatible, such as with `--ignore-scripts`, and separately run only explicitly audited setup operations. - Execute the CLI in a restricted environment with access only to the files and credentials required for the transaction. - Require users to verify transaction destination, token, amount, oracle, network, and calldata independently before signing. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:39
• Finding: Private Key Exposure Through Command-Line Arguments<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:39-42` **Vulnerability Type**: Plaintext secret exposure through process arguments and environment variables **Risk Level**: High ### Vulnerable Code Snippet ```markdown If no wallet is configured, the user must either: - Run `nla wallet:set --private-key <key>` - Pass `--private-key <key>` to the command - Set the `PRIVATE_KEY` environment variable ``` ### Technical Analysis The documentation recommends passing a wallet private key directly as a command-line argument. Command-line arguments can be retained in shell history, terminal recordings, automation logs, agent transcripts, crash reports, and process-monitoring systems. Depending on the operating system and process permissions, other local users or processes may also be able to inspect the command line while it is running. The environment-variable alternative is safer than a literal shell argument in some environments but remains sensitive. Environment variables can be inherited by child processes, exposed through debugging or diagnostic output, captured by CI systems, or unintentionally written to logs. A blockchain private key is a bearer credential. Disclosure allows an attacker to sign transactions without further authentication, and blockchain transfers are generally irreversible. ### Attack Path 1. A user follows the documented example and enters `nla wallet:set --private-key <key>` or supplies the key to another CLI command. 2. The plaintext key is stored in shell history, captured in a tool transcript, exposed in a process listing, or collected by terminal or CI logging. 3. An attacker with access to that history, log, transcript, or process metadata extracts the key. 4. The attacker imports the key into another wallet or signing utility. 5. The attacker signs unauthorized token approvals or transfers and moves assets to an attacker-controlled address. For the environment-variable variant, an attacker may instead obtain the k ...[truncated 630 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Remove all recommendations to pass private keys through command-line arguments. - Use hidden interactive input that does not echo the key and does not persist it in shell history. - Prefer hardware wallets, operating-system credential stores, encrypted keystores, or external signing services. - If environment variables must be supported, treat them only as a compatibility fallback and document their inheritance and logging risks. - Ensure the agent never requests, displays, records, or repeats a private key in prompts, tool calls, output, or transcripts. - Use a dedicated low-value wallet with narrowly limited funds and permissions for escrow operations. - Add explicit instructions to rotate a key immediately if it is entered into a command line or exposed to an agent transcript. - Require transaction simulation and explicit user confirmation on a trusted signing device before broadcasting. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:56
• Finding: Shell Command Injection Through Unescaped Escrow Parameters<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:56-64` **Vulnerability Type**: Shell command injection through uncontrolled natural-language arguments **Risk Level**: High ### Vulnerable Code Snippet ```bash nla escrow:create \ --demand "<demand text>" \ --amount <amount> \ --token <token_address> \ --oracle <oracle_address> \ [--arbitration-provider "<provider>"] \ [--arbitration-model "<model>"] \ [--arbitration-prompt "<prompt>"] ``` ### Technical Analysis The skill directs an agent to insert user-controlled values into a Bash command template. The demand and arbitration prompt are unrestricted natural-language strings. Placing them between literal double quotes does not make arbitrary shell content safe: embedded quote characters can terminate the intended argument, and shell constructs such as command substitution may be evaluated when a generated command is interpreted by Bash. The amount, address, provider, and model fields also require strict validation. If the implementation constructs one command string and passes it to a shell, metacharacters in any insufficiently validated field may alter command structure, add arguments, redirect output, or execute additional commands. The declared `Bash(nla:*)` restriction does not by itself eliminate this risk. A tool policy that authorizes a command based only on its visible prefix may still permit shell syntax appended after or embedded within the arguments. ### Attack Path 1. An attacker supplies a crafted demand or arbitration prompt containing quote-breaking text and shell syntax. 2. The agent substitutes that text directly into the documented Bash template. 3. The generated string is executed by a shell rather than passed to the CLI as a structured argument array. 4. The malicious text escapes the intended argument boundary or triggers shell command substitution. 5. Bash executes an attacker-selected command with the agent process's local privileges. 6. The command can r ...[truncated 768 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Do not build a single shell command by concatenating or interpolating user-controlled strings. - Invoke `nla` directly through a process API that accepts an argument array and does not use a shell. - If Bash is unavoidable, apply robust shell escaping to every dynamic argument and reject newline and control characters; argument-array execution remains preferable. - Validate `amount` as a bounded non-negative integer in the token's smallest unit. - Validate token and oracle values as exact EVM addresses before execution. - Restrict provider and model values to explicit allowlists. - Treat demand and prompt values as opaque data, not executable command fragments. - Consider passing long natural-language values through a safely opened input file or standard input if the CLI supports it. - Display the final structured arguments and blockchain transaction details for user confirmation without exposing secrets. - Add tests containing embedded quotes, backticks, command substitutions, semicolons, newlines, redirections, and option-injection payloads. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (1)

Missing User Warnings

Medium

• Confidence: 97% confidence
• Finding: The skill explicitly instructs the user to supply a private key via command line flag or environment variable without a prominent warning about credential exposure. Passing private keys on the CLI can leak them through shell history, process listings, terminal logs, agent transcripts, or tool telemetry, which is especially dangerous here because the key controls blockchain funds and can enable irreversible asset theft.

Static analysis

No suspicious patterns detected.