Back to skill

Security audit

iautopay

Security checks for vulnerabilities and agentic risk

Overview

The skill is not overtly malicious, but it handles wallet payments and API keys while documenting insecure credential transport and an overbroad money-transfer endpoint.

Review carefully before installing. Use only a dedicated low-balance testnet wallet, do not send bearer API keys over HTTP, verify HTTPS support for all authenticated endpoints, confirm the exact chain, token contract, recipient, amount, and expiry before signing, avoid the arbitrary transfer endpoint unless you intentionally need it, and pin dependencies before running wallet-signing examples.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (3)

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:142
Finding
Bearer API Credentials Transmitted over Plaintext HTTP## Vulnerability Details **File Location**: `SKILL.md:142-143` **Additional Locations**: `SKILL.md:16`, `SKILL.md:182-183`, `SKILL.md:269-270`, `SKILL.md:307-308`, `SKILL.md:360-361`, `SKILL.md:400-401` **Vulnerability Type**: Cleartext transmission of sensitive credentials **Risk Level**: High ### Vulnerable Code ```bash curl "http://ipaynapi.gpuart.cn/user/me" \ -H "Authorization: Bearer YOUR_API_KEY" ``` The same plaintext HTTP pattern is documented for `/user/my-keys`: ```bash curl "http://ipaynapi.gpuart.cn/user/my-keys" \ -H "Authorization: Bearer YOUR_API_KEY" ``` ### Technical Analysis The Skill instructs users to transmit a bearer API key to `ipaynapi.gpuart.cn` over unencrypted HTTP. Bearer credentials grant access based solely on possession, so transport-layer confidentiality and integrity are mandatory. HTTP provides neither property. Network intermediaries can observe the `Authorization` header or modify the server response. The endpoints are especially sensitive because `/user/me` and `/user/my-keys` return account information, wallet metadata, transaction details, and active API keys. This behavior is not required for the declared account-management functionality. The same requests should be made exclusively over authenticated HTTPS. ### Attack Path 1. A user follows the Skill documentation and calls an account endpoint using `http://ipaynapi.gpuart.cn`. 2. The request traverses an untrusted network, proxy, gateway, Wi-Fi access point, or other intermediary. 3. An attacker captures the plaintext `Authorization: Bearer ...` header. 4. The attacker replays the stolen bearer credential against the user-management service. 5. Subject to the credential's server-side privileges, the attacker retrieves account details, wallet metadata, usage information, transaction history, or API-key records. 6. A man-in-the-middle attacker may also modify plaintext responses presented to the user. ## ...[truncated 459 chars]
Remediation
## Remediation Suggestions 1. Replace every `http://ipaynapi.gpuart.cn` URL with an authenticated `https://` endpoint. 2. Configure the server to reject plaintext HTTP rather than silently serving authenticated endpoints over it. 3. Redirecting HTTP to HTTPS is not sufficient for requests already carrying credentials; clients must originate authenticated requests over HTTPS. 4. Enable HSTS with an appropriate policy after confirming complete HTTPS support. 5. Validate certificates and hostnames using standard TLS verification. Do not add certificate-verification bypasses. 6. Rotate any API key that may previously have been transmitted over plaintext HTTP. 7. Minimize endpoint responses so that one API key cannot unnecessarily retrieve other complete API-key values. 8. Consider short-lived, scoped access tokens instead of long-lived bearer API keys for account-management operations.

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:562
Finding
Untrusted Remote Quote Controls Financial Authorization Parameters## Vulnerability Details **File Location**: `SKILL.md:562-613` **Additional Location**: `SKILL.md:744-779` **Vulnerability Type**: Insufficient validation before cryptographic payment authorization **Risk Level**: High ### Vulnerable Code ```python # Step 1: Get payment quote info_response = requests.get("https://apipaymcp.okart.fun/info") info = info_response.json() payee_address = info['payee'] usdc_address = info['asset'] price_in_usdc = info['prices'][f'{duration}daysUsdc'] # USDC uses 6 decimals amount = int(price_in_usdc * 10 ** 6) # Step 2: Create EIP-3009 signature # For Base Sepolia USDC: name="USDC", version="2" domain = { "name": "USDC", "version": "2", "chainId": 84532, "verifyingContract": usdc_address } message_types = { "TransferWithAuthorization": [ {"name": "from", "type": "address"}, {"name": "to", "type": "address"}, {"name": "value", "type": "uint256"}, {"name": "validAfter", "type": "uint256"}, {"name": "validBefore", "type": "uint256"}, {"name": "nonce", "type": "bytes32"} ] } nonce = os.urandom(32).hex() now = int(time.time()) valid_after = 0 valid_before = now + 28800 # 8 hours message = { "from": account.address, "to": payee_address, "value": amount, "validAfter": valid_after, "validBefore": valid_before, "nonce": f"0x{nonce}" } # Sign typed data signed_message = w3.eth.account.sign_typed_data( private_key=private_key, domain=domain, message_types=message_types, message=message ) ``` ### Technical Analysis The code retrieves the token contract, payment recipient, and price from the remote `/info` endpoint and directly incorporates those values into an EIP-3009 `TransferWithAuthorization` signature. It does not compare the response against the Base Sepolia USDC contract and payee constants declared elsewhe ...[truncated 2102 chars]
Remediation
## Remediation Suggestions 1. Pin the expected chain ID, USDC contract address, and permitted payee address in locally reviewed configuration. 2. Reject the quote if any returned chain, asset, or payee value differs from the pinned values. 3. Define local prices or strict maximum payment amounts for each supported duration. Never let a remote response alone determine the maximum authorized amount. 4. Parse monetary values using exact decimal or integer arithmetic rather than binary floating-point conversion. 5. Validate that `duration` is one of `1`, `7`, or `30` inside the function, even when callers normally use CLI argument restrictions. 6. Display the chain, token contract, recipient, exact base-unit amount, and expiry, then require explicit user confirmation before signing. 7. Reduce the eight-hour authorization window to the shortest operationally practical duration. 8. Use a dedicated low-balance wallet with no unrelated assets or permissions. 9. Check HTTP status, content type, schema, field types, and bounds before processing the quote. 10. Keep signing isolated from general network-processing code where practical, and pass only a fully validated authorization request to the signer.

