T08 · Insecure Dependencies
Error
- Location
SKILL.md:13- Finding
Unpinned Global Installation of a Privileged Payment CLI
- Content
View full analysis
- Remediation
View remediation
Security audit
lobstercash
Security checks for vulnerabilities and agentic risk
Overview
This payment skill is not clearly malicious, but it should be reviewed carefully because it gives an agent broad spending, card, API-payment, and blockchain-signing authority with some safeguards missing or under-scoped.
Install only if you trust the Lobster Cash CLI publisher and are comfortable delegating payment actions to the agent. Pin and review the CLI version where possible, avoid passing bearer tokens through command arguments, do not use debug output around secrets unless necessary, require explicit confirmation before every spend or transaction signature, and revoke wallet or card access when finished.
Vulnerability Patterns
- Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
- 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
Findings (3)
T09 · Insecure Skill Coding Practices
Error
- Location
references/x402.md:14- Finding
Bearer Credentials and Signed Payment Payloads May Be Exposed to Arbitrary Endpoints or Logs
- Content
View full analysis
``` For POST requests add: `--json '{"key": "value"}'` For custom headers add: `--header "Authorization: Bearer "` To raise the signature timeout add: `--timeout ` (default 120000, minimum 5000). To see the full payment negotiation on stderr add: `--debug`. ``` ```markdown ## If the fetch fails Add `--debug` to the same command and run it again. Debug output goes to stderr and shows the 402 `accepts` array, the signed payment payload, and the phase-2 response — exactly where the payment flow broke. Common failures: - `"x402 payment failed: server returned 402 after payment attempt"`: the facilitator rejected the signed authorization. Verify the agent is registered as an `external-wallet` delegated signer on the Base smart wallet, and that the 402 `accepts` entry targets Base USDC. ``` The same credential-bearing command is also documented in `SKILL.md:89-101`: ```markdown lobstercash crypto x402 fetch ``` ```markdown For POST requests add `--json '{"key": "value"}'`. For custom headers add `--header "Authorization: Bearer "`. ``` ```markdown If the fetch fails, add `--debug` and run again. See [x402 reference](references/x402.md) for output format and common failures. ``` ### Technical Analysis The Skill permits an arbitrary URL to be combined with a bearer authorization header. It does not impose an HTTPS-only requirement, validate that the token belongs to the destination origin, restrict destination hosts, or define a safe redirect policy. Bearer tokens provide access to whoever possesses them. If a user supplies a token for one service but an attacker-controlled endpoint or cross-origin redirect receives the request, the token may be disclose ...[truncated 1843 chars]- Remediation
View remediation
T05 · Unauthorized Access and Privilege Escalation
Error
- Location
references/tx.md:3- Finding
Opaque External Blockchain Transactions Can Be Signed Without Mandatory Validation or User Confirmation
- Content
View full analysis
- Remediation
View remediation
Vulnerability Patterns
- Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
- Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
- Tool MisuseTool Parameter Abuse, Chaining Abuse, Unsafe Defaults
- Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
- MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Findings (14)
Vague Triggers
High
- Category
- Not specified by scanner
- Confidence
- 95% confidence
- Finding
The trigger description is extremely broad, covering generic intents like shopping, browsing, sending money, and payment setup, which can cause the skill to activate in many normal conversations where financial tooling was not explicitly requested. In a payment-capable skill, unintended invocation increases the chance an agent starts wallet, card, or checkout flows without sufficiently explicit user consent, making the context materially more dangerous than a typical informational skill.
- Content
Missing User Warnings
Medium
- Category
- Not specified by scanner
- Confidence
- 88% confidence
- Finding
The BYO-browser and manual checkout flow instructs the agent to use
cards revealto obtain card credentials, but the skill does not prominently warn about the sensitivity of exposing PAN/CVV/expiry data or define strict handling requirements. In this context, revealing payment credentials to an agent or browser automation path creates clear risk of leakage through logs, screenshots, tool telemetry, prompt history, or accidental display to unintended parties.- Content
Vague Triggers
Medium
- Category
- Not specified by scanner
- Confidence
- 89% confidence
- Finding
The eval prompts and expectations define the skill as applicable to a very broad range of spending, wallet, checkout, browsing, and transaction-signing intents without clear narrowing conditions or disambiguation boundaries. In a payment-capable skill, overly broad trigger scope can cause the agent to invoke high-risk financial actions in ambiguous contexts, increasing the chance of unintended purchases, wallet operations, or exposure to malicious checkout/payment flows.
- Content
Missing User Warnings
Medium
- Category
- Not specified by scanner
- Confidence
- 88% confidence
- Finding
The example content encourages users to buy tokenized stocks and, after selection, immediately check balances and continue into funding or transaction flows without surfacing any warning about investment risk, asset volatility, jurisdictional restrictions, or the fact that on-chain actions can be irreversible. In a payment and wallet skill, this omission can materially increase the chance of users being nudged into financial activity they do not fully understand.
- Content
Autonomous Decision Making
Medium
- Category
- Excessive Agency
- Confidence
- 75% confidence
- Finding
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
- Content
md - **Skipping price discovery:** Always discover the real product and price (Step 2) before requesting a card. Without it you can't size the card and the merchant will decline. - **Hallucinating product URLs or paths:** Same rule as the native flow — never guess URLs beyond the root domain. Either start from the merchant homepage and let your browser tool navigate the site's own UI, or ground yourself in a real URL pulled from web search results. - **Placing orders without user authorization:** The card's hard cap is a backstop, not a green light. Always stop at the order-review screen and ask the user to confirm before submitting. - **Requesting a new card without checking `cards list` first:** Always run `lobstercash cards list` after Step 2 and check whether an `active` card already covers this purchase. Reusing a usable card avoids spamming the user with another approval link. - **Reusing a card whose description doesn't fit the purchase:** The user approved each card for a specific purpose. Don't reuse an "AWS credits" card to buy enamel pins — request a new card scoped to the new purpose. - **Sharing revealed card details with the user or logs:** `cards reveal` output is sensitive. Use the values in the merchant's checkout form, then forget them. Don't echo them back to the user. - **Guessing merchant questions you can't answer:** Same as the native flow — when you hit a required choice you can't make on your own (size, shipping option, missing address field), pause and ask the user. Don't invent answers.
Autonomous Decision Making
Medium
- Category
- Excessive Agency
- Confidence
- 75% confidence
- Finding
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
- Content
md - **Skipping price discovery:** Always discover the real product and price (Step 2) before requesting a card. Without it you can't size the card and the merchant will decline. - **Hallucinating product URLs or paths:** Same rule as the native flow — never guess URLs beyond the root domain. Either start from the merchant homepage and let your browser tool navigate the site's own UI, or ground yourself in a real URL pulled from web search results. - **Placing orders without user authorization:** The card's hard cap is a backstop, not a green light. Always stop at the order-review screen and ask the user to confirm before submitting. - **Requesting a new card without checking `cards list` first:** Always run `lobstercash cards list` after Step 2 and check whether an `active` card already covers this purchase. Reusing a usable card avoids spamming the user with another approval link. - **Reusing a card whose description doesn't fit the purchase:** The user approved each card for a specific purpose. Don't reuse an "AWS credits" card to buy enamel pins — request a new card scoped to the new purpose. - **Sharing revealed card details with the user or logs:** `cards reveal` output is sensitive. Use the values in the merchant's checkout form, then forget them. Don't echo them back to the user. - **Guessing merchant questions you can't answer:** Same as the native flow — when you hit a required choice you can't make on your own (size, shipping option, missing address field), pause and ask the user. Don't invent answers.
Autonomous Decision Making
Medium
- Category
- Excessive Agency
- Confidence
- 75% confidence
- Finding
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
- Content
md - **Skipping price discovery:** Always discover the real product and price (Step 2) before requesting a card. Without it you can't size the card and the merchant will decline. - **Hallucinating product URLs or paths:** Same rule as the native flow — never guess URLs beyond the root domain. Either start from the merchant homepage and let your browser tool navigate the site's own UI, or ground yourself in a real URL pulled from web search results. - **Placing orders without user authorization:** The card's hard cap is a backstop, not a green light. Always stop at the order-review screen and ask the user to confirm before submitting. - **Requesting a new card without checking `cards list` first:** Always run `lobstercash cards list` after Step 2 and check whether an `active` card already covers this purchase. Reusing a usable card avoids spamming the user with another approval link. - **Reusing a card whose description doesn't fit the purchase:** The user approved each card for a specific purpose. Don't reuse an "AWS credits" card to buy enamel pins — request a new card scoped to the new purpose. - **Sharing revealed card details with the user or logs:** `cards reveal` output is sensitive. Use the values in the merchant's checkout form, then forget them. Don't echo them back to the user. - **Guessing merchant questions you can't answer:** Same as the native flow — when you hit a required choice you can't make on your own (size, shipping option, missing address field), pause and ask the user. Don't invent answers.
Missing User Warnings
Medium
- Category
- Not specified by scanner
- Confidence
- 92% confidence
- Finding
The flow instructs the agent to collect and pass shipping address, contact email, phone number, and product details into automated browser and payment workflows, but it does not include an explicit privacy notice, minimization guidance beyond convenience, retention limits, or user-facing consent language for transmitting this data to third-party merchants and browser automation. In a payments/purchasing skill, this is materially risky because the data is both sensitive and externally disclosed during checkout, increasing privacy, compliance, and misuse exposure.
- Content
Unsafe Defaults
Medium
- Category
- Tool Misuse
- Confidence
- 60% confidence
- Finding
Tool defaults are unsafe or overly permissive (e.g. disabled TLS verification, no authentication, world-writable permissions). Unsafe defaults widen the attack surface.
- Content
Local development mock card
When the web app is running with
NODE_ENV=development, you can pass--card-id dev-mock-cardto bypass Crossmint card credentials and inject a non-chargeable test card:bash lobstercash purchase run \
Missing User Warnings
Medium
- Category
- Not specified by scanner
- Confidence
- 94% confidence
- Finding
The setup instructions direct the agent to link itself to a blockchain wallet and enable spending-adjacent capabilities such as virtual cards and top-ups, but they do not require an explicit safety warning or a clear confirmation that the user understands they are granting the agent financial authority. In a payments skill, that omission is risky because users may treat setup as routine account linking rather than delegation of sensitive wallet access, increasing the chance of unintended authorization.
- Content
Missing User Warnings
Medium
- Category
- Not specified by scanner
- Confidence
- 95% confidence
- Finding
The skill explicitly supports signing and submitting arbitrary externally supplied blockchain transactions, but it does not require or prominently warn about verifying the transaction source, contents, destination, approvals, or irreversibility before approval. In this context, an agent wallet may execute hostile serialized payloads or raw calls from another tool or external system, leading to irreversible asset loss, unsafe approvals, or unintended contract interactions.
- Content
Missing User Warnings
Medium
- Category
- Not specified by scanner
- Confidence
- 95% confidence
- Finding
The skill instructs the agent to automatically pay a metered API endpoint from the agent wallet and optionally attach arbitrary Authorization headers, but it does not require explicit user confirmation for spending or any warning about transmitting sensitive credentials to third-party URLs. In a payments skill, this context makes the issue more dangerous because an agent could silently spend funds and exfiltrate bearer tokens or other secrets to an attacker-controlled endpoint under the guise of an API fetch.
- Content
Missing User Warnings
Low
- Category
- Not specified by scanner
- Confidence
- 82% confidence
- Finding
The documentation tells users to export
LOBSTER_AGENT_IDto control which wallet an agent session uses, but it does not warn that environment variables can persist in shell history, be inherited by child processes, or be exposed through debugging/process-inspection workflows depending on the environment. While the value is an agent identifier rather than a secret key, it is still security-relevant because it influences wallet/agent selection and could cause accidental cross-agent actions or information leakage in multi-agent setups.- Content
Intent-Code Divergence
Low
- Category
- Not specified by scanner
- Confidence
- 96% confidence
- Finding
L42 instructs the agent to include the explorer URL so the user can verify the transaction, while L38 says to show the explorer link only if asked. It also says not to show the raw transaction hash unless specifically asked, creating conflicting guidance about what transaction identifiers should be disclosed by default.
- Content
Static analysis
No suspicious patterns detected.