T08 · Insecure Dependencies
- Location
scripts/install_mypay.py:64- Finding
Unverified Globally Installed Payment Dependency
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This payment skill is mostly coherent, but it can submit payments without a final transaction-specific confirmation and exposes sensitive payment-link material too broadly.
Review before installing. Only use this skill if you trust the mypay-bot CLI and are comfortable giving it payment API and wallet-signing credentials. Do not proceed unless the workflow is changed to require a clear final confirmation of the exact transaction details before any submit-payment command, and avoid sharing full payment URLs or tokenized links unless you know they are safe to disclose.
scripts/install_mypay.py:64Unverified Globally Installed Payment Dependency
SKILL.md:85Payment Submission Proceeds Without Explicit Transaction-Specific Confirmation
There is a clear description-behavior mismatch. The declared purpose says this skill should be used for user intents involving payments, purchases, checkout, transfers, and transactions. However, the code chunk is strictly an environment/dependency checker for an npm package. It verifies npm availability, inspects the globally installed mypay-bot version, and instructs the user how to manually install or update it. It does not initiate payments, handle wallets, process orders, transfer money, or interact with financial resources. While dependency checking could be a supporting implementation detail inside a broader payment skill, the supplied code chunk’s actual primary purpose is operational setup validation, not payment execution. Therefore the description materially overstates and misrepresents the code’s actual behavior.
The trigger criteria are extremely broad, including many common commerce-related words and even cases where the user does not explicitly ask to pay. In the context of a payment skill with wallet credentials and submission commands, overbroad invocation can cause the agent to enter a payment flow unexpectedly and increase the risk of accidental financial actions.
The skill instructs the agent to submit a payment using a payment link but does not require an explicit final confirmation from the user immediately before execution. In a payment context, this creates a direct risk of unauthorized or accidental transactions, especially if the trigger fired broadly or prior steps inferred intent incorrectly.
The skill explicitly requires copying full URLs, query parameters, tokens, and hashes from tool output back to the user verbatim. Because this is a payment skill handling API-linked workflows and wallet operations, those values may include secrets, signed links, session tokens, or one-time authorization material that could enable replay, account misuse, or data leakage.
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
def run_cmd(cmd):
"""Run a shell command and return (returncode, stdout)."""
try:
result = subprocess.run(
cmd, shell=True, capture_output=True, text=True, timeout=30
)
return result.returncode, result.stdout.strip()
The skill invokes shell commands and depends on external binaries, but it does not declare an explicit tool scope such as allowed-tools or permissions. In a payment-oriented skill, missing tool restrictions increases the chance of broader-than-expected command execution and makes review and enforcement of least privilege harder.
Output size or generation rate is not bounded. Unbounded output enables denial-of-service through resource exhaustion, log flooding, or context-window stuffing.
- **Preserve all links and images exactly**: Every URL, link, and image reference that appears
in the output of any mypay-bot command MUST be copied in full — character for character,
with no truncation, no summarization, no reformatting. This includes query parameters,
tokens, hashes, and any other URL components. Display them to the user exactly as received.
- **Follow the step order strictly**: Step 0 -> Step 1 -> Step 2. Do not skip or reorder.
subprocess module calls execute external commands. Without careful input validation, this enables command injection.
def run_cmd(cmd):
"""Run a shell command and return (returncode, stdout)."""
try:
result = subprocess.run(
cmd, shell=True, capture_output=True, text=True, timeout=30
)
return result.returncode, result.stdout.strip()
No suspicious patterns detected.