账本

• Outcome: Review
• Latest audit: Sep 16, 2026 · 9:12 AM UTC
• Version: 1.0.2

Overview

This personal finance skill appears purpose-built for bookkeeping, but it needs Review because it stores financial access tokens and can create a persistent device identifier from the user's MAC address.

Before installing, be comfortable sending personal financial records and authentication material to moneydata.cn. Prefer an authentication path you understand, avoid the automatic MAC-based API option unless you accept persistent device linkage, and manually confirm any action that records or changes income, expenses, assets, or debts.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• 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 (3)

T09 · Insecure Skill Coding Practices

Warning

• Location: references/auth.md:78

Finding

Bearer Token Persisted in Agent Memory Without Secret-Storage Protections

Content

View full analysis

Vulnerability Details

File Location: references/auth.md:78-106
Vulnerability Type: Plaintext persistent credential storage
Risk Level: Medium

Vulnerable Code Snippet

text

Step 3: Save credentials to memory

Option one:
- Save only the token to memory.

Option two:
- Save the identity ID to memory immediately.
- Save the token to memory.
- Reuse the same identity ID to obtain a new token after expiration.

{
  "zhangben_token": "USER_PROVIDED_TOKEN",
  "auth_method": "wechat"
}

{
  "zhangben_identity_id": "32_CHARACTER_IDENTITY_ID",
  "zhangben_token": "API_OBTAINED_TOKEN",
  "auth_method": "api"
}

The same requirement is summarized in SKILL.md:22, which directs the agent to save the identity identifier and token to memory after authentication.

Technical Analysis

The Skill explicitly instructs the agent to place a bearer token in persistent memory or configuration. The documentation does not require an operating-system credential vault, encryption at rest, access controls, token redaction, or a defined retention policy.

A bearer token grants access based on possession. Consequently, any user, process, extension, agent, or later session that can read the shared memory may be able to impersonate the account. The identity identifier is also persisted for API-based authentication, increasing the amount of reusable authentication material exposed through the same storage channel.

This is an insecure secret-management practice rather than agent memory poisoning: the stored values are credentials, not attacker-controlled behavioral rules.

Attack Path

1. A user authenticates through either the WeChat-token or API-token method.
2. The agent saves zhangben_token in persistent memory as instructed.
3. An attacker obtains read access to the agent's memory, configuration, backup, diagnostic output, or another session sharing that state.
4. The attacker extracts th ...[truncated 944 chars]

Remediation

View remediation

Remediation Suggestions

1. Never store raw bearer tokens in conversational or general-purpose agent memory.
2. Use an operating-system-backed credential vault or a dedicated MCP secret facility with per-Skill access controls.
3. Store only an opaque credential reference in agent memory.
4. Encrypt credentials at rest and restrict access to the minimum process identity.
5. Ensure tokens are short-lived, narrowly scoped, revocable, and rotated after suspected disclosure.
6. Redact tokens from prompts, tool output, logs, traces, exceptions, backups, and diagnostic reports.
7. Provide an explicit logout operation that revokes the server-side token and deletes all local credential material.
8. Document token expiration, scope, retention, and deletion behavior.
9. Avoid storing the reusable identity identifier beside the token; if it must be retained, protect it as authentication material.

T09 · Insecure Skill Coding Practices

Error

• Location: references/auth.md:64

Finding

Predictable Token Acquisition Scheme Uses a MAC-Derived Identifier and Public Constant

Content

View full analysis

Vulnerability Details

File Location: references/auth.md:64-74
Vulnerability Type: Weak and reproducible authentication construction
Risk Level: High

Vulnerable Code Snippet

text

1. Generate an identity ID:
   - Obtain the MAC address through ifconfig.
   - Apply MD5 to the MAC address to produce a 32-character identity ID.

2. Immediately save the identity ID to memory.

3. Obtain a token:
   - Construct code as:
     identity_id + 10_digit_timestamp + f5138595b7b93cd08b8c03bbaa825ddb
   - POST the following body to https://moneydata.cn/api/user/token:
     {"code": "CONSTRUCTED_CODE"}
   - Extract the token from the response.

4. Save the token to memory.

Technical Analysis

The documented token acquisition value is assembled from:

• An MD5 hash of a MAC address.
• A ten-digit timestamp.
• A constant embedded directly in the public Skill documentation.

None of these elements is a suitable independent authentication secret. MAC addresses have constrained and partially structured input space, MD5 is a fast unsalted hash, timestamps are predictable, and the trailing constant is disclosed to every reader of the package.

MD5 does not provide meaningful secrecy for a low-entropy or discoverable hardware identifier. If the backend treats the constructed code as sufficient proof of identity, knowledge or inference of the MAC-derived identity ID may allow an attacker to generate fresh token requests without possessing the previous bearer token.

The actual exploitability depends on server-side checks that are not present in the audited package. The documented client flow does not mention a server nonce, device-bound private key, user confirmation, rate limiting, or cryptographic challenge-response.

Attack Path

1. The attacker obtains the stored zhangben_identity_id, observes the device MAC address, or searches plausible MAC-address candidates.
2. If starting with a MA ...[truncated 1409 chars]

Remediation

View remediation

Remediation Suggestions

1. Replace the custom token construction with a standard authorization protocol such as OAuth 2.1 with PKCE or an equivalent user-mediated flow.
2. Generate account and device identifiers with a cryptographically secure random-number generator rather than deriving them from hardware attributes.
3. Use server-issued, high-entropy refresh credentials and store them in a protected credential vault.
4. Require explicit user authorization when linking a new client or device.
5. Use short-lived access tokens with narrowly scoped permissions.
6. Support server-side token rotation, revocation, replay prevention, and anomaly detection.
7. If request signing is required, use a protected private key and a server-provided nonce; do not use a public embedded constant as proof of authenticity.
8. Enforce timestamp validation, one-time challenges, rate limiting, and lockout controls on the token endpoint.
9. Invalidate identities and tokens created through the old construction after securely migrating users.

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: references/auth.md:54

