Back to skill

Security audit

PayRam MCP Integration

Security checks for vulnerabilities and agentic risk

Overview

This skill fits a crypto-payment setup purpose, but it needs review because it directs agents to run unverified remote scripts, handle passwords and wallet mnemonics, and automate wallet and contract operations.

Install only after carefully reviewing the external PayRam scripts at a pinned version, and avoid running the headless or self-host commands in a production or wallet-bearing environment. Use testnet funds first, keep PayRam passwords and wallet mnemonics out of shell history and project files where possible, confirm destination addresses and chain choices manually, and treat any exposed mnemonic as compromised.

Vulnerability Patterns
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • 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
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (3)

T03 · Remote Payload Retrieval and Execution

Error
Location
SKILL.md:132
Finding
Mutable Remote Installation Script Is Downloaded and Executed Without Verification<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:132` **Vulnerability Type**: `T03: Remote Payload Retrieval and Execution` **Risk Level**: Critical ### Vulnerable Code ```bash /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/PayRam/payram-scripts/main/setup_payram.sh)" ``` ### Technical Analysis The documented self-hosting procedure downloads a shell script from the mutable `main` branch of an external GitHub repository and passes its contents directly to Bash. No immutable commit, signed release, cryptographic signature, or expected checksum is specified. The remote script is not included in the audited project, so its effective behavior cannot be reviewed from this package. Its contents can change after the Skill has passed review. The `curl -fsSL` options do not establish payload integrity. HTTPS protects the connection in transit but does not protect against: - Compromise of the upstream GitHub account or repository. - Malicious or accidental changes to the `main` branch. - Compromise of the upstream development process. - Repository ownership or access-control changes. Immediate execution also prevents the user from reviewing the downloaded content before it runs. This behavior is not necessary for the minimum declared functionality of connecting to the hosted MCP endpoint. A hosted connection only requires the separate `mcporter config add` operation. ### Attack Path 1. An attacker compromises the upstream repository, a maintainer account, or the release workflow. 2. The attacker modifies `setup_payram.sh` on the `main` branch. 3. A user follows the self-hosted setup command from `SKILL.md`. 4. `curl` downloads the attacker-controlled version. 5. Bash immediately executes the payload with the privileges of the invoking user. 6. The payload can access local files, credentials, wallet material, containers, or network resources available to that user. ### Impact Assessment Successful exploitation provides arbitrary comm ...[truncated 620 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove the direct `curl`-to-Bash execution pattern. 2. Publish versioned, immutable releases and reference a specific release or commit. 3. Download the installer as a separate file without executing it: ```bash curl -fL -o setup_payram.sh https://example.invalid/path/to/versioned/setup_payram.sh ``` 4. Publish the expected SHA-256 checksum through an independently protected release channel and verify it before execution: ```bash echo "<EXPECTED_SHA256> setup_payram.sh" | sha256sum --check ``` 5. Cryptographically sign releases and require signature verification using a documented trusted signing key. 6. Instruct users to inspect the downloaded script before running it. 7. Vendor the reviewed installation script in the Skill package where practical. 8. Run installation with the least privileged dedicated account and avoid requesting root access unless a documented operation strictly requires it. 9. Separate optional self-hosting installation from the minimal hosted MCP connection workflow. ]]>

T03 · Remote Payload Retrieval and Execution

