Is mayswind/ezbookkeeping safe?

The skill exposes a tokens-revoke API command (Method: POST) that accepts a tokenId and revokes the corresponding session. By first calling tokens-list to enumerate all active session IDs and then calling tokens-revoke for each, an agent manipulated through prompt injection embedded in transaction data could lock the user out of their ezBookkeeping account entirely. Recovery would require direct server access or re-authentication through an out-of-band method.

When an agent calls transactions-list or transactions-list-all, the API response includes user-controlled string fields: comment (per transaction), category names, account names, and tag names. If an attacker has write access to the ezBookkeeping instance or if the user has unwittingly stored malicious content, these fields can contain prompt injection instructions that activate when the agent processes and displays the transaction data. The transactions-list-all endpoint returns the complete transaction history with no server-enforced pagination, maximizing exposure.

The load_env_file() function reads .env files line by line, strips leading and trailing quote characters, then uses eval to assign the value to the variable named by the key. Although the key is filtered through a case statement to only EBKTOOL_SERVER_BASEURL and EBKTOOL_TOKEN, the value is not shell-escape-sanitized before being interpolated into the eval string. A .env file containing a value with embedded double quotes, backticks, or $(command) sequences could break out of the quoting context and execute arbitrary shell commands with the agent's privileges.

load_env_from_paths() attempts to load credentials from .env files in the current working directory, the parent of the current working directory, and the user's home directory — in that order. The current working directory is determined at runtime from the agent's invocation context, which varies by agent implementation. This means the skill may silently read .env files from project directories, workspace roots, or other locations the user did not intend to expose to the skill. While only EBKTOOL_* keys are extracted, the access pattern is broader than the principle of least privilege requires.

The skill grants the agent write access to financial records via transactions-add, accounts-add, transaction-categories-add, and transaction-tags-add. An agent manipulated through prompt injection or confused by ambiguous user instructions could add false transactions, modify account balances via accounts-add with balanceTime, or create misleading categories that corrupt the user's financial history in ways that may not be immediately apparent.

The EBKTOOL_TOKEN is expanded into curl command-line arguments as the Authorization Bearer header value. During the brief execution window of each curl call, the token is present in /proc/PID/cmdline and visible to any process with read access to the proc filesystem on the host. On shared systems this constitutes a token disclosure risk.

String-typed API parameters are URL-encoded for GET requests and JSON-stringified for POST requests, but the intermediate shell variable expansions (e.g., inside jq --arg, url_encode via jq @uri) rely on jq's argument handling for safety. If jq is absent or a version with a parsing bug is present, crafted parameter values could affect command construction. The dependency check at startup (check_dependency) verifies jq is present but not its version.

The transactions-list-all endpoint retrieves all transactions within a specified time range with no count limit enforced by the skill. On accounts with years of transaction history, a single API call can return thousands of records including amounts, account identifiers, categories, tags, and free-text comments. While all data goes to the user-configured server, an agent that is manipulated into calling this endpoint and forwarding results could facilitate a comprehensive financial data dump.

Full static analysis of SKILL.md reveals no hidden instructions, no instruction-override phrases, no invisible unicode characters, no HTML comment tricks, no external URL fetch instructions, and no persona change directives. The instruction to not request credential values is correctly framed as a user-protection measure, not a control bypass.

The git clone performed a shallow sparse checkout from the official openclaw/skills repository at a pinned commit hash. The only external IP contacted was 140.82.121.3 (GitHub). The pre-existing connection to 185.125.188.59 (Canonical Ubuntu) was present before installation and is unrelated to the skill. No new listening ports were opened, no background services were installed, and no files were written outside the skill directory.

Filesystem monitoring recorded read access to .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, and gcloud credentials. Cross-referencing with the auditd process execution log confirms these accesses occurred at two discrete moments: before the git clone (audit events 262-267, part of the audit harness pre-install baseline) and after installation (events 1423-1428, post-install canary verification). The ebktools.sh script was never executed during the audit — no EXECVE event references it — so these accesses cannot be attributed to the skill. All canary files remain unmodified.