Spend Ledger
SuspiciousAudited by ClawScan on May 10, 2026.
Overview
Spend Ledger mostly matches its payment-tracking purpose, but one query script can execute injected code and the privacy wording understates that payment tool arguments may be read and stored.
Review carefully before installing. Do not let the agent pass untrusted service/date/skill strings to query-log.sh until the code-injection issue is fixed. Treat the ledger data directory as sensitive, avoid putting secrets in payment tool arguments, and disable community pattern syncing if you do not want remote pattern updates influencing payment detection.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If an agent passes an attacker-controlled filter value to query-log.sh, arbitrary Node.js code could run on the user's machine with the skill's local privileges.
User-controlled CLI filter values are interpolated directly into a Node.js -e JavaScript program. A crafted service, date, skill, or summary value containing quotes and JavaScript can break out of the string literal and execute code.
--service) SERVICE="$2"; shift 2 ;; ... if ('${SERVICE}') filters.service = '${SERVICE}';Pass filters through process.argv, stdin JSON, or environment variables and parse them as data; validate date and enum fields, and never template untrusted strings into executable code.
A user may install the skill believing it only sees outputs, while it can inspect payment inputs and may persist fragments of sensitive arguments locally.
This privacy claim is broader than the provided implementation: plugin.js reads tool params before execution, and detectors.js stores truncated argument summaries. Users could underestimate what payment-call data is visible to the skill.
No wallet keys or credentials are accessed — the skill observes tool call results only
Revise the documentation to clearly state that tool names, parameters, and results are inspected; add explicit redaction for credential-like fields before storing argument summaries.
The local ledger can contain financial history, service details, transaction identifiers, user-request context, and portions of payment tool arguments.
Detected payment records persist a truncated copy of payment tool arguments. This is local and aligned with transaction review, but payment arguments can include sensitive context or token-like fragments.
tool_args_summary: truncate(argsStr, 200)
Treat the data directory as sensitive, avoid placing secrets in payment arguments, and add field-level redaction for tokens, API keys, card/payment-method fields, and wallet secrets.
A bad or compromised pattern feed could cause false payment detections or affect duplicate-payment blocking behavior.
The skill automatically fetches and caches remote community patterns that influence what tool calls are treated as payments. This is disclosed and configurable, but it makes remote pattern provenance important.
const PATTERNS_URL = process.env.SPEND_LEDGER_PATTERNS_URL || `${API_BASE}/patterns.json`; ... writeFileSync(CACHE_PATH, JSON.stringify(data), { mode: 0o600 });Disable community syncing for sensitive environments, and prefer signed/versioned pattern lists with clear review and rollback controls.
Legitimate repeated payments with identical inputs in the same session may be blocked, and false positives in detection could interrupt expected work.
The plugin can block tool calls before execution when it believes a duplicate payment is being attempted. This is central to the stated purpose and disclosed, but it is a high-impact control over payment-capable tools.
if (duplicate) { return { block: true, blockReason: `Duplicate payment blocked — identical payment to ...` }; }Provide a clear user-visible override or confirmation path for legitimate repeats, and ensure duplicate checks include enough scope, such as tool name, recipient, amount, and session.