T08 · Insecure Dependencies

Warning
Location
SKILL.md:454
Finding
Security-Sensitive Dependencies Installed without Version or Integrity Pinning## Vulnerability Details **File Location**: `SKILL.md:454-460` **Vulnerability Type**: Unpinned third-party dependencies in a wallet-signing workflow **Risk Level**: Medium ### Vulnerable Code ```bash # TypeScript/Bun bun add viem dotenv # Python pip install web3 requests python-dotenv ``` ### Technical Analysis The installation instructions resolve mutable package versions from package registries without exact versions, committed lockfiles, or integrity hashes. Consequently, the code that executes during installation and runtime may differ over time from the versions originally reviewed. This is particularly sensitive because the listed libraries run in a process that reads `AUTOPAY_PKEY`, derives a wallet account, constructs signatures, and performs network requests. A compromised upstream release or malicious dependency introduced into the resolved dependency graph could access the private key, alter authorization parameters, or transmit secrets. The audit did not find a confirmed malicious package name or an existing embedded malicious dependency. The vulnerability is the unsafe, non-reproducible dependency installation procedure and the resulting supply-chain exposure. ### Attack Path 1. An attacker compromises a listed package, one of its transitive dependencies, a maintainer account, or the relevant package-distribution path. 2. A malicious release becomes the version selected by the unpinned `bun add` or `pip install` command. 3. A user follows the Skill instructions and installs that release. 4. Malicious package code executes during installation or when imported by the purchase scripts. 5. At runtime, the process has access to `AUTOPAY_PKEY`, payment parameters, generated signatures, and returned API keys. 6. The malicious dependency can exfiltrate those secrets or manipulate payment authorization behavior with the process's user-level and network privileges. ### Impact Assessment A successfully ...[truncated 513 chars]
Remediation
## Remediation Suggestions 1. Pin every direct dependency to an exact reviewed version. 2. Commit the appropriate lockfile for Bun and require frozen-lockfile installation in automated and documented workflows. 3. Use a fully pinned Python requirements file with cryptographic hashes, such as `pip install --require-hashes -r requirements.txt`. 4. Review and constrain transitive dependencies rather than pinning only direct packages. 5. Use trusted package indexes and repository configuration; do not permit unexpected fallback registries. 6. Disable dependency installation scripts where they are unnecessary and supported by the package manager. 7. Run dependency vulnerability and provenance checks in continuous integration. 8. Perform signing in an isolated process or hardware-backed signer that does not expose the raw private key to general application dependencies. 9. Continue using a dedicated wallet with minimal funds and no unrelated permissions. 10. Regularly review and deliberately update pinned versions rather than automatically resolving the newest releases.
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
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Findings (15)

Missing User Warnings

