Back to skill

Security audit

Tokenized agents pump.fun

Security checks for vulnerabilities and agentic risk

Overview

The skill is coherently about Solana wallet payments, but it tells agents to follow changeable remote instructions in a payment flow.

Review this skill before installing in production payment projects. Prefer a version that uses the bundled reference files or commit-pinned links, pin npm dependencies with a lockfile, disclose wallet auto-reconnect behavior, and verify that every transaction shown to the user matches the intended amount, currency, and recipient before signing.

Vulnerability Patterns
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (3)

T01 · Skill Instruction Hijacking

Warning
Location
SKILL.md:124
Finding
Mandatory Use of Mutable Remote Instructions<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:124` and `SKILL.md:420` **Vulnerability Type**: Mutable external instructions can alter the behavior of an agent after the local Skill has been reviewed **Risk Level**: Medium ### Vulnerable Code ```md Install `@solana/wallet-adapter-react`, `@solana/wallet-adapter-react-ui`, and `@solana/wallet-adapter-wallets`. Use `useWallet()` for `publicKey` and `signTransaction`, and `useConnection()` for the active RPC connection. MUST See [https://raw.githubusercontent.com/pump-fun/pump-fun-skills/refs/heads/main/tokenized-agents/references/WALLET_INTEGRATION.md](https://raw.githubusercontent.com/pump-fun/pump-fun-skills/refs/heads/main/tokenized-agents/references/WALLET_INTEGRATION.md) for the full WalletProvider setup, layout wrapping, and hook usage. ``` ```md See [https://raw.githubusercontent.com/pump-fun/pump-fun-skills/refs/heads/main/tokenized-agents/references/SCENARIOS.md](https://raw.githubusercontent.com/pump-fun/pump-fun-skills/refs/heads/main/tokenized-agents/references/SCENARIOS.md) for detailed test scenarios (happy path, duplicate rejection, expired invoices, etc.) and a troubleshooting table for common errors and for wallet Integration must follow [https://raw.githubusercontent.com/pump-fun/pump-fun-skills/refs/heads/main/tokenized-agents/references/WALLET_INTEGRATION.md](https://raw.githubusercontent.com/pump-fun/pump-fun-skills/refs/heads/main/tokenized-agents/references/WALLET_INTEGRATION.md). ``` ### Technical Analysis The Skill directs the agent to retrieve and follow documentation from the mutable `main` branch of an external GitHub repository. The wording “MUST See” and “must follow” gives the remote content authoritative control over the agent's implementation behavior. Because the URLs reference a branch rather than an immutable commit, their contents can change after the local Skill package has been audited. This bypasses the trust boundary established by reviewing the bund ...[truncated 1473 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Replace remote branch URLs with relative references to the bundled files: - `references/WALLET_INTEGRATION.md` - `references/SCENARIOS.md` 2. Remove language requiring the agent to retrieve mutable external instructions. 3. If remote retrieval is operationally necessary, pin each URL to a reviewed Git commit hash rather than `refs/heads/main`. 4. Verify downloaded content against a cryptographic digest before processing it. 5. Treat remotely retrieved documentation as untrusted data and explicitly prohibit it from overriding system, developer, security, or local Skill instructions. 6. Review and publish updated local Skill releases when documentation changes instead of changing effective behavior remotely. ]]>

T08 · Insecure Dependencies

Warning
Location
references/WALLET_INTEGRATION.md:6
Finding
Wallet Dependencies Are Installed Without Version or Integrity Pinning<![CDATA[ ## Vulnerability Details **File Location**: `references/WALLET_INTEGRATION.md:6` **Vulnerability Type**: Unpinned security-sensitive npm dependencies **Risk Level**: Medium ### Vulnerable Code ```bash npm install @solana/wallet-adapter-react @solana/wallet-adapter-react-ui @solana/wallet-adapter-wallets ``` ### Technical Analysis The installation command does not specify versions and the project contains no audited lockfile in the reviewed directory. Consequently, package resolution depends on the registry state at installation time and may select releases that differ from those originally reviewed or tested. npm packages may execute lifecycle scripts during installation and subsequently run inside the wallet-facing application. These packages are particularly security-sensitive because they participate in wallet connection and transaction-signing workflows. The audit did not establish that any named package is malicious. The confirmed weakness is non-reproducible dependency resolution and the resulting exposure to future compromised, vulnerable, or behaviorally incompatible releases. ### Attack Path 1. A package publisher account or an upstream package is compromised, or a future release introduces malicious or vulnerable code. 2. A user follows the documented command after the affected release becomes the registry-selected version. 3. npm downloads the changed package and its transitive dependency graph. 4. Any enabled lifecycle scripts execute with the privileges of the user running npm. 5. The dependency later runs in the application and may influence wallet connectivity or transaction-signing behavior. ### Impact Assessment Installation-time code runs with the local privileges of the developer or build account and can generally access files, environment variables, and network resources available to that account. Runtime browser code can interact with the application's wallet workflow and data exposed to the frontend. The exact impact d ...[truncated 246 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Pin every wallet adapter package to an exact, reviewed version rather than relying on registry defaults. 2. Commit a package lockfile containing npm integrity hashes. 3. Use `npm ci` in CI and production builds so installation fails if the lockfile and manifest differ. 4. Review transitive dependencies and package lifecycle scripts before adoption. 5. Use `npm install --ignore-scripts` where lifecycle scripts are not required, or explicitly allow only reviewed scripts. 6. Run dependency installation in an isolated, least-privileged build environment without wallet secrets or production credentials. 7. Enable automated vulnerability and unexpected dependency-change monitoring. 8. Keep the wallet adapter versions aligned with the payment SDK's supported Solana dependency versions. ]]>

T08 · Insecure Dependencies

Note
Location
SKILL.md:71
Finding
Core Solana Dependency Resolution Is Not Fully Reproducible<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:71-82` **Vulnerability Type**: Mutable version ranges and dynamic dependency-selection guidance **Risk Level**: Low ### Vulnerable Code ```bash npm install @pump-fun/agent-payments-sdk@3.0.0 @solana/web3.js@^1.98.0 ``` ```md 1. Before installing `@solana/web3.js`, `@solana/spl-token`, or any `@solana/wallet-adapter-*` package, first check what versions `@pump-fun/agent-payments-sdk` declares in its own `package.json` (inspect it via `npm info @pump-fun/agent-payments-sdk dependencies`). Install the same ranges — or ranges that resolve to the same major.minor — so npm/pnpm hoists a single copy instead of two. 2. Never blindly install "latest" for these shared packages. Always prefer the version that is most compatible with the latest `@pump-fun/agent-payments-sdk`. 3. If the project already has these packages at different versions, align them to match the SDK and re-install. ``` ### Technical Analysis Although `@pump-fun/agent-payments-sdk` is pinned to version `3.0.0`, `@solana/web3.js` uses the compatible-release range `^1.98.0`. Installations at different times may therefore resolve to different releases. The guidance also tells the agent to query current registry metadata and select compatible ranges. Registry metadata and the meaning of “latest” are mutable, so the final dependency graph is not completely determined by the audited Skill. The document correctly warns against blindly installing latest versions, which reduces risk, but it does not require exact versions, a committed lockfile, or integrity verification. Since these libraries construct and submit payment transactions, unexpected dependency changes have elevated security relevance. ### Attack Path 1. A new release satisfying `^1.98.0` is published, or registry metadata changes. 2. A user follows the Skill without an existing lockfile. 3. npm resolves a dependency version different from the one used during the Skill's review. ...[truncated 719 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Replace `@solana/web3.js@^1.98.0` with an exact version that has been tested with `@pump-fun/agent-payments-sdk@3.0.0`. 2. Pin exact versions for all direct Solana and wallet dependencies. 3. Commit and enforce a lockfile with integrity hashes. 4. Replace “latest” compatibility guidance with a documented compatibility matrix of reviewed exact versions. 5. Use `npm ci` for reproducible installation. 6. Require a security review and test run before updating any dependency or lockfile. 7. Isolate installation in a least-privileged environment and restrict unnecessary lifecycle scripts and network access. ]]>
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • 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 (3)

Whitespace Padding

Medium
Category
Prompt Injection
Content
### Parameters (`BuildAcceptPaymentParams`)

| Parameter          | Type                         | Description                                                                                          |
| ------------------ | ---------------------------- | ---------------------------------------------------------------------------------------------------- |
| `user`             | `PublicKey`                  | The payer's wallet address                                                                           |
| `currencyMint`     | `PublicKey`                  | Mint address of the payment currency (USDC, wSOL)                                                    |
Confidence
70% confidence
Finding
Large whitespace padding was detected (a block of blank lines or a long run of spaces). This can push injected instructions below or to the right of the visible area so a human reviewer never sees them while the agent still reads them. Manual review of the hidden content is recommended.

Missing User Warnings

Medium
Confidence
84% confidence
Finding
The markdown instructs users to enable `autoConnect` on the wallet provider, which can automatically reconnect to a previously selected wallet when the app loads. The document does not warn that this affects wallet connection behavior or user privacy expectations, even though it changes how the application interacts with the user's wallet.

Natural-Language Policy Violations

Low
Confidence
91% confidence
Finding
The layout example sets `<html lang="en">`, which enforces an English locale in the sample without mentioning user selection or a region-specific requirement. Under the policy, language constraints should either be optional for the user or clearly justified.

Static analysis

No suspicious patterns detected.