launch-bnb-token-on-flap

• Outcome: Review
• Latest audit: Sep 16, 2026 · 4:13 AM UTC
• Version: 1.3.0

Overview

This skill mostly matches its token-launch purpose, but it can guide an agent into irreversible crypto transactions using unverified vault contracts and an unpinned npm install.

Review the final transaction carefully before signing, especially `to`, `chainId`, `quoteToken`, `quoteAmt`, `beneficiary`, `vaultFactory`, and `vaultData`. Prefer official vault factories, avoid custom factory addresses unless you independently verify them, and install dependencies from a pinned, trusted environment rather than running a fresh unpinned npm install during a token launch.

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 (2)

T08 · Insecure Dependencies

Warning

• Location: references/preflight.md:8
• Finding: Unpinned npm Dependency Installation Enables Supply-Chain Code Execution<![CDATA[ ## Vulnerability Details **File Location**: `references/preflight.md:8-14` **Vulnerability Type**: Unpinned third-party dependency installation **Risk Level**: Medium ### Vulnerable Code ```bash node -e "require('viem')" 2>/dev/null && echo OK || echo MISSING ``` If missing, install it: ```bash npm install viem ``` ### Technical Analysis The Skill instructs the Agent to install `viem` without specifying an exact version, lockfile, package integrity hash, trusted registry, or lifecycle-script policy. Consequently, the package and its transitive dependencies are resolved dynamically at execution time. This installation is necessary only when `viem` is unavailable, but resolving a mutable latest version is not the minimum-risk method required for the Skill's transaction-construction functionality. npm packages and transitive dependencies can execute lifecycle scripts during installation. A compromised package release, dependency, registry account, registry mirror, or local npm configuration could therefore turn this instruction into arbitrary local code execution. The command also does not use `npm ci` or `--ignore-scripts`, and the reviewed project contains no lockfile establishing a reproducible dependency graph. ### Attack Path 1. An attacker compromises a future `viem` release, one of its resolved dependencies, the configured npm registry, or a registry account. 2. The Skill checks for `viem` and determines that it is missing. 3. Following the documented workflow, the Agent runs `npm install viem`. 4. npm retrieves the currently resolved package graph rather than a reviewed, immutable version. 5. A malicious package lifecycle script executes during installation. 6. The payload runs with the operating-system permissions of the Agent or user that invoked npm. ### Impact Assessment Successful exploitation could execute arbitrary commands with the invoking user's privileges. Depending on the execution environment, the malicious package could ...[truncated 475 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin `viem` to a reviewed exact version instead of installing the latest release: ```bash npm install --save-exact viem@<reviewed-version> ``` 2. Include and review a lockfile, then use reproducible installation: ```bash npm ci ``` 3. Disable lifecycle scripts where they are unnecessary: ```bash npm ci --ignore-scripts ``` 4. Document and enforce the expected npm registry, and reject unexpected registry overrides. 5. Verify package integrity through the committed lockfile and periodically audit the pinned dependency graph. 6. Prefer requiring callers to provide a preinstalled, approved dependency environment rather than modifying the environment automatically. 7. Never run dependency installation as root or another privileged account. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: references/vault-factory.md:16
• Finding: Unverified Vault Factories Can Be Inserted into Financial Transaction Calldata<![CDATA[ ## Vulnerability Details **File Location**: `references/vault-factory.md:16-20` and transaction sink at `references/construct-tx.md:119` **Vulnerability Type**: Insufficient validation of attacker-controlled smart-contract addresses **Risk Level**: Medium ### Vulnerable Code ```markdown Any vault factory address is accepted — unregistered or unverified factories can be used, but the resulting vault will be marked unverified in the UI. ## Step 2 — Read the factory's vaultData schema Call `vaultDataSchema()` on the factory contract to determine what fields are required and how `vaultData` must be encoded. ``` The supplied address is later inserted directly into launch calldata: ```typescript vaultFactory: vaultFactoryAddress, vaultData, // encoded bytes from vault-factory.md ``` ### Technical Analysis The workflow explicitly accepts arbitrary, unregistered, or unverified vault factory addresses. Its principal validation step is to call the factory's self-reported `vaultDataSchema()` method and encode values according to the returned schema. A schema returned by the candidate contract only describes what that contract claims to require. It does not establish that: - the factory is authentic; - its runtime bytecode matches a reviewed implementation; - it deploys the expected vault type; - its revenue-distribution behavior matches the schema description; - it lacks upgradeable or privileged behavior that can alter the result; or - the generated transaction will route revenue as the user intends. The unverified address is subsequently embedded in the signed `newTokenV6WithVault` transaction. Displaying an “unverified” warning in a user interface does not provide a security boundary at transaction-construction time. ### Attack Path 1. An attacker persuades the user or Agent to use a custom vault factory address. 2. The malicious contract implements `vaultDataSchema()` and returns plausible field names, types, and ...[truncated 1092 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Default to an explicit allowlist of audited factory addresses for BNB Chain mainnet. 2. Verify all of the following before using a factory: - chain ID is exactly `56`; - deployed runtime bytecode is present; - runtime bytecode hash matches an approved release; - proxy implementation and administrator addresses are known, where applicable; - the source code and audit identity correspond to the expected factory. 3. Treat `vaultDataSchema()` only as an encoding aid, not as proof of safety or authenticity. 4. For a custom factory, stop the automatic workflow and require explicit informed user confirmation that includes: - factory address; - verification status; - implementation address; - upgradeability and administrator status; - expected revenue recipients and proportions; - transaction simulation results. 5. Simulate the complete launch transaction against a trusted BNB Chain RPC before requesting a signature. 6. Decode and present the final transaction parameters, including `vaultFactory` and `vaultData`, for independent user verification. 7. Reject unverified factories by default rather than relying on a downstream UI warning. ]]>

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• 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

Static analysis

No suspicious patterns detected.