T09 · Insecure Skill Coding Practices
- Location
escrow-integration.js:41- Finding
Escrow Release Accepts Fabricated Proof Hashes
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is openly for real purchases, but its safeguards are not strong enough for spending money and handling payment/session data.
Review carefully before installing. This skill can drive a real Amazon session, use saved payment and shipping details, capture checkout screenshots, and interact with escrow/payment code. Only use it in a tightly controlled test account or sandbox wallet until it has explicit per-purchase confirmation, authoritative final-total checks, secure evidence storage, pinned dependencies, and real proof/escrow state validation.
escrow-integration.js:41Escrow Release Accepts Fabricated Proof Hashes
escrow-integration.js:90Post-Purchase Errors Can Incorrectly Refund Escrow
amazon-purchase-with-session.js:84Final Checkout Total Is Not Validated Against the Authorized Budget
amazon-purchase-with-session.js:14Checkout Screenshots Are Stored in a Predictable Shared Temporary Directory
package.json:40Wallet-Handling Dependency Is Broadly Versioned Without an Integrity Lock
Skill modifies its own code, configuration, or behavior at runtime. Self-modification enables an agent to escalate privileges, disable safety constraints, or install persistent backdoors.
- Comments for complex logic
**Documentation:**
- Update SKILL.md for behavior changes
- Update README.md for setup changes
- Update CHANGELOG.md for all changes
- Add JSDoc comments to functions
The documented functionality claims end-to-end autonomous e-commerce purchasing and escrow settlement, but the file does not provide those controls as enforceable behavior. In context, this is especially risky because the action domain is real-world purchasing with saved payment methods, where false assumptions about safeguards can directly lead to unauthorized or uncontrolled spending.
The documented functionality claims end-to-end autonomous e-commerce purchasing and escrow settlement, but the file does not provide those controls as enforceable behavior. In context, this is especially risky because the action domain is real-world purchasing with saved payment methods, where false assumptions about safeguards can directly lead to unauthorized or uncontrolled spending.
The documented functionality claims end-to-end autonomous e-commerce purchasing and escrow settlement, but the file does not provide those controls as enforceable behavior. In context, this is especially risky because the action domain is real-world purchasing with saved payment methods, where false assumptions about safeguards can directly lead to unauthorized or uncontrolled spending.
The code claims escrow protection and verification, but it only generates a local hash after the order is already placed. This creates a dangerous trust gap: users or downstream systems may believe purchases are escrow-controlled when no actual funds hold, release control, or independent verification exists.
The changelog advertises autonomous real-world purchasing, proof of completed orders, and production readiness without any adjacent warning that using the skill can place binding orders and spend real funds. In a commerce automation skill, omission of explicit spending/ordering warnings increases the chance of unsafe routing, accidental invocation, or user misunderstanding about real-world financial consequences.
The README promotes autonomous real-world purchasing using pre-saved payment methods while framing the capability as safe, but it does not prominently warn that this can trigger irreversible financial transactions or require explicit human confirmation before checkout. In the context of an autonomous commerce skill, that omission materially increases the risk of unauthorized or unintended purchases, especially if downstream agents invoke the skill based only on user intent matching.
The quick-start example instructs users to initialize an escrow client with a wallet private key from an environment variable but provides no security guidance on secret handling, storage, rotation, or least-privilege usage. Because this skill is designed for autonomous financial transactions, weak credential practices could expose blockchain funds or allow fraudulent escrow releases if the private key is leaked through logs, local shells, CI, or misconfigured deployment environments.
The skill documents capabilities that imply access to environment-backed secrets and sensitive automation, but it declares no explicit tool scope or permissions boundaries. In a skill that can trigger purchases and interact with escrow/payment systems, missing scope declarations increases the chance of unintended secret access or over-privileged execution.
The skill authorizes adding items to cart and completing checkout with saved payment information, but it does not present a prominent upfront warning or mandatory final confirmation for irreversible financial actions. In this context, autonomous purchasing against saved payment methods materially increases the risk of accidental, coerced, or prompt-manipulated purchases.
The escrow example pulls a wallet private key from an environment variable inside a broadly described e-commerce skill. Combining autonomous purchasing with direct access to signing keys expands the blast radius: if the skill or its runtime is misused, an attacker could trigger unauthorized on-chain operations or exfiltrate high-value credentials.
The stated network policy says only retailer domains are allowed, yet the skill also depends on external escrow interactions. This inconsistency weakens trust in the security model and may lead to undeclared outbound connectivity, making it harder to review or constrain where financial or order data can be sent.
The purchase target and budget are hard-coded, so the script can buy a specific item regardless of the user's actual request. In an autonomous purchasing skill, this is especially dangerous because it can trigger unintended real-world spending and makes the agent's behavior diverge from user intent.
The script depends on an already authenticated Amazon browser profile and then drives that live session into a purchase flow. In a commerce automation skill, reusing stored session state without explicit authorization checks or escrow gating increases the risk of unauthorized purchases from a real account and makes the manifest's safety claims misleading.
Loading a persistent browser session implicitly uses stored authentication material and account state, which may include access to payment methods, addresses, and order history. Without prominent disclosure and consent, an operator may unknowingly run a script that acts with the full privileges of a real retail account.
The script navigates a live checkout flow, captures screenshots, and writes proof artifacts to disk without a clear upfront warning about the sensitivity of those actions. Because screenshots and saved files may contain order details, addresses, and other personal data, this creates privacy and operational risk in addition to the purchase risk.
The package description makes sweeping claims about being the 'ONLY agent with proven real-world commerce capability' and presents autonomous purchasing as a core function without embedding any clear safety boundaries, approval requirements, or trigger constraints. In an agentic ecosystem, overbroad capability claims can cause unsafe invocation or over-trust, which is especially risky for a skill intended to make real-world purchases and interact with escrowed funds.
The manifest explicitly advertises autonomous real-world purchasing, but the description does not define strict invocation boundaries, approval requirements, or constraints on when purchases may occur. In a commerce skill, ambiguous trigger scope is dangerous because an orchestrating agent could invoke it in response to loosely related shopping intents, leading to unauthorized or unintended financial transactions using pre-saved payment credentials.
The dependency on Playwright is version-ranged with a caret, allowing newer minor/patch releases to be installed without review. For a skill that automates browser actions for e-commerce purchases, silently changing browser automation behavior or pulling in a compromised or vulnerable release increases supply-chain and execution risk.
"node": ">=18.0.0"
},
"dependencies": {
"playwright": "^1.40.0"
},
"optionalDependencies": {
"clawpay": "^1.0.0"
The manifest references Playwright without pinning, and Playwright has a known advisory related to downloading/installing browsers without verifying authenticity. In a skill that automates high-impact actions like purchases, an affected Playwright/browser install path could enable tampering with the execution environment, making downstream commerce actions more dangerous than in a low-privilege context.
The optional dependency clawpay is also unpinned, which permits different installs to resolve to different versions over time. Because this package appears related to payment/escrow functionality, uncontrolled version drift in a financial integration raises supply-chain and transaction-integrity concerns even if the dependency is optional.
"playwright": "^1.40.0"
},
"optionalDependencies": {
"clawpay": "^1.0.0"
},
"devDependencies": {},
"peerDependencies": {},
The claim that this is the 'ONLY agent with proven commerce capability' is manipulative marketing language that can bias agent selection or downstream trust decisions without contextual qualification. In a high-risk commerce skill, exclusivity and proof claims can pressure systems or users to prefer this skill and lower scrutiny, increasing the chance of unsafe autonomous purchasing behavior.
Detected: suspicious.dynamic_code_execution