Mercury Payments
PassAudited by VirusTotal on May 12, 2026.
Overview
Type: OpenClaw Skill Name: mercury-payments Version: 1.0.1 The skill is classified as suspicious primarily due to the explicit example of `curl ... | python3 -c "..."` in `SKILL.md`. While presented as a placeholder, this pattern demonstrates a direct command injection vulnerability (potential RCE) if the `...` portion is controlled by a malicious prompt. This high-risk execution pattern, combined with the skill's inherent ability to perform sensitive financial transactions, access API tokens (e.g., via `pass show <vault-path>`), and interact with the file system (`/tmp/`, 'daily memory file'), elevates its risk profile beyond benign, even without clear evidence of intentional malicious payloads within the provided bundle.
Findings (0)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If the token is misused or exposed, it could allow recipient creation, payments, transfers, and transaction access on the Mercury account.
The skill asks the agent to use a write-capable bank API token and may retrieve it from a local password vault; the registry metadata declares no primary credential or required environment variables, so this high-impact account access is under-disclosed.
Mercury API token (write access): `$MERCURY_API_TOKEN` or `pass show <vault-path>`
Use a dedicated least-privilege Mercury token with payment limits, expose it only for approved sessions, declare the credential requirement clearly, and revoke or rotate the token when not needed.
A mistaken or over-permissive invocation could send money to the wrong recipient, use the wrong account, or create unwanted financial transactions.
The skill instructs the agent to use raw API calls to initiate bank payments. Although it says never to send money without explicit approval, the artifacts do not provide enforceable limits, recipient/account allowlists, amount caps, or rollback/containment.
`POST "https://api.mercury.com/api/v1/account/{accountId}/transactions"` with `paymentMethod`: `ach` or `domesticWire`Require per-payment human confirmation of amount, recipient, invoice number, account, and payment method; consider separate approval for new recipients and internal transfers; and prefer a constrained payment workflow over raw API access.
Sensitive payment or invoice details could be retained longer than expected, and incorrect or manipulated memory could influence later payment decisions.
The skill requires persistent payment logging but does not define the file path, contents, retention, redaction rules, permissions, or how future agent runs should trust that memory.
Payment logged in daily memory file
Make payment logging opt-in or clearly bounded, store only minimal non-secret data, define retention and access controls, and require fresh user verification before relying on logged memory for future payments.
Invoice information could be sent to the wrong person or a vendor could be told a payment was made incorrectly.
The workflow intentionally propagates invoice PDFs and payment details to external recipients. This is purpose-aligned, but a wrong attachment, thread, or payment status could spread beyond the original banking action.
Email bookkeeper (always) ... Attach the invoice PDF ... Email vendor (always) ... Attach the invoice PDF
Confirm the email recipients, thread, payment status, and attachment before sending notifications, especially when invoices contain sensitive business information.
It may be harder to verify who authored the payment instructions or whether they match your organization's approved finance process.
There is no executable package to inspect, which reduces code-execution risk, but the author/source provenance is limited for a skill that handles banking workflows.
Source: unknown; Homepage: none; No install spec — this is an instruction-only skill.
Only use this skill if you trust its source and have reviewed that the instructions match your internal payment controls.