Is ahsanatha/mayar-payment-skill safe?

https://github.com/openclaw/skills/tree/main/skills/ahsanatha/mayar-payment-skill

90
SAFE

The mayar-payment-skill is a legitimate Mayar.id payment integration with no prompt injection, hidden instructions, or malicious behavior detected in skill content or installation monitoring. Canary files were accessed during the audit period but accesses correlate with the monitoring infrastructure's own baseline checks rather than skill-initiated reads. Primary concerns are operational: the API token is placed in plaintext in the MCP server config file, integration examples demonstrate shell-injection-prone execSync patterns, and all payment operations route through a third-party MCP endpoint that must be trusted.

Category Scores

Prompt Injection 93/100 · 30%
Data Exfiltration 83/100 · 25%
Code Execution 92/100 · 20%
Clone Behavior 91/100 · 10%
Canary Integrity 100/100 · 10%
Behavioral Reasoning 82/100 · 5%

Findings (5)

MEDIUM API Token Stored in Plaintext Config File -12

The skill instructs users to embed their Mayar JWT API token directly as a command-line argument in config/mcporter.json ('Authorization:YOUR_API_TOKEN_HERE'). This token is visible in process listings (ps aux), readable by any skill or process with filesystem access to the config directory, and may be logged by process auditing tools. The skill does separately recommend storing credentials in ~/.config/mayar/credentials with chmod 600, but the MCP config step duplicates the token in a less-protected location.

LOW Shell Injection Risk Pattern in Integration Examples -8

The integration-examples.md file demonstrates using Node.js execSync() to invoke mcporter with shell commands that interpolate user-supplied variables via template literals (e.g., name="${data.name}", email="${data.email}", mobile=""${data.mobile}""). If an LLM agent follows these example patterns and processes unsanitized user input, arbitrary shell command injection is possible. This is documentation code, not code that runs at install time, but the examples are presented as production patterns.

LOW External MCP Server Receives API Token -5

All payment operations are routed through an SSE endpoint at https://mcp.mayar.id/sse, which receives the user's Mayar API token as an HTTP Authorization header on every connection. Users must trust Mayar.id's MCP infrastructure. If the mcp.mayar.id domain is taken over, the API endpoint is compromised, or the service implements unauthorized logging, the token and all payment operations could be exposed to a third party.

INFO Canary File Accesses Attributed to Audit Infrastructure -9

Audit logs record multiple accesses to canary files (.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, .config/gcloud/credentials) at timestamps 1771951900.611 (pre-install setup), 1771951908.528 and 1771951915.263 (openclaw-gateway startup), and 1771951919.949 (post-install baseline check — all 6 files at identical timestamp indicating scripted enumeration by audit system). Canary integrity confirms no modifications. Access pattern is consistent with the monitoring infrastructure's own honeypot setup and verification routines, not skill-triggered activity.

INFO Payment and Messaging Capability Combination Risk -18

The skill's stated use case includes generating WhatsApp payment messages. When deployed alongside messaging skills, the combined capabilities — invoice creation with arbitrary recipient details, customer data enumeration, balance queries, and WhatsApp message delivery — create an attack surface for social engineering fraud. An adversarial agent context could silently enumerate get_latest_transactions or get_customer_detail to harvest customer contact information, then generate and send fraudulent payment requests. The skill itself has no malicious instructions, but its high-value financial capabilities warrant awareness.