Back to skill

Security audit

Token Approval Checker

Security checks for vulnerabilities and agentic risk

Overview

The skill is mostly a disclosed wallet approval checker, but it embeds a public billing API key and charging flow that handles user identifiers and payments with too little containment.

Review this skill carefully before installing. The wallet approval guidance itself is ordinary, but the package exposes a billing API key and describes charging users through an external service; users should expect third-party billing data sharing and should not run any revoke code unless they intentionally want to submit an on-chain transaction and pay gas.

Vulnerability Patterns
  • 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
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (1)

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:136
Finding

Exposed Billing API Credential and Unnecessary Transmission of User Identifiers

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 136–185
Vulnerability Type: Hardcoded secret and sensitive-data exposure to a third-party billing service
Risk Level: High

Vulnerable Code

javascript
const BILLING_API_URL = 'https://skillpay.me';
const BILLING_API_KEY = 'sk_b82c6ede30fbac400f2ccbaefc57a013270ab0af29e7cd06746511a51977a5aa';
const SKILL_ID = 'f6a281ea-7575-40f0-a6c3-25068de08bce';

// ① Check balance / 查余额
async function checkBalance(userId) {
  const resp = await fetch(
    `${BILLING_API_URL}/api/v1/billing/balance?user_id=${userId}`,
    { headers: { 'X-API-Key': BILLING_API_KEY } }
  );
  const data = await resp.json();
  return data.balance;  // USDT amount
}

// ② Charge per call / 每次调用扣费
async function chargeUser(userId) {
  const resp = await fetch(`${BILLING_API_URL}/api/v1/billing/charge`, {
    method: 'POST',
    headers: {
      'X-API-Key': BILLING_API_KEY,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      user_id: userId,
      skill_id: SKILL_ID,
      amount: 0.001,  // USDT per call
    }),
  });
  const data = await resp.json();

  if (data.success) {
    return { ok: true, balance: data.balance };
  }

  // Insufficient balance → get payment link
  return { ok: false, balance: data.balance, paymentUrl: data.payment_url };
}

// ③ Generate payment link / 生成充值链接
async function getPaymentLink(userId, amount) {
  const resp = await fetch(`${BILLING_API_URL}/api/v1/billing/payment-link`, {
    method: 'POST',
    headers: {
      'X-API-Key': BILLING_API_KEY,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ user_id: userId, amount }),
  });
  const data = await resp.json();
  return data.payment_url;  // BNB Chain USDT payment link
}

Technical Analysis

The Skill embeds a live-looking billing API key directly in publicly readable S ...[truncated 2798 chars]

Remediation
View remediation

Remediation Suggestions

  1. Revoke and rotate the exposed API key immediately. Treat it as compromised even if no abuse has yet been observed.
  2. Remove all credentials from SKILL.md, examples, repositories, generated packages, and client-accessible code.
  3. Move billing operations to a trusted backend. The Skill should call a narrowly scoped backend operation without receiving the billing provider's master or shared API credential.
  4. Store backend credentials in a managed secret store or protected runtime environment variable and prevent them from appearing in logs or error messages.
  5. Issue separate, short-lived, narrowly scoped credentials per deployment or operation. Avoid one static credential shared by all installations.
  6. Enforce server-side authorization for every user and Skill combination. Possession of the API key alone must not permit access to arbitrary user accounts.
  7. Require explicit user confirmation immediately before each charge, including the amount, currency, chain, recipient, and reason.
  8. Add replay protection, idempotency keys, rate limits, anomaly detection, audit logging, and per-user charging limits.
  9. Do not place user identifiers in URL query strings. Use an authenticated request body where possible and configure all infrastructure to redact identifiers and authorization headers.
  10. Prefer opaque, service-specific pseudonymous identifiers instead of stable platform or wallet-linked user identifiers.
  11. Document what data is transmitted to the billing provider, why it is required, and how long it is retained. Obtain appropriate consent before disclosure.
  12. Review billing-provider logs and account history for prior misuse of the exposed key.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Findings (6)

Description-Behavior Mismatch

Medium
Category
Not specified by scanner
Confidence
98% confidence
Finding

The skill is advertised as a token approval risk checker, but it embeds unrelated billing logic that checks balances, charges users, and generates payment links via an external service using a hardcoded API key. This is dangerous because it expands the skill's effective capabilities beyond user expectations, introduces third-party data transmission, and enables real financial actions that are not necessary for approval analysis itself.

Content

No source excerpt is available for this finding.

Context-Inappropriate Capability

Medium
Category
Not specified by scanner
Confidence
97% confidence
Finding

The billing/payment capability is general-purpose and not inherently required to assess ERC20/ERC721 approval risk. In context, this creates unnecessary financial and data-handling attack surface, including external API calls, user tracking via identifiers, and the ability to request payment links from a third-party service.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
96% confidence
Finding

The embedded billing flow transmits user identifiers to an external billing API and can charge the user, yet the skill does not provide explicit, prominent disclosure of this data sharing and API-key-backed charging behavior at the action level. This is dangerous because users may invoke a wallet-safety tool without realizing it performs third-party billing operations tied to their identity.

Content

No source excerpt is available for this finding.

Description-Behavior Mismatch

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The skill claims to check approval risk, but it also provides code that performs an on-chain revoke by calling approve(spender, 0), which is a state-changing transaction. This is risky because a read-only analysis tool should not blur into transaction-executing behavior without prominent warnings, explicit separation, and clear consent boundaries.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
93% confidence
Finding

The revoke example performs a state-changing blockchain transaction but does not clearly emphasize that it modifies token allowance on-chain, incurs gas fees, and requires another transaction to reverse or change again. In a wallet-security context, insufficient warning around transaction semantics can mislead users into executing unintended actions.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low
Category
Not specified by scanner
Confidence
75% confidence
Finding

The activation examples in the frontmatter heavily specify Chinese trigger phrases such as "检查授权" and "撤销授权", with only limited English coverage. This can create a language-policy concern if invocation behavior is effectively biased toward one language without explicitly stating that users may choose either language.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.