Ethereum L2 Analytics 以太坊L2分析

• Outcome: Review
• Latest audit: Sep 16, 2026 · 5:04 AM UTC
• Version: 1.0.0

Overview

The skill is mostly Ethereum L2 analysis content, but it bundles under-disclosed paid verification, wallet-address transmission, and an exposed payment API key.

Review this before installing: it appears to be a paid Chinese-language L2 analytics skill with static data, not a reliable live-monitoring system. Do not provide a wallet address unless you accept that it may be sent to SkillPay, and treat any investment or bridge recommendations as informational rather than current financial advice.

A.I.G

Vulnerability Patterns

• 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
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (3)

T09 · Insecure Skill Coding Practices

Warning

• Location: payment.py:15
• Finding: Hard-Coded Payment API Credential Distributed with the Skill<![CDATA[ ## Vulnerability Details **File Location**: `payment.py:15-16`, `payment.py:31-33`; `_meta.json:9-15` **Vulnerability Type**: Hard-coded secret **Risk Level**: Medium ### Vulnerable Code ```python # payment.py:15-16 SKILLPAY_API_URL = "https://api.skillpay.io/v1" SKILLPAY_API_KEY = "sk_f03aa8f8bbcf79f7aa11c112d904780f22e62add1464e3c41a79600a451eb1d2" ``` ```python # payment.py:31-33 headers = { "Authorization": f"Bearer {SKILLPAY_API_KEY}", "Content-Type": "application/json" } ``` ```json // _meta.json:9-15 "pricing": { "enabled": true, "amount": "0.01", "currency": "USDT", "chain": "bsc", "apiKey": "sk_f03aa8f8bbcf79f7aa11c112d904780f22e62add1464e3c41a79600a451eb1d2" } ``` ### Technical Analysis A bearer credential for the SkillPay API is embedded in two files distributed with the Skill. Secrets stored in source code or package metadata cannot be treated as confidential because any user, registry operator, build system, or process with access to the package can extract them. The code uses this value directly as an HTTP `Authorization` bearer token. An attacker does not need to execute the Skill or bypass local controls to recover it. The credential's exact server-side permissions cannot be established from the repository, so the audit cannot confirm access beyond whatever privileges SkillPay assigned to this key. ### Attack Path 1. Download or otherwise obtain a copy of the Skill package. 2. Read `payment.py` or `_meta.json`. 3. Extract the embedded `sk_...` bearer credential. 4. Construct requests to the SkillPay API using `Authorization: Bearer <extracted-key>`. 5. Exercise any API operations permitted by that credential, potentially including payment-verification requests, until the key is revoked or rejected. ### Impact Assessment The exposed credential may allow unauthorized use of the associated SkillPay API identity. Potential impact includes API quota consumption, payment-verification probing, operational disrupt ...[truncated 359 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Immediately revoke and rotate the exposed API credential. 2. Remove the credential from both `payment.py` and `_meta.json`. 3. Purge the exposed value from repository history, release archives, caches, and published Skill packages where feasible. 4. Keep payment credentials in a protected server-side secret manager or environment provided by a trusted deployment platform. 5. Prefer a server-side payment-verification proxy so end-user Skill packages never receive the provider credential. 6. Scope the replacement credential to the minimum required verification endpoint and deny administrative or payment-modification operations. 7. Add automated secret scanning to pre-commit and CI pipelines. 8. Review API logs for use of the exposed key and configure rate limits and anomaly alerts. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: payment.py:27
• Finding: Undisclosed Transmission of a User Wallet Address to an External Payment Service<![CDATA[ ## Vulnerability Details **File Location**: `payment.py:27-50` **Vulnerability Type**: Undisclosed external transmission of a persistent user identifier **Risk Level**: Medium ### Vulnerable Code ```python def verify_payment(user_address: str = None) -> dict: """ 验证用户支付状态 Args: user_address: 用户钱包地址 (可选) Returns: dict: 验证结果 """ try: headers = { "Authorization": f"Bearer {SKILLPAY_API_KEY}", "Content-Type": "application/json" } data = json.dumps({ "skill_slug": SKILL_SLUG, "user_address": user_address, "timestamp": datetime.utcnow().isoformat() }).encode('utf-8') req = urllib.request.Request( f"{SKILLPAY_API_URL}/verify", data=data, headers=headers, method='POST' ) with urllib.request.urlopen(req, timeout=10) as response: result = json.loads(response.read().decode('utf-8')) return result ``` ### Technical Analysis `verify_payment()` sends the supplied wallet address, the Skill identifier, and a timestamp to `https://api.skillpay.io/v1/verify`. Although a public wallet address is not a private key, it is a persistent pseudonymous identifier that can be correlated with public blockchain transactions and usage times. Remote payment verification is related to the package's enabled pricing configuration. However, the primary `SKILL.md` instructions describe L2 analytics and do not disclose that a wallet address will be transmitted to SkillPay, identify the destination, explain retention, or request informed consent. This network behavior therefore exceeds the behavior clearly disclosed by the Skill's main functional documentation. The request uses HTTPS, so plaintext transport was not observed. The finding concerns data minimization, transparency, and external disclosure rather than evid ...[truncated 1013 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Before collecting an address, clearly disclose: - The destination service and domain. - Every transmitted field. - The purpose of transmission. - Applicable retention, sharing, and deletion policies. 2. Obtain explicit user consent before sending the wallet address. 3. Determine whether verification can use a one-time payment receipt, signed nonce, or other less linkable identifier instead of a persistent wallet address. 4. Do not transmit `user_address` when it is `None` or unnecessary. 5. Validate wallet-address format and reject oversized or malformed input before transmission. 6. Restrict outbound requests to an allowlisted, configurable endpoint and verify the expected TLS configuration. 7. Document the network behavior and payment flow in `SKILL.md`, not only in implementation code or metadata. 8. Establish contractual and technical controls for provider retention, access logging, deletion, and incident response. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: payment.py:68
• Finding: Payment Verification Can Be Disabled Through an Environment Variable<![CDATA[ ## Vulnerability Details **File Location**: `payment.py:68-84` **Vulnerability Type**: Authentication and payment-control bypass **Risk Level**: Medium ### Vulnerable Code ```python def require_payment(user_address: str = None): """ 要求支付 - 在 Skill 入口调用 Args: user_address: 用户钱包地址 Returns: bool: 是否已支付 """ # 检查环境变量是否跳过验证 (测试模式) if os.environ.get('SKILLPAY_SKIP_VERIFICATION') == 'true': print("⚠️ [DEV MODE] Payment verification skipped") return True result = verify_payment(user_address) if result.get('success') and result.get('verified'): print(f"✅ Payment verified for {SKILL_SLUG}") return True ``` ### Technical Analysis The authorization gate trusts the process environment to decide whether payment verification is required. If `SKILLPAY_SKIP_VERIFICATION` is exactly `true`, the function returns success without contacting the payment service or validating a receipt. Environment variables are commonly controlled by the invoking user, process supervisor, container configuration, CI job, or parent process. No signed development configuration, build-time restriction, privileged test harness, or production safeguard protects this bypass. This is a business-logic authorization weakness rather than operating-system privilege escalation. It permits bypass of the Skill's payment condition but does not grant additional host permissions. ### Attack Path 1. Obtain the Skill package or invoke it in an environment where process variables can be set. 2. Set `SKILLPAY_SKIP_VERIFICATION=true`. 3. Invoke an entry point or integration that relies on `require_payment()`. 4. The function returns `True` before calling `verify_payment()`. 5. Any paid functionality guarded only by this return value becomes available without payment verification. ### Impact Assessment An attacker who can influence the Skill process environment can bypass the intended payment ch ...[truncated 496 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove the environment-variable bypass from production code. 2. Implement test behavior by injecting a mock payment verifier within the test suite rather than adding a production authorization shortcut. 3. If separate development behavior is unavoidable, use a distinct development build that cannot be published or deployed as the production Skill. 4. Fail closed when verification is unavailable, malformed, or inconclusive. 5. Validate a server-signed, short-lived verification result rather than trusting local environment state. 6. Centralize authorization enforcement so every paid operation checks the same verified server-side entitlement. 7. Add tests proving that arbitrary environment variables cannot produce successful payment authorization in release builds. 8. Log verification decisions without recording unnecessary wallet identifiers or secrets. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (17)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: 声明描述的核心功能是 Ethereum L2 生态分析与情报生成，但提供的代码片段实际只处理访问控制/付费验证，主用途明显不同。代码访问的资源是 SkillPay 支付服务，而不是任何 Optimism、Arbitrum、Base、zkSync、Starknet、TVL、桥接或链上分析数据源。虽然付费校验可被视为某个技能的配套基础设施，但在当前片段中它是唯一可见行为，且声明中完全未提及收费验证或支付网关，因此构成明显描述-行为不匹配。另有安全问题：代码硬编码了 API key，但这不改变其与声明用途不一致的结论。

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 91% confidence
• Finding: The description presents a comprehensive L2 ecosystem intelligence and analysis skill, including deep protocol analysis, live TVL monitoring, cross-chain bridge analysis, fund-flow tracking, and investment opportunity discovery. The supplied code only produces a simple report composed of static mock data for L2 TVL rankings, bridge TVL, and broad category comparisons. Although the topic domain matches Ethereum L2, the implemented behavior is materially narrower and lacks several core advertised capabilities. This is therefore a description-to-behavior mismatch.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 91% confidence
• Finding: The description presents a broad, comprehensive L2 ecosystem intelligence and monitoring tool with deep analysis across major Ethereum L2s, including TVL monitoring, bridge analysis, capital flow tracking, technical comparisons, and investment opportunity discovery. The supplied code does something narrower: it evaluates one L2 project at a time using hardcoded scoring thresholds and produces a report with strengths, weaknesses, and an investment recommendation. While this partially overlaps with 'assessing Rollup projects' and 'investment opportunity identification,' the primary behavior is a static rubric-based scorer, not a comprehensive ecosystem analysis platform. There is no evidence of network access, protocol-specific data ingestion, monitoring, bridge analytics, or comparative multi-project analysis. Therefore the declared description materially overstates the implemented capabilities.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 70% confidence
• Finding: Without declared permissions the skill's intent is opaque and cannot be validated.

Natural-Language Policy Violations

Medium

• Confidence: 95% confidence
• Finding: The manifest description and primary documentation are written in Chinese, and the skill presents itself as the default interaction mode without any indication that users may choose another language. Under the stated policy, forcing a specific language without user opt-in is a natural-language policy violation unless the locale restriction is explicit and justified.

Natural-Language Policy Violations

Medium

• Confidence: 96% confidence
• Finding: The description is written entirely in Chinese, indicating the skill is presented as Chinese-language only. Under the policy, forcing a specific language without offering user choice or documenting a justified locale restriction is a natural-language policy violation.

Natural-Language Policy Violations

Medium

• Confidence: 94% confidence
• Finding: The module description and printed payment guidance are written in Chinese, and the code does not offer any locale selection or user opt-in for that language. This can violate language or locale policy when a skill forces a specific language for user-facing interactions.

Description-Behavior Mismatch

Medium

• Confidence: 93% confidence
• Finding: The file introduces payment-gating and monetization logic that is not aligned with the stated purpose of an Ethereum L2 analytics skill. Hidden or undeclared monetization changes the trust model, can surprise users, and may be used to block access or steer them to external payment infrastructure without prior disclosure.

External Transmission

Medium

• Category: Data Exfiltration

Content

from datetime import datetime

# SkillPay API 配置
SKILLPAY_API_URL = "https://api.skillpay.io/v1"
SKILLPAY_API_KEY = "sk_f03aa8f8bbcf79f7aa11c112d904780f22e62add1464e3c41a79600a451eb1d2"
SKILL_SLUG = "shenmeng-ethereum-l2-analytics"
PRICE = "0.01"  # USDT

• Confidence: 99% confidence
• Finding: The module hardcodes a live SkillPay API endpoint together with a bearer API key, enabling external transmission and exposing a reusable secret in source code. Hardcoded credentials are highly dangerous because anyone with file access can extract the key, impersonate the skill, query payment status, or abuse the remote billing API.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The code sends user payment-verification data, including wallet address and timestamp, to a third-party API without any just-in-time notice or consent flow. In the context of a blockchain analytics skill, wallet addresses are sensitive because they enable transaction-history correlation and profiling, so undisclosed transmission increases privacy and compliance risk.

Context-Inappropriate Capability

Medium

• Confidence: 97% confidence
• Finding: The environment variable SKILLPAY_SKIP_VERIFICATION allows payment enforcement to be bypassed entirely, creating a built-in authentication and authorization backdoor. Even if intended for testing, such a switch is dangerous when present in production code because anyone controlling the runtime environment can disable verification and gain unpaid access.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: This guide gives concrete recommendations for moving funds across bridges, choosing providers, and handling urgent transfers, but it does not prominently warn users about irreversible loss from sending to wrong addresses, phishing sites, fake bridge frontends, or malicious token approvals. In a crypto-asset context, those omissions materially increase user-harm risk because the document may be used as actionable operational guidance for real fund transfers.

Natural-Language Policy Violations

Medium

• Confidence: 92% confidence
• Finding: This code file contains natural-language descriptions and user-facing output in Chinese, and the script does not provide any opt-in, fallback, or documented justification for enforcing that locale. The policy allows locale constraints only when the user is given a choice or the restriction is clearly documented as justified.

Description-Behavior Mismatch

Medium

• Confidence: 95% confidence
• Finding: The manifest describes an Ethereum L2 analytics and monitoring tool, which implies read-oriented data collection and reporting. In addition to generating analytics output, the script persists a JSON report under /tmp, which is a side effect not stated in the manifest description.

Natural-Language Policy Violations

Medium

• Confidence: 94% confidence
• Finding: This Python file contains natural-language descriptions and report strings entirely in Chinese, indicating the skill is designed to operate in a fixed language. The file does not provide any user opt-in, locale selection, or documented justification for restricting output to Chinese, which can violate language/locale policy requirements.

Natural-Language Policy Violations

Low

• Confidence: 95% confidence
• Finding: A natural-language policy issue exists when a skill or reference material forces a specific language without user opt-in. This file presents all guidance solely in Chinese and does not indicate that the locale is optional or intentionally restricted to a Chinese-language audience for a documented reason.

Natural-Language Policy Violations

Low

• Confidence: 94% confidence
• Finding: This markdown file is entirely presented in Chinese, starting with the title, and does not indicate that language selection is optional or user-configurable. Under the policy, forcing a specific language without user opt-in is a natural-language locale violation.

Static analysis

No suspicious patterns detected.