Back to skill

Security audit

RedotPay Wallet

Security checks for vulnerabilities and agentic risk

Overview

The skill is mostly clear about using RedotPay for service lookup and paid requests, but its setup instructions run an unverified remote installer.

Install only if you trust the RedotPay CLI source and are comfortable with a payment-capable local tool. Prefer verifying the installer or using a signed/package-manager installation before running it, and confirm costs and spend caps before any paid request.

Vulnerability Patterns
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • 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
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
Findings (1)

T03 · Remote Payload Retrieval and Execution

Error
Location
SKILL.md:178
Finding

Unverified Remote Installer Download and Execution

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 178–180
Vulnerability Type: Remote payload retrieval and execution without effective integrity verification
Risk Level: High

Vulnerable Code:

bash
curl -fsSL "https://raw.githubusercontent.com/redotpay/redotpay-cli/v0.1.0/install.sh" -o redotpay-install.sh
shasum -a 256 -c SHA256SUMS --ignore-missing
bash redotpay-install.sh

Technical Analysis

The installation instructions download a shell script from an external GitHub raw-content URL and subsequently execute it with bash. This creates a remote code-execution channel whose effective payload is controlled outside the reviewed Skill package and can change after the Skill has been audited.

Although the workflow includes a checksum command, the project contains no SHA256SUMS file and does not retrieve or embed a trusted expected digest. Consequently, the command cannot authenticate the downloaded installer against a value established by this reviewed package. The use of --ignore-missing further weakens the intended validation. Moreover, the commands are not chained with &&, so execution of bash redotpay-install.sh is not explicitly conditioned on successful checksum verification.

The URL references the v0.1.0 Git tag rather than an immutable content digest. A tag may potentially be moved, and compromise of the referenced repository or publisher account could allow replacement of the installer. HTTPS protects transport in ordinary circumstances but does not protect against a compromised or malicious upstream publisher.

Executing an externally controlled shell script is broader than the minimum privileges required for the Skill’s declared service-discovery and data-retrieval functionality. The script runs with all permissions of the invoking user rather than a narrowly scoped permission set.

Attack Path

  1. The agent or user determines that the required redotpay execut ...[truncated 1507 chars]
Remediation
View remediation

Remediation Suggestions

  1. Remove the direct download-and-execute workflow and prefer an official package manager that supports signed metadata, version locking, and reproducible package verification.
  2. If direct installation is unavoidable, reference an immutable release artifact or commit digest rather than a mutable Git tag.
  3. Embed the exact expected SHA-256 digest in the reviewed Skill or obtain it through an independently authenticated, signed release manifest.
  4. Verify the downloaded file against that exact digest and abort immediately on any mismatch or verification error.
  5. Make execution explicitly conditional on successful verification, for example by using set -e and chaining verification and execution with &&.
  6. Verify a publisher signature using a pinned, independently distributed public key in addition to checking a hash.
  7. Avoid executing an installer with elevated privileges. Install the verified binary into a user-scoped directory with the minimum filesystem permissions necessary.
  8. Pin and document the expected CLI version, artifact URL, hash, signing identity, and supported platform so reviewers can independently validate the complete installation chain.
  9. Consider distributing the verified executable as part of a trusted, signed release process rather than executing a general-purpose shell installer.
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.