Binance Event Contract Risk Manager

• Outcome: Review
• Latest audit: Sep 12, 2026 · 5:58 AM UTC
• Version: 1.0.0

Overview

The skill is not malicious, but its core trading-risk instructions can approve positions larger than its own stated limit.

Review this carefully before installing or using it for automated trading. The artifact does not show malware-like behavior, but its risk calculations should be corrected and independently tested before any approval can influence real trades. Prefer a pinned installer version and require explicit user confirmation for trade approvals.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (2)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:81
• Finding: Unpinned Package Execution Through npx## Vulnerability Details **File Location**: `SKILL.md`, lines 81-84 **Vulnerability Type**: Supply-chain risk from an unpinned executable dependency **Risk Level**: Medium **Vulnerable Code Snippet**: ```markdown ## Installation ```bash npx clawhub@latest install binance-event-contract-risk-manager --dir /workspace/skills ``` ``` ### Technical Analysis The installation procedure directs users to execute the mutable `latest` release of the `clawhub` package through `npx`. The command does not pin an exact reviewed version, verify an integrity hash, use a lockfile, or require inspection of the downloaded package before execution. Because `npx` can retrieve and execute package code, the effective code executed by this command may change after this Skill has been audited. Compromise of the package publisher, registry account, release pipeline, or a future release could consequently introduce arbitrary code into the installation process. ### Attack Path 1. An attacker compromises the package publisher, registry account, release pipeline, or mutable `latest` release. 2. The attacker publishes a malicious package version or modifies package lifecycle behavior. 3. A user follows the documented installation command. 4. `npx` retrieves the attacker-controlled release and executes its package entry point or lifecycle scripts. 5. The malicious package performs actions with the permissions of the invoking user and may modify the specified `/workspace/skills` directory or other user-accessible resources. ### Impact Assessment Successful exploitation could permit arbitrary code execution with the privileges of the user running the installation command. The accessible scope may include modification of installed skills, theft or alteration of user-readable files and environment variables, network access, and execution of additional processes. No privileged execution such as `sudo` is specified, so privilege escalation beyond the inv ...[truncated 53 chars]
• Remediation: ## Remediation Suggestions - Replace `@latest` with an exact, reviewed package version. - Verify the package using a registry integrity digest or an independently published checksum. - Document the expected registry and package publisher to reduce registry substitution risk. - Review the package contents and lifecycle scripts before execution. - Disable lifecycle scripts during installation where compatible with the package. - Use a lockfile or equivalent immutable dependency manifest. - Perform installation in a restricted environment with minimal filesystem, credential, and network access. - Establish a controlled upgrade process in which each new version is reviewed before the pinned version is changed.

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:19
• Finding: Position-Sizing Formula Compares Incompatible Units and Can Approve Oversized Trades## Vulnerability Details **File Location**: `SKILL.md`, lines 19-22 **Vulnerability Type**: Unsafe financial risk-control logic **Risk Level**: High **Vulnerable Code Snippet**: ```text Risk Amount = Capital × 2% Position Size = Risk Amount ÷ (Entry Price - Stop Loss) Max Position (USD) = Min(Capital × 5%, 250 USDT) ← Binance per-trade limit Final Position = Min(Risk-based Size, Max Position) ``` The inconsistency is also demonstrated by the approved example at lines 53-61: ```text 【 Risk Check PASSED | BTCUSDT Long | 12:10 UTC 】 Capital: 1,000 USDT Risk Amount (2%): 20 USDT Position Size: 0.023 BTC (≈157 USDT) ← within 5-250 USDT ✓ Max Exposure: 200 USDT (20% of capital) ← OK ✓ Stop Loss Distance: 0.5% Risk/Reward: 1:2.4 Daily P&L: -2.3% ← No warning ✓ Concurrent Positions: 2/4 ← OK ✓ ✅ Execution approved ``` ### Technical Analysis `Risk Amount ÷ (Entry Price - Stop Loss)` produces a quantity denominated in the base asset, such as BTC or ETH. In contrast, `Max Position` is denominated in USDT. The final `Min` operation therefore compares incompatible units unless the risk-based quantity is first converted to notional value. The approved example confirms that the stated five-percent capital limit is not consistently enforced. For capital of 1,000 USDT, the five-percent maximum is 50 USDT, but the example approves a position worth approximately 157 USDT. Although 157 USDT is below the separate 250 USDT exchange limit, it exceeds the documented capital-based limit by more than three times. A further correctness issue is that the stop-loss distance is not explicitly converted to an absolute non-negative value. For a short trade, direct subtraction may produce a negative denominator, which can yield a negative or otherwise invalid risk-based size. ### Attack Path 1. A trade signal supplies an entry price and stop-loss price. 2. The risk manager calculates a base-asset quantity using the price diff ...[truncated 969 chars]
• Remediation: ## Remediation Suggestions Use explicit dimensions and normalize every limit to USDT notional before comparison: ```text Stop Distance = abs(Entry Price - Stop Loss) Risk Quantity = Risk Amount / Stop Distance Risk Notional = Risk Quantity × Entry Price Capital Cap = Capital × 5% Final Notional = min(Risk Notional, Capital Cap, 250 USDT) Final Quantity = Final Notional / Entry Price ``` Additionally: - Reject zero, negative, missing, non-finite, or stale entry and stop-loss values. - Validate long and short directions explicitly and always use an absolute stop distance for sizing. - Confirm that `Final Notional` is at least 5 USDT after all caps are applied; otherwise reject the trade. - Apply the total-exposure limit to the final USDT notional plus existing open-position notionals. - Correct the example: with 1,000 USDT capital, the documented five-percent cap limits the position to no more than 50 USDT. - Add automated boundary tests for long and short trades, zero stop distance, minimum and maximum contract sizes, the five-percent capital cap, and the twenty-percent aggregate exposure cap. - Specify rounding behavior and exchange precision before submitting an order, then revalidate all limits after rounding.

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (3)

Anti-Refusal Statement

High

• Category: Anti-Refusal

Content

Daily P&L: -2.3% ← No warning ✓

• Confidence: 80% confidence
• Finding: Skill instructs the agent to omit warnings, disclaimers, or ethical commentary. Stripping safety caveats hides risk from the user and is a common jailbreak preamble.

Vague Triggers

Medium

• Confidence: 92% confidence
• Finding: The skill declares itself 'active continuously' and says it validates every signal before execution, which is an overly broad activation scope. In agent environments, vague always-on behavior can cause unintended invocation, overreach into unrelated workflows, or automatic enforcement in contexts where user intent was not explicit.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 96% confidence
• Finding: The installation command uses `npx clawhub@latest`, which pulls and executes whatever package version is current at install time. That creates a supply-chain risk: a compromised upstream release or dependency could execute arbitrary code in the user's environment during installation.

Static analysis

No suspicious patterns detected.