Back to skill

Security audit

Token Launcher - Tator Launch Pad

Security checks for vulnerabilities and agentic risk

Overview

This instruction-only skill is coherent, but it guides users through irreversible token and fee transactions with externally constructed transaction payloads and incomplete mandatory validation controls.

Install only if you are comfortable with a third-party service or SDK preparing blockchain transactions. Use a dedicated minimally funded wallet, pin dependencies, verify endpoints and contract addresses independently, decode and simulate every transaction, and require human approval before any signing, fee-recipient change, claim, or deployment.

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
references/clanker.md:14
Finding
Unpinned Third-Party Packages Installed in Wallet-Enabled Applications<![CDATA[ ## Vulnerability Details **File Locations**: - `references/clanker.md:14` - `references/flaunch.md:14` - `references/pumpfun.md:14` **Vulnerability Type**: Supply-chain exposure through mutable dependency versions **Risk Level**: Medium ### Vulnerable Code `references/clanker.md:14`: ```bash npm install clanker-sdk viem ``` `references/flaunch.md:14`: ```bash npm install viem ``` `references/pumpfun.md:14`: ```bash npm install @solana/web3.js @solana/spl-token ``` ### Technical Analysis The setup commands install the latest package versions available at execution time without exact version or integrity pinning. Consequently, the dependency code installed by two users at different times may differ from the code reviewed during this audit. These packages are intended to run inside applications that load blockchain transaction-signing keys and construct or submit financial transactions. A malicious or compromised package release could therefore operate within a security-sensitive process. Although `REFERENCE.md` recommends auditing third-party SDKs and pinning versions, the actual installation examples do not enforce those controls. The finding does not establish that the named packages are currently malicious. The vulnerability is the unsafe, mutable dependency-resolution process documented by the Skill. ### Attack Path 1. An attacker compromises a listed package, one of its transitive dependencies, or a maintainer account. 2. The attacker publishes a malicious release under the legitimate package name. 3. A user follows one of the documented unversioned `npm install` commands. 4. npm resolves the dependency to the compromised release. 5. The package executes in an application that has access to a launch-wallet key and RPC connectivity. 6. The malicious code reads signing material, changes transaction calldata or recipients, or submits unauthorized transactions. 7. The attacker steals the minimally funded wallet balance, redirects creator f ...[truncated 806 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Replace all unversioned package commands with exact, reviewed versions, for example: ```bash npm install --save-exact clanker-sdk@REVIEWED_VERSION viem@REVIEWED_VERSION ``` 2. Generate and commit `package-lock.json`, and use `npm ci` in automated and production environments. 3. Pin direct dependencies and review transitive dependency changes before updating the lockfile. 4. Verify npm package ownership, provenance, integrity hashes, repository links, and release history. 5. Run dependency scanning and lockfile-diff review in CI. 6. Disable unnecessary lifecycle scripts where operationally possible, or review package lifecycle scripts before installation. 7. Isolate wallet-signing functionality in a least-privileged process with only the required secrets and network access. 8. Continue using a dedicated, minimally funded launch wallet, and rotate it immediately if dependency compromise is suspected. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:102
Finding
Externally Constructed Transactions Can Be Signed Without Mandatory Semantic Validation<![CDATA[ ## Vulnerability Details **File Locations**: - `SKILL.md:102-108` - `SKILL.md:165-174` - `SKILL.md:223` **Vulnerability Type**: Unsafe trust in externally supplied blockchain transactions **Risk Level**: High ### Vulnerable Code and Instructions `SKILL.md:102-108`: ```text When you call the Tator x402 API (`POST https://x402.quickintel.io/v1/tator/prompt`): 1. Sent to Tator: `walletAddress` (public address — not sensitive), `prompt` (your instruction), `provider` (your agent name) 2. NOT sent to Tator: Your private key, seed phrase, or any signing material 3. x402 payment: Your wallet provider signs a USDC authorization locally → the signed payment header is sent with the request. The API verifies the signature on-chain — it never has your key 4. Returned to you: Unsigned transaction(s) — you sign locally and broadcast yourself ``` `SKILL.md:165-174`: ```bash curl -X POST https://x402.quickintel.io/v1/tator/prompt \ -H "Content-Type: application/json" \ -H "PAYMENT-SIGNATURE: <x402_payment>" \ -d '{ "prompt": "launch a token called Galaxy Cat with ticker GCAT on base", "walletAddress": "0xYourWallet", "provider": "my-agent" }' ``` `SKILL.md:223`: ```text The response includes unsigned transaction(s) for your wallet to sign and broadcast. After confirmation, you'll get back the deployed token address, transaction hash, and fee configuration details. ``` ### Technical Analysis Local signing protects the confidentiality of the private key, but it does not establish that a transaction supplied by an external service is safe. A valid local signature authorizes the transaction’s actual encoded behavior, regardless of the natural-language request that preceded it. The documented Easy Mode delegates transaction construction to `x402.quickintel.io` and then directs the wallet to sign and broadcast the response. It does not require the client to: - Verify the expected chain ID. - Restrict destination addresses to verified platfor ...[truncated 2390 chars]
Remediation
<![CDATA[ ## Remediation Suggestions Implement a mandatory transaction-validation layer before any signature request: 1. **Enforce chain allowlists** - Require the returned chain ID to match the user-selected network. - Reject missing, unsupported, or changed chain IDs. 2. **Enforce destination allowlists** - Maintain verified contract addresses per platform and chain. - Reject transactions targeting unknown addresses. - Verify addresses independently against official documentation and block explorers. 3. **Decode transaction calldata** - Validate the function selector against an explicit allowlist. - Decode every argument using a locally trusted ABI. - Reject unknown functions, malformed calldata, delegate calls, arbitrary multicalls, and unexpected nested actions. 4. **Validate financial parameters** - Verify native-token value and token-transfer amounts against expected limits. - Reject unexpected approvals and unlimited allowances. - Verify creator, administrator, treasury, shareholder, and fee-recipient addresses. - Verify that fee shares total the expected amount and match the user-approved configuration. 5. **Simulate before signing** - Simulate against a trusted RPC endpoint. - Inspect balance changes, approvals, emitted events, contract creation, and expected state changes. - Reject transactions whose simulation differs from the requested operation. 6. **Require informed approval** - Display the decoded chain, destination, function, value, recipients, fee allocation, approvals, and administrative changes. - Require explicit human confirmation for deployment, fee-recipient updates, approvals, and asset transfers. 7. **Apply transaction limits** - Set maximum native value, gas, fees, and token amounts. - Reject additional transactions not necessary for the requested operation. 8. **Treat API responses as untrusted input** - Validate the response schema strictly. - Do not automatically sig ...[truncated 151 chars]
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (3)

External Transmission

Medium
Category
Data Exfiltration
Content
After deploying via any platform, run a Quick Intel scan to verify the contract looks clean from an external perspective:

```bash
curl -X POST https://x402.quickintel.io/v1/scan/full \
  -H "Content-Type: application/json" \
  -H "PAYMENT-SIGNATURE: <x402_payment>" \
  -d '{"chain": "base", "tokenAddress": "0xYourDeployedToken"}'
Confidence
60% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Vague Triggers

Medium
Confidence
95% confidence
Finding
The trigger list includes broad phrases such as "token idea," "token strategy," and especially "is this a good token," which can cause the skill to activate in contexts where a user is only seeking discussion or analysis rather than token deployment tooling. In an agent environment with wallet capabilities, unintended invocation increases the chance that the agent moves from advisory conversation into transactional or externally connected behavior without sufficient user intent verification.

External Transmission

Medium
Category
Data Exfiltration
Content
### Launch a Token

```bash
curl -X POST https://x402.quickintel.io/v1/tator/prompt \
  -H "Content-Type: application/json" \
  -H "PAYMENT-SIGNATURE: <x402_payment>" \
  -d '{
Confidence
88% confidence
Finding
The skill provides direct instructions to send user prompts and wallet-associated metadata to an external endpoint, which creates a real external data transmission and action-initiation path. In the context of a token-launching skill, this is more dangerous because the external service returns unsigned transactions intended for signing, so an agent could be induced to initiate sensitive blockchain operations or disclose prompts, addresses, and payment authorization artifacts to a third party.

Static analysis

No suspicious patterns detected.