T09 · Insecure Skill Coding Practices
- Location
scripts/check-positions.py:5- Finding
Plaintext Wallet Private Key Embedded in Source Code
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is intended for real leveraged trading, but it handles wallet keys and live mainnet transactions in ways that need careful review before use.
Install only if you are prepared to audit and modify it first. Remove and rotate any exposed wallet keys, do not reuse the shipped key, avoid plaintext private-key files, pin and review dependencies, add dry-run and explicit confirmation gates before any approval or trade, and use a minimally funded wallet or external signer for live trading.
scripts/check-positions.py:5Plaintext Wallet Private Key Embedded in Source Code
scripts/test-avantis-simple.py:12Test Script Unconditionally Approves USDC and Opens a Real Mainnet Leveraged Position
scripts/trade.py:23Invalid Trade Directions Silently Become Short Positions and Financial Inputs Are Not Validated
README.md:40Wallet-Sensitive SDK Is Installed Without Version or Integrity Pinning
The README instructs users to place a raw blockchain private key into a plaintext file, which creates a direct credential exposure risk if the file is read by other local users, committed to version control, uploaded in logs, or exfiltrated by malware. In this skill's context, the key controls a funded wallet used for high-risk leveraged trading, so compromise can immediately lead to unauthorized trades or total asset theft.
The finding is credible because the skill claims broad multi-asset trading but also suggests additional privileged actions such as token approvals and direct signing that are not transparently emphasized. In a financial context, hidden approval flows and embedded credential usage are especially dangerous because they can authorize token spending or other on-chain actions beyond what the user expects.
The finding is credible because the skill claims broad multi-asset trading but also suggests additional privileged actions such as token approvals and direct signing that are not transparently emphasized. In a financial context, hidden approval flows and embedded credential usage are especially dangerous because they can authorize token spending or other on-chain actions beyond what the user expects.
The finding is credible because the skill claims broad multi-asset trading but also suggests additional privileged actions such as token approvals and direct signing that are not transparently emphasized. In a financial context, hidden approval flows and embedded credential usage are especially dangerous because they can authorize token spending or other on-chain actions beyond what the user expects.
A raw blockchain private key is hardcoded directly in the script and then loaded into the signer, exposing full control of the associated wallet to anyone who can read the file, repository history, logs, or packaged skill contents. In the context of a leverage-trading skill on mainnet, compromise of this key could allow an attacker to inspect positions, place or modify trades, withdraw or otherwise misuse funds, and incur amplified losses due to leveraged exposure.
The script builds, signs, and broadcasts a blockchain close transaction immediately after printing position details, without any confirmation step or review of transaction parameters. Because this skill controls leveraged positions on mainnet, a mistaken pair index, trade index, or partial close amount can irreversibly alter or liquidate a position and cause financial loss.
A hardcoded private key embedded in source code is a severe secret exposure: anyone with access to the repository, logs, or redistributed file can control the wallet and sign arbitrary transactions. In this skill's context, the key is immediately used against Base mainnet to approve token spending and place leveraged trades, making theft and fund loss especially likely and severe.
The script sends live mainnet approval and trading transactions without an explicit confirmation gate, so running it can spend real funds and grant allowances automatically. In a leveraged trading skill, this is more dangerous than a typical blockchain demo because approval plus trade execution can rapidly create financial loss, liquidation risk, or unintended token exposure.
The script accesses a wallet private key from disk without any warning, confirmation, or disclosure to the user, then uses it to approve USDC and open leveraged positions. This is dangerous because a user or calling agent may trigger real fund movements without realizing the script has direct signing authority, and leveraged trading amplifies the financial consequences of unauthorized or mistaken execution.
The documentation discloses the exact filesystem path to a wallet private key, which meaningfully lowers the barrier for credential theft by any local user, adjacent process, or malicious automation with filesystem access. In a trading skill tied to real funds, revealing where the key lives creates a direct route to wallet takeover and unauthorized transactions.
Disclosing a sensitive private-key storage location without a strong security warning normalizes unsafe secret handling and may prompt operators to access or copy the key insecurely. Because this skill performs financial operations with direct wallet integration, the context makes the omission more dangerous: compromise of the key can result in complete loss of funds and unauthorized on-chain actions.
The quick-start presents executable commands that open and close leveraged positions on a live trading platform, and it also exposes a specific funded wallet context, but it does not clearly and prominently warn that these commands trigger real on-chain financial transactions. In an agent-skill setting, users may reasonably interpret 'quick start' examples as safe demos or dry runs, which increases the risk of accidental fund loss, especially given leverage and direct wallet integration.
The script directly reads a private key from a fixed wallet file on disk and then uses it to sign blockchain transactions. This creates a credential-access and custody risk: any user invoking the script implicitly grants spending authority to whatever key is stored there, and compromise or misconfiguration of that file can lead to unauthorized trades or fund loss. In a trading skill with direct wallet integration, this is especially dangerous because the credential is immediately used for high-value on-chain actions.
The script accesses wallet credentials silently at startup with no user-facing disclosure, prompt, or consent boundary. Even if the skill's purpose is to close trades, silently loading a sensitive signing key reduces transparency and makes accidental use of a live wallet more likely, particularly in automated or agent-driven environments.
This script is described as a read-only position viewer, but it loads a private key from disk and enables local signing anyway. That unnecessarily expands the blast radius: anyone who can run or modify this script, or influence imported code paths, gains access to a funded signing key rather than only public wallet data.
The code reads a wallet private key directly from a fixed local file path with no warning, prompt, or safeguards. This creates unsafe secret handling, encourages plaintext key storage, and can expose the credential through file compromise, accidental reuse, developer environment leakage, or downstream code that now has access to a signer.
The file-level docstring says the script is a 'Simple Avantis trade test - 2x long ETH with $5'. However, the constructed TradeInput uses collateral_in_trade=10 and leverage=5, and later log messages also describe a 5x long position. This is an active contradiction between the documentation and the implemented trading behavior.
The script directly reads a private key from a fixed local filesystem path and automatically uses it for signing trades. This is dangerous because it silently couples trading execution to a sensitive wallet secret, increasing the risk of unauthorized fund use, accidental key exposure, and misuse when the skill is run in a broader agent environment. In the context of a trading skill with direct wallet integration, this is especially risky because the code can immediately spend funds once invoked.
No suspicious patterns detected.