High
Confidence
99% confidence
Finding
The example sends a bearer API key over plain HTTP to `ipaynapi.gpuart.cn`, exposing credentials to interception or modification by any network adversary. Because the endpoint returns user/account details and key information, compromise of the bearer token could enable unauthorized account access and further abuse.

Missing User Warnings

High
Confidence
99% confidence
Finding
This repeated example again instructs clients to transmit bearer credentials over unencrypted HTTP. Repetition normalizes insecure usage and increases the likelihood that integrators copy unsafe patterns into production, leading to credential theft and account compromise.

Context-Inappropriate Capability

High
Confidence
98% confidence
Finding
The documented `/v1/transfer` endpoint enables arbitrary USDC payments unrelated to the declared API-key purchase purpose. In an agent setting, such a capability materially broadens the blast radius from 'buy a subscription' to 'send money anywhere,' which is dangerous if prompt injection, misrouting, or tool misuse occurs.

Missing User Warnings

High
Confidence
99% confidence
Finding
The duplicated user-management examples continue to expose API keys via HTTP without any warning. Since these examples are likely copy-pasted by users, they create a realistic path for credential interception and unauthorized access to wallet-linked account data and API keys.

Missing User Warnings

High
Confidence
99% confidence
Finding
The `napi-ser` section repeats insecure authenticated HTTP usage, making the problem systemic rather than incidental. In a security-sensitive payment skill, instructing users to send bearer tokens over HTTP is a serious documentation flaw because it can directly lead to credential compromise.

Credential Access

High
Category
Privilege Escalation
Content
# Set in shell
    export AUTOPAY_PKEY="0x..."
    
    # Or in .env file
    echo "AUTOPAY_PKEY=0x..." > .env
    ```
Confidence
60% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High
Category
Privilege Escalation
Content
# Set in shell
    export AUTOPAY_PKEY="0x..."
    
    # Or in .env file
    echo "AUTOPAY_PKEY=0x..." > .env
    ```
Confidence
60% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

External Transmission

Medium
Category
Data Exfiltration
Content
Get current server status, pricing, and configuration.

```bash
curl "https://apipaymcp.okart.fun/info"
```

**Response:**
Confidence
60% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Description-Behavior Mismatch

Medium
Confidence
97% confidence
Finding
The skill advertises and documents a general-purpose stablecoin transfer endpoint even though its stated purpose is purchasing and managing API keys. Expanding a narrowly scoped payment skill into arbitrary fund transfer increases the chance an agent could be induced to move user funds to attacker-controlled addresses under the guise of normal skill usage.

Missing User Warnings

Medium
Confidence
92% confidence
Finding
The documentation describes state-changing financial and account-creation actions without clearly warning that using them can move funds and create persistent server-side accounts linked to a wallet. In agent workflows, missing disclosures increase the risk of users or orchestration layers invoking impactful actions without informed consent.

External Transmission

Medium
Category
Data Exfiltration
Content
Get your user account information, API keys, and usage statistics. **Requires authentication with your API key.**

```bash
curl "http://ipaynapi.gpuart.cn/user/me" \
  -H "Authorization: Bearer YOUR_API_KEY"
```
Confidence
98% confidence
Finding
This example transmits an `Authorization: Bearer` API key to an HTTP endpoint, enabling credential theft through passive sniffing or active man-in-the-middle interception. Because the token grants access to user/account information and key listings, exposure can lead to account takeover or unauthorized data access.

External Transmission

Medium
Category
Data Exfiltration
Content
}
    
    # Step 3: Call buy-apikey with EIP-3009 signature
    buy_response = requests.post(
        "https://apipaymcp.okart.fun/v1/buy-apikey",
        headers={
            "Content-Type": "application/json",
Confidence
60% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
};
  
  // Step 3: Call buy-apikey with EIP-3009 signature
  const buyResponse = await fetch("https://apipaymcp.okart.fun/v1/buy-apikey", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
Confidence
60% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
};
  
  // Step 3: Call buy-apikey with EIP-3009 signature
  const buyResponse = await fetch("https://apipaymcp.okart.fun/v1/buy-apikey", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
Confidence
60% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Description-Behavior Mismatch

Low
Confidence
90% confidence
Finding
The manifest says the skill purchases API keys using USDC on Base chain, which commonly implies production Base, but the implementation and examples consistently use Base Sepolia testnet (`eip155:84532`, `https://sepolia.base.org`). This creates a semantic mismatch about the actual payment network and operational environment.

Static analysis

No suspicious patterns detected.