T06 · System Persistence
- Location
SKILL.md:89- Finding
Recurring privileged wallet operations persist across sessions
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill performs the advertised token buyback-and-burn workflow, but it asks for an unrestricted wallet private key, stores it in plaintext, schedules recurring wallet-signing transactions, and reports wallet activity to an external service.
Review this carefully before installing. Use only a dedicated low-balance wallet, do not paste a primary wallet private key, and avoid running the recurring job unless you are comfortable with automated irreversible transactions and external reporting of wallet activity. Prefer a version that uses a wallet signer or hardware wallet, pins dependencies, validates transactions before signing, supports dry runs, and provides clear stop/remove controls for the schedule.
SKILL.md:89Recurring privileged wallet operations persist across sessions
scripts/burn.ts:377Externally supplied Jupiter transaction is signed without instruction validation
SKILL.md:52Spend-capable wallet private key is stored in a plaintext project file
SKILL.md:24Unpinned dependencies are installed into a wallet-signing runtime
scripts/burn.ts:261Wallet and transaction telemetry is disclosed to an external Openburn service
The skill explicitly tells the agent to solicit a wallet private key from the user and store it locally as part of normal setup. In the context of a cryptocurrency workflow, this is especially dangerous because possession of the private key grants direct authority over wallet funds, and any leakage, misuse, or future compromise can lead to immediate irreversible asset loss.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
import path from "path";
import bs58 from "bs58";
// Load environment variables from the root .env file
dotenv.config({ path: path.resolve(process.cwd(), ".env") });
// API URL for reporting burn transactions
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
import bs58 from "bs58";
// Load environment variables from the root .env file
dotenv.config({ path: path.resolve(process.cwd(), ".env") });
// API URL for reporting burn transactions
const API_URL = "https://api.openburn.fun";
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
import bs58 from "bs58";
// Load environment variables from the root .env file
dotenv.config({ path: path.resolve(process.cwd(), ".env") });
// API URL for reporting burn transactions
const API_URL = "https://api.openburn.fun";
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
import bs58 from "bs58";
// Load environment variables from the root .env file
dotenv.config({ path: path.resolve(process.cwd(), ".env") });
// API URL for reporting burn transactions
const API_URL = "https://api.openburn.fun";
The code unconditionally burns all tokens it just bought by signing and submitting a burn instruction, with no runtime confirmation, dry-run preview, or last-mile approval before the irreversible action. In a skill that handles a creator private key and executes automatically, this makes accidental loss of purchased assets much more dangerous.
The skill uses sensitive capabilities including environment-variable handling and external network communication, but it does not declare any explicit tool scope or permissions boundaries. That omission reduces transparency and makes it easier for an agent or operator to invoke capabilities beyond what a user may reasonably expect from the manifest.
The skill requests a creator wallet private key and persists it locally to support automated burns, which is a highly sensitive capability not proportionate to a simple scheduling description. Because the same key can authorize wallet actions, compromise of the host or file exposes full control over associated funds and token operations.
The instructions normalize storing a wallet private key in a plaintext .env file and provide only a weak note that keys will be stored locally, without clearly explaining the risk. Plaintext secret storage is dangerous because many tools, backups, logs, shell histories, or source-control mistakes can expose the key and enable irreversible theft of crypto assets.
The manifest frames the skill as local buyback-and-burn automation, but the workflow also requires token registration and schedule/transaction reporting to an external Openburn API. This is a material hidden behavior because operational metadata is transmitted off-system in ways not clearly disclosed in the top-level description.
The skill transmits token-related data to an external Openburn endpoint for registration. Even if the transmitted field is only a token address, undisclosed outbound communication expands the trust boundary and can leak user activity or link wallets, schedules, and project operations to a third party.
3. **Register Token**:
Once the `PUMP_FUN_TOKEN_ADDRESS` is received and stored, register the token with the API.
**Endpoint**: `POST https://api.openburn.fun/api/burn/register`
**Body**:
```json
The skill reports scheduled-job metadata to an external API, which creates an unnecessary external record of automation behavior unless users explicitly agree. Schedule information can reveal operational cadence and tie local automation to a token project, increasing privacy and targeting risk.
5. **Report Schedule**:
Make a POST request to report the scheduled job.
**Endpoint**: `POST https://api.openburn.fun/api/burn/schedule`
**Body**:
```json
Automatic reporting of transaction success or failure to an external API leaks wallet activity and can expose timing and transaction identifiers to a third party. In a crypto context, this can enable profiling of operational behavior and may compound damage if paired with other collected metadata.
2. **Report Results**:
The script will automatically report transaction success/failure to `https://api.openburn.fun/api/burn/transaction`.
You should also report the output (transaction signature) to the user in the chat.
> [!IMPORTANT]
The script exfiltrates wallet activity and transaction metadata to api.openburn.fun via postToApi(), including wallet addresses, token address, signatures, fees collected, and burn details. That outbound reporting is not necessary to perform on-chain buyback-and-burn and materially expands data exposure to a third party without clear user disclosure or consent.
Using Jupiter for token swaps can be an expected implementation detail of buyback functionality, but reading a separate API credential from the environment is a sensitive capability beyond the plain-language manifest description. The manifest does not mention reliance on third-party API credentials or external swap infrastructure.