Error
Location
SKILL.md:104
Finding
Unpinned External Repository Scripts Receive Credentials and Perform Wallet Operations<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:104-109` **Vulnerability Type**: `T03: Remote Payload Retrieval and Execution, T08: Insecure Dependencies` **Risk Level**: High ### Vulnerable Code ```bash git clone https://github.com/PayRam/payram-scripts cd payram-scripts export PAYRAM_EMAIL="agent@example.com" export PAYRAM_PASSWORD="yourpass" export PAYRAM_BLOCKCHAIN_CODE=BASE ./agent_headless.sh run # wallet created, contracts deployed, ready ``` ### Technical Analysis The procedure clones the repository's current default branch without selecting or verifying an immutable revision. It then executes `agent_headless.sh` while authentication credentials are present in the process environment. The command is documented as creating a wallet and deploying contracts. These are financially sensitive operations with substantially greater authority than the minimum required to connect to the advertised hosted MCP service. Because the cloned script is absent from the audited artifact, its handling of the following cannot be verified: - `PAYRAM_EMAIL` and `PAYRAM_PASSWORD`. - Generated wallet secrets and derivation material. - Contract bytecode and constructor arguments. - Fund-collector or destination addresses. - External endpoints contacted during setup. - Commands executed on the local host. A mutable default branch can change after review. An upstream compromise could therefore convert the documented workflow into credential theft, wallet-key theft, malicious contract deployment, or arbitrary local execution. ### Attack Path 1. An attacker gains the ability to modify the default branch of `PayRam/payram-scripts`, or compromises a dependency used by its scripts. 2. The attacker changes `agent_headless.sh` or a script that it invokes. 3. A user clones the repository without pinning a reviewed commit. 4. The user exports PayRam credentials and runs `agent_headless.sh`. 5. The modified script reads inherited environment variables or newly gene ...[truncated 1182 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Pin the repository to a specific reviewed commit or signed release: ```bash git clone https://github.com/PayRam/payram-scripts cd payram-scripts git checkout <REVIEWED_COMMIT_HASH> ``` 2. Verify the commit or release signature against a documented trusted maintainer key. 3. Publish and verify checksums for all scripts and contract artifacts. 4. Include security-relevant scripts and contract source in the auditable Skill package where possible. 5. Separate authentication, wallet generation, and contract deployment into distinct, explicitly approved steps. 6. Do not expose passwords through long-lived shell environment variables. Use protected standard input, an OS credential store, or a dedicated secret manager. 7. Run setup in a restricted container or dedicated low-privilege account with narrowly scoped filesystem and network access. 8. Present and require confirmation of wallet addresses, fund-collector destinations, chain identifiers, and contract bytecode hashes before deployment. 9. Ensure production wallet operations use a hardware wallet or external signer rather than exposing mnemonic material to general-purpose setup scripts. 10. Document every external endpoint contacted and allow users to restrict outbound traffic accordingly. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
references/headless-setup.md:23
Finding
Authentication Tokens and Wallet Mnemonics Are Persisted in Plaintext Project Files<![CDATA[ ## Vulnerability Details **File Location**: `references/headless-setup.md:23,52-54,93` **Vulnerability Type**: `T09: Insecure Skill Coding Practices` **Risk Level**: High ### Vulnerable Documentation ```text | `signin` | Sign in; saves token to `.payraminfo/headless-tokens.env` | ``` ```text | `PAYRAM_MNEMONIC` | — | Or mnemonic in `.payraminfo/headless-wallet-secret.txt` | Token is read from `.payraminfo/headless-tokens.env` (created by signin). Deploy-scw uses mnemonic from that file or `PAYRAM_MNEMONIC`. ``` ```text - **Token / secrets:** `.payraminfo/headless-tokens.env`, `.payraminfo/headless-wallet-secret.txt` (mnemonic). Do not commit. ``` ### Technical Analysis The documented design stores an authentication token and a wallet recovery mnemonic in ordinary files under the project directory. A mnemonic generally provides complete authority over all wallet keys derived from it. A bearer token may permit API impersonation for as long as it remains valid. The only documented protection is an instruction not to commit the files. That does not protect them against: - Permissive filesystem permissions. - Other local users or processes. - Malware and compromised development tools. - Automated backup, indexing, or synchronization systems. - Accidental archives or project-directory copies. - Diagnostic bundles and support uploads. - Container bind mounts or CI artifacts. The documentation does not state that files are created atomically with owner-only permissions, encrypted at rest, excluded from backups, or securely deleted. It also does not describe token scope, expiration, or rotation. ### Attack Path 1. The sign-in or wallet-deployment workflow writes a token or mnemonic into `.payraminfo`. 2. The project directory is copied, backed up, indexed, synchronized, archived, exposed through a development service, or read by another local process. 3. An attacker obtains `headless-tokens.env` or `headless-wallet-secret.txt`. 4. The attacker impor ...[truncated 902 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Do not persist wallet mnemonics in plaintext project files. 2. Use a hardware wallet, external signer, operating-system keychain, or dedicated secrets manager. 3. If file storage is unavoidable: - Encrypt the secret at rest with a key stored separately. - Create the file atomically with owner-only permissions such as mode `0600`. - Verify directory ownership and permissions before writing. - Prevent symlink and path-substitution attacks. - Exclude the file from backups, indexing, synchronization, and diagnostic collection. 4. Add explicit ignore rules for `.payraminfo` to all relevant version-control and packaging configurations. Treat this only as defense in depth, not the primary protection. 5. Use short-lived, narrowly scoped authentication tokens with rotation and revocation support. 6. Avoid storing reusable account passwords in files or command history. 7. Redact tokens, mnemonics, and private keys from all logs and error output. 8. Provide a secure deletion and credential-rotation procedure. 9. Document that any exposed mnemonic must be abandoned and all assets transferred to a newly generated wallet. 10. Separate testnet and production credentials and prevent production wallet secrets from being used in routine automated setup. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Findings (8)

Missing User Warnings

High
Confidence
95% confidence
Finding
The headless setup instructs users to export credentials and run a fully non-interactive script that creates wallets and deploys contracts, yet provides no warning about financial risk, secret handling, irreversible on-chain actions, or environment isolation. In the context of an agent skill, omission of these warnings materially increases the chance of unsafe autonomous execution.

Missing User Warnings

High
Confidence
99% confidence
Finding
Piping a remote script directly into bash without any warning is a classic arbitrary-code-execution hazard. Because this skill targets payment and agent infrastructure, successful compromise could expose credentials, alter payout logic, steal wallet material, or persist malware on hosts likely to hold sensitive financial data.

Credential Access

High
Category
Privilege Escalation
Content
| `PAYRAM_FUND_COLLECTOR` | deployer address | Cold wallet 0x (40 hex). Omit or leave empty to use deployer address from mnemonic. |
| `PAYRAM_SCW_NAME` | `Headless SCW` | Name for the SCW wallet |
| `PAYRAM_BLOCKCHAIN_CODE` | `ETH` | e.g. ETH, BASE, POLYGON |
| `PAYRAM_MNEMONIC` | — | Or mnemonic in `.payraminfo/headless-wallet-secret.txt` |

Token is read from `.payraminfo/headless-tokens.env` (created by signin). Deploy-scw uses mnemonic from that file or `PAYRAM_MNEMONIC`.
Confidence
88% confidence
Finding
The skill documents use of a mnemonic and token files stored in predictable local paths and environment variables, which are highly sensitive credentials for wallet control and authenticated API access. In an agent skill context, normalizing plaintext secret handling increases the chance that automation, logs, shell history, or other tools expose credentials that could enable account takeover or theft of crypto assets.

Credential Access

High
Category
Privilege Escalation
Content
## Files and scripts

- **Token / secrets:** `.payraminfo/headless-tokens.env`, `.payraminfo/headless-wallet-secret.txt` (mnemonic). Do not commit.
- **Scripts:** `scripts/generate-deposit-wallet.js` (BTC), `scripts/generate-deposit-wallet-eth.js` (ETH xpub), `scripts/deploy-scw-eth.js` (SCW deploy). Run via headless commands; deploy-scw is invoked by `./agent_headless.sh deploy-scw`.

---
Confidence
90% confidence
Finding
The documentation explicitly identifies the secret-bearing files for tokens and wallet mnemonic storage, which can guide an attacker or unsafe automation toward high-value credential targets. Because this skill is for headless/CLI automation of crypto payments, compromise of these files could directly enable unauthorized API actions or wallet deployment/use tied to financial operations.

Vague Triggers

Medium
Confidence
94% confidence
Finding
The description embeds trigger phrases such as 'accept crypto payments', 'create payment link', and especially 'PayRam', which are broad enough to overlap with ordinary user requests or mere mentions of the product. The file does not provide exclusion conditions or negative examples to clarify when the skill should or should not activate.

Context-Inappropriate Capability

Medium
Confidence
92% confidence
Finding
The skill advertises 'no KYC / no signup / no account' and then later provides headless instructions requiring PAYRAM_EMAIL and PAYRAM_PASSWORD plus automated wallet creation and contract deployment. This creates a deceptive trust boundary: an agent or user may treat the skill as low-risk integration guidance when it actually enables credentialed account operations and autonomous financial setup with minimal warning.

Context-Inappropriate Capability

Medium
Confidence
98% confidence
Finding
The self-hosted path executes a remote shell script via curl piped to bash, which grants arbitrary code execution from a network-fetched resource. In a skill intended for payment integration, this is especially dangerous because operators may run it on production hosts handling secrets, wallets, or payment infrastructure.

Missing User Warnings

Medium
Confidence
93% confidence
Finding
The documentation includes a destructive `reset-local` command that wipes local database and API data, but it does not present a strong inline warning about irreversible data loss at the command definition itself. In an agent/automation context, terse operational docs can lead to accidental execution, causing availability loss and destruction of local payment configuration, wallets, or test data.

Static analysis

No suspicious patterns detected.