jd-clawtip-payment-skill

• Outcome: Review
• Latest audit: May 28, 2026 at 8:22 AM UTC
• Version:
  1.0.13

Overview

This payment skill matches its stated purpose, but it handles payment tokens and transaction submission with enough weak controls that users should review it carefully before installing.

Install only if you trust the publisher and the JD payment flow, can protect local logs, and are comfortable with a payment token being stored locally in base64. Before use, require an explicit review of payee, amount, and resource for every payment, and prefer a version that removes raw token printing, uses a real secret store, and provides token deletion or expiry controls. The Review verdict is based on artifact evidence, not the stale VirusTotal status or the scanner score alone.

SkillSpector

By NVIDIA

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Behavioral AST: exec() Call, eval() Call, Dynamic Import
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (16)

subprocess module call

Medium

• Category: Dangerous Code Execution

Content

js_script_path = current_dir / 'test2.js'

        if user_token:
            result = subprocess.run(
                ["node", str(js_script_path), user_token, base64_pub_key],
                capture_output=True,
                text=True,

• Confidence: 91% confidence
• Finding: result = subprocess.run( ["node", str(js_script_path), user_token, base64_pub_key], capture_output=True, text=True, check=Tr

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 89% confidence
• Finding: The skill exposes capabilities beyond its stated safe-use constraints: it can directly create and persist a user token from arbitrary input, stores that token in a local file using only base64, and performs remote status/encryption-related calls not clearly bounded by strong validation. This is dangerous because a caller may coerce the skill into storing attacker-controlled credentials or misusing an existing token, leading to unauthorized payment/account actions and credential exposure on a host shared with other skills or users.

Description-Behavior Mismatch

Medium

• Confidence: 93% confidence
• Finding: The script stores a payment-related user token on disk in a locally readable config file using only base64 encoding, which is not security protection. In a payment skill context, persisting bearer-style tokens expands the attack surface because any local compromise, log access, backup exposure, or unintended file sharing could enable unauthorized payment actions or account access.

Intent-Code Divergence

Medium

• Confidence: 88% confidence
• Finding: The function is documented as only querying registration status, but on success it also persists the returned token to disk. This hidden side effect is dangerous in a payment-related skill because reviewers, callers, or users may not realize that sensitive credentials are being retained beyond the immediate transaction flow.

Context-Inappropriate Capability

Medium

• Confidence: 88% confidence
• Finding: A payment skill is expected to perform narrowly scoped transaction handling, but this code executes an auxiliary Node.js script outside that scope. In a payment context, any unnecessary execution capability is more dangerous because it can process secrets and alter transaction behavior without clear visibility to the caller.

Description-Behavior Mismatch

Medium

• Confidence: 96% confidence
• Finding: This file is a full client-side cryptography and storage library implementing SM2/SM3/SM4 operations, handshake logic, encryption/decryption, HMAC, and local persistence, which is materially broader than a payment-only skill needs. In a payment skill, this kind of surplus capability increases attack surface, obscures data flows, and makes it harder to verify that keys and payment-related data are handled safely and only for the declared purpose.

Context-Inappropriate Capability

Medium

• Confidence: 98% confidence
• Finding: The code stores encryption-related material (`aksKey` and derived encrypted storage values) in localStorage or app storage, protected only by hardcoded client-side SM4 keying material also present in the bundle. Because both the protection logic and embedded secrets are available to an attacker with client-side access, stored material can be recovered or abused, especially in a payment context where compromise may enable message decryption, replay support, or fraudulent request construction.

Context-Inappropriate Capability

Low

• Confidence: 90% confidence
• Finding: The library exposes generic test, decrypt, and decrypt-with-HMAC helpers beyond the stated payment/request-token purpose, creating unnecessary capability for handling arbitrary encrypted payloads. Extra decryption and testing surfaces are risky in a payment skill because they expand the number of paths that may process attacker-controlled ciphertext, complicate auditing, and may be repurposed by other code to access protected data.

Missing User Warnings

Medium

• Confidence: 84% confidence
• Finding: The script transmits the provided device identifier and related request metadata to remote payment-service APIs without any visible user disclosure or consent boundary. In a payment skill, silent transmission of device-linked identifiers is privacy-sensitive and can enable tracking, correlation, or unintended data sharing with third-party systems.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The code writes the returned user token to local storage without prior user disclosure or confirmation, creating a hidden persistence channel for payment credentials. In the context of a payment skill, undisclosed token retention materially increases the risk of credential theft and unauthorized reuse by other local processes, users, or malware.

Missing User Warnings

Medium

• Confidence: 97% confidence
• Finding: The script persists a sensitive payment-related token to disk and also prints the token to stdout, which can expose it through logs, terminal history, process supervision output, or other local monitoring mechanisms. In the context of a payment skill, token disclosure is especially risky because leaked credentials may enable unauthorized payment actions or account misuse by other skills or local users.

Missing User Warnings

High

• Confidence: 99% confidence
• Finding: The function prints the recovered userToken directly to output, exposing a sensitive credential in logs or terminal history. In a payment skill, token disclosure is especially dangerous because it may enable account impersonation, transaction abuse, or downstream compromise if logs are collected centrally.

Missing User Warnings

High

• Confidence: 97% confidence
• Finding: The code emits the full serialized payment request and then transmits it without any user confirmation step. This can leak sensitive transaction metadata to logs and enables silent payment initiation, which is particularly risky in a payment-processing skill where users should explicitly authorize value transfer.

Missing User Warnings

Medium

• Confidence: 85% confidence
• Finding: The skill executes an external Node.js process on sensitive payment data without clear disclosure or consent. In this context, hidden processing is risky because it handles userToken-derived material and could exfiltrate or transform data in ways not apparent from the primary Python code.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The code writes encryption-related state to local/app storage without any visible notice, consent flow, or disclosure in this file. In a payment-related skill, silent persistence of security-sensitive state increases privacy and trust concerns and can mask long-lived client tracking or retention of material that users would not expect to remain on the device.

Missing User Warnings

Medium

• Confidence: 88% confidence
• Finding: The code sends handshake/client cryptographic material over network requests without any visible user disclosure or transparency in this file about what is sent, why, or to which trust boundary. In the context of a payment skill, undisclosed transmission of client cryptographic state is more sensitive because it may relate to device binding, tokenization, or payment-session establishment and therefore carries privacy and security implications.

VirusTotal

VirusTotal engine telemetry is currently stale for this artifact.