Finding

Authentication Flow Collects a Stable Hardware Identifier Through Network-Interface Enumeration

Content

View full analysis

Vulnerability Details

File Location: references/auth.md:54-71
Vulnerability Type: Excessive device access and stable identifier collection
Risk Level: Medium

Vulnerable Code Snippet

text

Option two: Automatically obtain a token

1. Generate an identity ID:
   - Use ifconfig to obtain the MAC address.
   - Hash the MAC address with MD5 to generate a 32-character identity ID.

2. Immediately save the identity ID to memory.

3. Obtain a token:
   - Construct code from the identity ID, timestamp, and fixed constant.
   - Send the constructed value to https://moneydata.cn/api/user/token.

Technical Analysis

The Skill's core purpose is personal bookkeeping, but its API authentication option instructs the agent to execute a system network-interface inspection command and derive a stable identifier from the device's MAC address.

Accessing interface metadata expands the Skill's system-access scope beyond ordinary ledger operations. Hashing the MAC address with MD5 does not anonymize it reliably because MAC addresses are structured, often observable locally, and susceptible to candidate enumeration. The resulting digest remains a stable correlator and is explicitly retained for future token renewal.

The user is offered the API method as a choice, but the documentation does not separately explain the privacy implications of hardware enumeration, the exact identifier sent to the service, its retention period, or a deletion mechanism.

Attack Path

1. The user selects automatic API authentication.
2. The agent runs or otherwise uses ifconfig to enumerate local interface information.
3. The agent extracts a MAC address and computes its MD5 digest.
4. The agent saves the resulting stable identity value in persistent memory.
5. The identity value is incorporated into a request sent to the external token service.
6. The external service can associate subsequent ledger activity and token ...[truncated 950 chars]

Remediation

View remediation

Remediation Suggestions

1. Do not inspect network interfaces or collect MAC addresses for bookkeeping authentication.
2. Generate a random 256-bit client identifier using a cryptographically secure random-number generator.
3. Treat generated identifiers as sensitive and store them only in a protected credential facility.
4. Obtain explicit, informed consent before collecting any device identifier, separately from general authentication consent.
5. Explain what information is collected, why it is needed, where it is sent, how long it is retained, and how it can be deleted.
6. Minimize identifier retention and provide an account/device unlinking mechanism.
7. Bind authentication to server-issued credentials rather than stable hardware properties.
8. Restrict the Skill's command permissions so that system network-enumeration commands are unnecessary and unavailable during normal operation.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (8)

Vague Triggers

Medium

• Category: Not specified by scanner
• Confidence: 88% confidence

Finding

The trigger description is overly broad for a skill that performs real financial actions through a remote MCP service. Generic phrases like “账本” and broad bookkeeping verbs increase the chance of accidental invocation in ordinary conversation, which could lead the agent to collect or act on sensitive financial data without the user clearly intending to use this specific service.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 94% confidence

Finding

The skill handles highly sensitive personal financial information and sends it to an external endpoint at https://moneydata.cn/mcp, but the description does not prominently warn the user that their data will be transmitted off-platform. Without explicit disclosure, users may unknowingly expose income, expenses, assets, liabilities, and authentication tokens to a third-party service, creating privacy and consent risks.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 95% confidence

Finding

The instructions tell the agent to store authentication tokens in memory persistently, but do not require a clear user-facing warning that these are sensitive long-lived credentials. In an agent environment, silent persistence of tokens can lead to unintended retention, reuse across sessions, or exposure to other components with memory access.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 96% confidence

Finding

The automatic token flow collects a device-derived identifier, stores it immediately, and persists the resulting token without a strong warning about device fingerprinting, sensitivity, or long-term linkage. Because this skill handles personal finance data, the combination of financial access tokens and stable device identifiers raises the privacy and account-linkage risk beyond what is necessary for the stated function.

Content

No source excerpt is available for this finding.

Context-Inappropriate Capability

Medium

• Category: Not specified by scanner
• Confidence: 95% confidence

Finding

The skill instructs deriving a persistent identity from the host MAC address using ifconfig and MD5, which creates a device fingerprint unrelated to normal personal bookkeeping needs. This unnecessarily ties a user's financial access to host-level identifiers, increasing privacy risk and potentially exposing infrastructure metadata if the agent runs on shared or managed systems.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 93% confidence

Finding

The document exposes multiple state-changing financial operations such as income, expense, buy_asset, sell_asset, borrow, and repay without any explicit warning that these calls modify real ledger data and may affect assets, liabilities, and transaction history. In a personal finance skill, an agent or user could invoke these tools based on ambiguous prompts or misunderstood context, causing unauthorized or irreversible bookkeeping changes.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low

• Category: Not specified by scanner
• Confidence: 93% confidence

Finding

The document is entirely written in Chinese, including the title, column headings, and remediation guidance, with no indication that users may choose another language or that the file is intended only for a Chinese-language audience. Under the language/locale policy, fixed-language instructions can be a policy concern when no opt-in or justification is provided.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low

• Category: Not specified by scanner
• Confidence: 88% confidence

Finding

The entire reference is written in Chinese and uses Chinese-only labels and descriptions, but it does not indicate that the skill is region- or language-specific or provide an opt-in for this locale. Under the language/locale policy, forcing a single language without user choice or justification can be a natural-language policy violation.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.