Nano invoice

• Outcome: Review
• Latest audit: Oct 3, 2026 · 10:07 AM UTC
• Version: 1.0.0

Overview

The skill mostly matches its Nano invoice purpose, but a wrong payment can permanently close a local invoice despite the instructions saying it will not.

Review this before installing if you depend on exact payment settlement. The skill does not appear to steal credentials, send Nano, or install persistence, but a buyer who knows the tagged amount could send a wrong amount and cause that invoice to close as underpaid or overpaid, requiring manual recovery or a new invoice.

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

T09 · Insecure Skill Coding Practices

Warning

• Location: nano_invoice/core.py:36

Finding

Attacker-Controlled Mismatched Payment Permanently Closes an Invoice

Content

View full analysis

Vulnerability Details

File Location: nano_invoice/core.py, lines 36 and 240–241 and 478–481
Vulnerability Type: Untrusted ledger input causes an unauthorized invoice state transition
Risk Level: Medium

Complete Code Snippet

python

SETTLING_KINDS = ("payment", "underpaid", "overpaid")
KIND_TO_STATE = {"payment": "paid", "underpaid": "underpaid", "overpaid": "overpaid"}

python

if kind in SETTLING_KINDS:
    _transition(c, invoice_id, KIND_TO_STATE[kind], now, observed)

python

if current.state == "open":
    kind = ("payment" if ob["amount_raw"] == inv.pay_raw
            else "underpaid" if ob["amount_raw"] < inv.pay_raw else "overpaid")
    try:
        observations.append(_record(store, ob, kind, inv.id, None, now, view))
        continue

Technical Analysis

The Skill assigns each invoice an exact payment amount containing a unique low-order tag. Ledger payments ending in that tag are associated with the invoice.

A remote payer controls the amount of a payment sent to the merchant. When such a payment has the invoice’s tag but differs from the required pay_raw, the code classifies it as underpaid or overpaid. Both classifications are included in SETTLING_KINDS, so Store.record() invokes _transition() and changes the invoice from open to a terminal underpaid or overpaid state.

The database trigger and transition rules prevent terminal invoices from returning to open. Consequently, a later payment of the correct amount is treated as a duplicate instead of settling the invoice.

This also contradicts the documented behavior in SKILL.md lines 50–51, which states that a wrong payment amount does not close an invoice.

Attack Path

1. A merchant creates an invoice and gives its exact tagged payment amount to a buyer.
2. The buyer learns the invoice tag from the disclosed amount.
3. Before paying correctly, the buyer sends a confirmed payment to the merchant with an amount that ends in the ...[truncated 1116 chars]

Remediation

View remediation

Remediation Suggestions

1. Remove underpaid and overpaid from SETTLING_KINDS; only an exact payment should transition an invoice to paid.
2. Record mismatched payments as non-settling observations or refund candidates while leaving the invoice in the open state.
3. Separate payment-record classification from invoice lifecycle transitions so recording an anomalous transaction cannot implicitly close an invoice.
4. Preserve the one-block/one-record protections, but permit a later exact payment to settle the still-open invoice.
5. Add regression tests covering:
   • Underpayment followed by exact payment.
   • Overpayment followed by exact payment.
   • Multiple mismatched payments before settlement.
   • Mismatched payments after expiration.
   • Concurrent mismatched and exact payments.
6. Ensure implementation and documentation consistently define whether and when underpayments or overpayments may close an invoice.

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

Undeclared Tool Scope

Medium

• Category: MCP Least Privilege
• Confidence: 91% confidence

Finding

The skill declares network and environment variable usage but does not explicitly scope or constrain those capabilities with a permissions/allowed-tools declaration. This creates a trust gap: an agent or operator cannot easily tell, from the manifest alone, what external access the skill is expected to use, which increases the risk of unintended network access, data exfiltration through environment-derived configuration, or overly broad execution in permissive runtimes.

Content

No source excerpt is available for this finding.