Bank Statement Converter

• Outcome: Review
• Latest audit: Sep 16, 2026 · 8:10 AM UTC
• Version: 1.5.5

Overview

The skill has a coherent bank-statement conversion purpose, but its code has material safety issues when handling sensitive financial spreadsheets.

Review this before installing if you will process statements from untrusted sources or on shared machines. Use a narrow workspace folder, install dependencies in an isolated environment, avoid privileged execution, and treat generated spreadsheets as potentially unsafe until formula sanitization and safer temporary-file handling are added.

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 (3)

T09 · Insecure Skill Coding Practices

Error

• Location: converter.py:911
• Finding: Spreadsheet Formula Injection in Generated Excel Workbooks<![CDATA[ ## Vulnerability Details **File Location**: `converter.py`, lines 911-930 **Vulnerability Type**: Untrusted spreadsheet formula injection **Risk Level**: High ### Vulnerable Code ```python for r, row_data in enumerate(rows, 2): for col, field in enumerate(TEMPLATE_COLUMNS, 1): cell = ws.cell(row=r, column=col, value=_template_cell_value(row_data, field)) if field == "日期": cell.number_format = "@" ``` The same unsafe write occurs in the summary workbook: ```python for r, row_data in enumerate(all_rows, 2): for col, field in enumerate(headers, 1): cell = ws.cell(row=r, column=col, value=_template_cell_value(row_data, field)) if field == "日期": cell.number_format = "@" ``` ### Technical Analysis Values originating from untrusted bank statement files are written directly into Excel cells without neutralizing spreadsheet formula prefixes. Text fields such as counterparty name, bank name, account number, summary, and remarks can therefore contain values beginning with `=`, `+`, `-`, or `@`. Spreadsheet software may interpret these values as formulas rather than literal text. Depending on the spreadsheet application and its security settings, a malicious formula can: - Display deceptive or manipulated content. - Reference other cells or workbook data. - initiate external-link requests that disclose information. - Abuse legacy formula capabilities or external data handlers. - Cause disruptive calculations or resource consumption. Setting the text number format only for date cells does not protect the other attacker-controlled fields. The issue affects both each source-specific workbook and the consolidated `汇总.xlsx` workbook. ### Attack Path 1. An attacker creates or modifies an otherwise valid supported bank statement. 2. The attacker inserts a formula-prefixed value into a mapped textual field, such as a remark or counterparty name. 3. A user runs the converter on the crafted statement ...[truncated 973 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions Introduce a single output-sanitization function for all untrusted textual fields before assigning values to cells. ```python DANGEROUS_FORMULA_PREFIXES = ("=", "+", "-", "@") def safe_excel_text(value): if value is None: return "" text = str(value) if text.startswith(DANGEROUS_FORMULA_PREFIXES): return "'" + text return text ``` Apply this protection to fields intended to be text, including summary, remarks, counterparty information, account identifiers, source company names, and any other source-derived labels. Keep verified numeric amount fields numeric where possible instead of converting every field indiscriminately. Additional hardening measures: 1. Use explicit field schemas that distinguish dates, numeric amounts, and literal text. 2. Set textual cells to the string data type where appropriate. 3. Sanitize values after trimming leading whitespace, or reject suspicious leading control characters that could obscure a formula prefix. 4. Add tests for payloads beginning with `=`, `+`, `-`, `@`, tabs, carriage returns, and leading whitespace. 5. Verify generated files in all supported spreadsheet applications because formula handling differs between products. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: converter.py:447
• Finding: Predictable Shared Temporary File Enables Symlink and Race Attacks<![CDATA[ ## Vulnerability Details **File Location**: `converter.py`, lines 447-450 **Vulnerability Type**: Insecure temporary-file creation **Risk Level**: Medium ### Vulnerable Code ```python tmp = os.path.join(tempfile.gettempdir(), "_claw_convert.xlsx") shutil.copy2(filepath, tmp) result = load_xlsx(tmp) os.unlink(tmp) ``` ### Technical Analysis When a file has an `.xls` extension but ZIP/XLSX content, the converter copies it to the fixed path `_claw_convert.xlsx` in the system temporary directory. The name is predictable and shared by every converter process. The code does not create the file atomically, verify ownership, reject symbolic links, or isolate concurrent runs. On a multi-user system, an attacker with access to the shared temporary directory may pre-create the path as a symbolic link or race the converter while it is copying, reading, or deleting the file. There is also no `try/finally` around deletion. If parsing raises an unexpected exception, sensitive financial data may remain at the predictable temporary path. ### Attack Path A symlink-based exploitation path is: 1. The attacker can create files in the shared system temporary directory. 2. The attacker creates `_claw_convert.xlsx` as a symbolic link to a file writable by the converter's user. 3. A victim processes a disguised XLSX file with an `.xls` extension. 4. `shutil.copy2()` follows the predictable destination and overwrites the linked target with the input statement. 5. The converter subsequently reads from and attempts to unlink the predictable path. A concurrency-based exploitation path is: 1. Two conversion processes handle disguised XLSX files at approximately the same time. 2. Both use the same `_claw_convert.xlsx` path. 3. One process overwrites or deletes the temporary file while the other is reading it. 4. One user may receive corrupted output, another user's statement data, or a conversion failure. ### Impact Assessment The vulnerability requires local access to ...[truncated 665 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions Create a unique temporary file atomically and guarantee cleanup: ```python tmp_path = None try: with tempfile.NamedTemporaryFile(suffix=".xlsx", delete=False) as tmp_file: tmp_path = tmp_file.name with open(filepath, "rb") as source: shutil.copyfileobj(source, tmp_file) return load_xlsx(tmp_path) finally: if tmp_path: try: os.unlink(tmp_path) except FileNotFoundError: pass ``` Alternatively, use `tempfile.TemporaryDirectory()` and place the copied workbook inside that private directory. Additional hardening measures: 1. Do not construct temporary names manually. 2. Ensure temporary files are created with restrictive permissions. 3. Avoid copying entirely if the workbook library can consume a binary stream or `BytesIO` object. 4. Place cleanup in a `finally` block. 5. Add concurrency tests that run multiple conversions simultaneously. 6. Avoid running the converter with elevated privileges. ]]>

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:47
• Finding: Unpinned Runtime Dependency Installation Creates Supply-Chain Exposure<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 47-53 **Vulnerability Type**: Unconstrained third-party dependency installation **Risk Level**: Medium ### Vulnerable Code ```bash pip install openpyxl xlrd ``` The documented verification command then imports the newly resolved packages: ```bash python3 -c "import openpyxl, xlrd; print('OK')" ``` ### Technical Analysis The installation instructions resolve mutable versions of `openpyxl`, `xlrd`, and their transitive dependencies from whatever package index is configured in the user's environment. No reviewed versions, lock file, package hashes, or trusted index are specified. This makes installation non-reproducible and exposes users to risks from: - A compromised or maliciously configured package index. - Dependency confusion involving an internal package source. - A compromised future package or transitive dependency release. - Unexpected incompatible versions. - Package installation hooks or imported package code executing with the installing user's privileges. The package names shown are not apparent typosquatting names, and the audited project does not itself retrieve remote executable payloads. The weakness is the absence of dependency integrity controls around the recommended installation process. ### Attack Path 1. A user follows the documented initialization command. 2. `pip` contacts the package indexes configured in that environment. 3. Dependency resolution selects the latest matching mutable releases because no versions are pinned. 4. A compromised index, package release, or transitive dependency supplies malicious code. 5. Installation-time behavior or the subsequent import executes that code with the user's privileges. 6. The compromised dependency can access files and resources available to the user, including bank statements processed by this skill. ### Impact Assessment A compromised dependency executes with the privileges of the user performing installation o ...[truncated 582 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions Replace unconstrained installation instructions with a reviewed, version-pinned dependency manifest. For example: ```text openpyxl==<reviewed-version> --hash=sha256:<reviewed-hash> xlrd==<reviewed-version> --hash=sha256:<reviewed-hash> ``` Install it using hash enforcement: ```bash python3 -m venv .venv . .venv/bin/activate python3 -m pip install --require-hashes -r requirements.txt ``` Additional hardening measures: 1. Pin all direct and transitive dependencies. 2. Generate and review hashes from a trusted package source. 3. Specify an approved package index in controlled environments. 4. Install dependencies in an isolated virtual environment rather than globally. 5. Run dependency vulnerability and provenance checks during releases. 6. Periodically update pinned versions through a documented review process. 7. Record supported Python and dependency versions to ensure reproducible deployments. ]]>

SkillSpector

Vulnerability Patterns

• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (4)

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 95% confidence
• Finding: The skill instructs the agent to read user-supplied folders recursively and generate converted Excel and ZIP outputs, but it does not declare any explicit tool scope or path restrictions. In an agent environment, missing permissions metadata can lead to broader-than-expected file read/write access, increasing the risk of unintended access to sensitive financial files or writing outputs outside approved workspace locations.

Natural-Language Policy Violations

Medium

• Confidence: 95% confidence
• Finding: The module title and description are written entirely in Chinese and present the skill as Chinese-language only, with no indication that users can choose another language or locale. Under the policy, forcing a specific language without user opt-in is a natural-language policy violation.

Natural-Language Policy Violations

Low

• Confidence: 95% confidence
• Finding: The manifest description is written entirely in Chinese and frames invocation/use conditions only in Chinese, with no indication that another language is supported or that the user can opt into the locale. Under the policy, forcing a specific language without user choice is a natural-language policy concern.

Natural-Language Policy Violations

Low

• Confidence: 91% confidence
• Finding: The natural-language comments and field labels are entirely Chinese, and the mapping logic is built around Chinese column names only. For a general-purpose skill, this effectively forces a specific language/locale without any visible opt-in or justification in the file.

Static analysis

No suspicious patterns detected.