T09 · Insecure Skill Coding Practices
- Location
auth.md:128- Finding
Wallet private key exposed through command-line arguments
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This DECK-0 skill is coherent, but it needs Review because it can sign live blockchain transactions and documents raw private-key fallback flows without strong per-transaction safeguards.
Install only if you intend to use DECK-0 wallet-linked features. Prefer a runtime wallet, hardware wallet, or dedicated low-value wallet, avoid DECK0_PRIVATE_KEY for real funds, and manually confirm chain, contract address, pack IDs, quantity, total value, and gas before any transaction. Expect app.deck-0.com to receive wallet addresses, signatures, collection activity, recap data, and publisher application content.
auth.md:128Wallet private key exposed through command-line arguments
README.md:7Unpinned third-party Skill installation creates supply-chain risk
errors.md:130Predictable shared temporary files permit symlink attacks and data exposure
Referenced artifact was not completely inspected
See [errors.md](./errors.md) for all error codes and troubleshooting.
Referenced artifact was not completely inspected
See [errors.md](./errors.md) for all error codes and troubleshooting.
The README instructs users to install the skill via npx skills add signorcrypto/deck0-skills without pinning a specific package version or commit. This creates a supply-chain risk: a later compromised or maliciously updated package/tooling release could be fetched and executed implicitly, which is especially concerning for a skill that interfaces with wallets and on-chain transactions.
The skill advertises pack purchases and pack opening through smart contract transactions but does not prominently warn that these actions may spend funds and be irreversible once signed and broadcast. In the context of an agent skill, missing consent and risk language increases the chance that a user authorizes unintended financial actions without understanding the consequences.
The skill description is broad enough to match generic requests about collecting cards, managing collections, or creating card collections, which can cause the agent to invoke this transactional NFT/crypto skill when the user did not intend to access DECK-0 specifically. Because the skill supports authenticated API calls and on-chain purchase/open actions, accidental activation can expose wallet-linked data, initiate sensitive flows, or steer users into unintended crypto transactions.
The documentation provides a fallback mode that directly uses a private key from an environment variable for request signing. While common in developer examples, embedding this pattern in a skill that may run in agent environments increases the chance of unsafe key handling, accidental logging, or reuse of a hot wallet without clearly warning that the credential grants signing authority.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
local signature
signature="$(cast wallet sign --private-key "$DECK0_PRIVATE_KEY" "$payload")"
# Export for use in curl
HEADER_WALLET="$WALLET"
HEADER_CHAIN_ID="$DECK0_CHAIN_ID"
HEADER_TIMESTAMP="$timestamp"
The pack-opening recap endpoint returns transaction-linked results, cards received, guild-related badge information, and a collector identifier, all tied to an authenticated user. The markdown description does not warn that polling and displaying this data may expose sensitive activity or identity-linked collection information.
These sections describe reading and submitting publisher application data including wallet address, collection description, motivational letter, rejection reason, and timestamps. The markdown omits any warning that this is user-submitted profile/application content that may be sensitive and should be handled carefully.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
The X-Agent-* headers in the example below should be produced via the same auth flow as in auth.md (e.g. sign_request and the authenticated request helpers).
HTTP_CODE=$(curl -s -o /tmp/response.json -w "%{http_code}" "$url" \
-H "X-Agent-Wallet-Address: $HEADER_WALLET" \
-H "X-Agent-Chain-Id: $HEADER_CHAIN_ID" \
-H "X-Agent-Timestamp: $HEADER_TIMESTAMP" \
The example instructs the agent or user to execute a value-bearing blockchain transaction with a private key and computed --value, but it does not explicitly warn that real funds will be spent and the action is irreversible once broadcast. In an agent-skill context, examples often become implementation templates, so omitting a spending confirmation step increases the chance of unintended financial loss or autonomous execution against a live wallet.
The pack-opening example signs and submits an on-chain transaction using a private key but does not clearly state that the action is irreversible and changes ownership state of user assets. Even though it may not transfer currency directly, it affects owned packs and can trigger unintended asset changes if copied blindly by an agent or operator.
The document instructs users how to perform payable on-chain purchases and irreversible pack-opening operations, but it does not prominently warn that minting spends native tokens plus gas and that opening packs is an irreversible state-changing transaction. In an agent skill context, this omission can cause users or downstream automation to authorize transactions without fully understanding financial cost and asset consequences.
The shell example directly relies on a raw private key in an environment variable and passes it to command-line tooling without any accompanying security guidance. In practice, this encourages unsafe key handling patterns that can lead to credential leakage through shell history, process inspection, logs, CI systems, or copied scripts, enabling full wallet compromise and unauthorized transactions.
The README describes wallet-authenticated API requests and submission of publisher applications, but it does not clearly disclose what wallet-linked data, signatures, addresses, or application contents are sent to the DECK-0 service. Because the skill ties identity and activity to a blockchain wallet, inadequate privacy notice can expose users to unintended data sharing and profiling risks.
This markdown file documents authenticated endpoints that return a user's wallet-specific album collection and account share URL, but it does not include any warning about exposing personal account or collection data. Under the markdown criteria for SQP-2, descriptions should warn when behavior can affect user privacy or reveal user-linked data.
No suspicious patterns detected.