Lightning Agentic Commerce

• Outcome: Review
• Latest audit: Sep 10, 2026 · 5:08 PM UTC
• Version: 1.0.0

Overview

This skill is coherent for Lightning payments, but it guides agents through real fund handling while documenting plaintext wallet secrets and insecure paywall setup.

Review carefully before installing or using with value at risk. Treat this as suitable only for isolated testnet or intentionally small funded wallets unless you replace plaintext seed/passphrase storage with stronger secret handling, avoid --insecure for exposed endpoints, and require explicit user approval before any payment-capable command runs.

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

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:197
• Finding: Wallet Passphrase and Seed Mnemonic Stored in Plaintext Files<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:197-198` **Vulnerability Type**: Plaintext storage of sensitive wallet credentials **Risk Level**: High ### Vulnerable Code ```markdown | **Wallet passphrase** | Stored at `~/.lnget/lnd/wallet-password.txt` (0600) | | **Seed mnemonic** | Stored at `~/.lnget/lnd/seed.txt` (0600) | ``` ### Technical Analysis The documented workflow stores both the wallet passphrase and seed mnemonic in plaintext files. File permissions of `0600` prevent access by other ordinary local accounts, but they do not encrypt the secrets or protect them from processes running as the wallet user, malware with user-level access, privileged users, insecure backups, filesystem snapshots, or accidental disclosure. A seed mnemonic is sufficient to reconstruct the associated wallet. Consequently, its confidentiality requirements are substantially higher than those of ordinary configuration data. Storing the passphrase beside the seed also weakens defense in depth if both files are captured together. The behavior exceeds the minimum privilege and exposure necessary for normal wallet operation because long-term plaintext retention of the recovery seed is not required after secure wallet initialization and backup. ### Attack Path 1. The user follows the Skill workflow and creates or initializes a funded Lightning wallet. 2. The supporting tooling writes the wallet passphrase and seed mnemonic to the documented paths. 3. An attacker compromises a process running under the same user, obtains an insecure backup or snapshot, or otherwise gains read access to the user's files. 4. The attacker reads `~/.lnget/lnd/seed.txt` and, if needed, `~/.lnget/lnd/wallet-password.txt`. 5. The attacker restores or unlocks the wallet using the captured credentials. 6. The attacker transfers available funds or otherwise compromises wallet assets. ### Impact Assessment Successful exploitation may disclose the wallet's root recovery secret and per ...[truncated 376 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Do not retain the seed mnemonic in a plaintext file after initialization. - Require the mnemonic to be recorded through a secure offline backup process, such as an encrypted removable backup or hardware-backed recovery mechanism. - Store operational credentials in an operating-system keychain, hardware security module, encrypted secret manager, or remote signer. - If a temporary seed file is unavoidable, create it with restrictive permissions, exclude it from backups and synchronization, securely delete it immediately after initialization, and clearly warn the user about residual filesystem recovery risks. - Keep wallet-unlock credentials separate from recovery material so that compromise of one storage location does not expose both. - Prefer the documented watch-only or remote-signer model for wallets holding significant funds. - Add explicit migration guidance requiring users who suspect disclosure to create a new seed and transfer all funds to addresses controlled by the new wallet. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:104
• Finding: Insecure Aperture Configuration Recommended for Externally Accessible Paid Endpoints<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:104` and `SKILL.md:164` **Vulnerability Type**: Unsafe service configuration **Risk Level**: Medium ### Vulnerable Code First occurrence: ```bash # Configure aperture to protect it skills/aperture/scripts/setup.sh --insecure --port 8081 ``` Second occurrence: ```bash # Configure and start paywall skills/aperture/scripts/setup.sh --port 8081 --insecure ``` The workflow then describes external access: ```bash # Other agents can now pay to access your endpoints # lnget --max-cost 100 https://your-host:8081/api/data ``` ### Technical Analysis The Skill repeatedly invokes the Aperture setup script with the explicit `--insecure` option while describing a service intended to receive requests from other agents. The exact implementation and semantics of this option cannot be verified because the referenced `skills/aperture/scripts/setup.sh` file is absent from the audited artifact. Nevertheless, the documented option expressly selects an insecure operating mode. If `--insecure` disables transport security, certificate verification, authentication protections, or another security boundary, using it for a network-accessible payment endpoint can expose requests, responses, payment metadata, or authentication tokens to interception or manipulation. Presenting this mode as part of the ordinary setup workflow increases the chance that a test-only configuration will be deployed on an untrusted network. The configuration may be acceptable for an isolated local development environment, but it is not the minimum safe configuration for the stated externally accessible seller workflow. ### Attack Path 1. A user follows the documented seller setup and enables Aperture with `--insecure`. 2. The service is bound or forwarded to an interface accessible by other agents or untrusted network participants. 3. A network-positioned attacker connects to the service or intercepts traffic between a buyer and the endpo ...[truncated 968 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Remove `--insecure` from the default setup workflow. - Configure authenticated TLS with valid certificate verification for any endpoint reachable across a network. - Bind the service to localhost by default and require an explicit, documented opt-in before exposing it externally. - Place the service behind a securely configured reverse proxy when public access is required. - Restrict inbound access with firewall rules and allowlists where practical. - Clearly label insecure mode as suitable only for isolated local testing, and include a warning that it must not be used with real funds, production tokens, or sensitive content. - Document which security controls `--insecure` disables so users can make an informed deployment decision. - Add a production validation step that refuses startup when insecure mode is combined with a non-loopback listener unless the user provides an explicit override. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• YARA Signatures: Malware Match, Webshell Match, Cryptominer Match
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (8)

YARA rule 'ransomware_behavior': Ransomware-like patterns (mass encryption, ransom notes) [malware]

Critical

• Category: YARA Match

Content

tall.sh
```

### Step 2: Set Up the Lightning Node

```bash
# Start litd container (testnet by default)
skills/lnd/scripts/start-lnd.sh

# Create an encrypted wallet
skills/lnd/scripts/create-wallet.sh --mode standalone

# Verify node is running
skills/lnd/scripts/lncli.sh getinfo
```

### Step 3: Fund the Wallet

```bash
# Generate a Bitcoin address
skills/lnd/scripts/lncli.sh newaddress p2tr

# Send BTC to this address from an exchange or another wallet

# Verify balance
skills/lnd/scripts/lncli.sh walletbalance
```

### Step 4: Open a Channel

```bash
# Connect to a well-connected node (e.g., ACINQ, Bitfinex)
skills/lnd/scripts/lncli.sh connect <pubkey>@<host>:9735

# Open a channel
skills/lnd/scripts/lncli.sh openchannel --node_key=<pubkey> --local_amt=1000000

# Wait for channel to confirm (6 blocks)
skills/lnd/scripts/lncli.sh listchannels
```

### Step 5: Configure lnget

```bash
# Initialize lnget config (auto-detects local lnd)
lnget config init

# Verify connection
lnget ln s

• Confidence: 80% confidence
• Finding: YARA rule matched a known malware signature (reverse shell, backdoor, ransomware, C2 framework, or info stealer).

Credential Access

High

• Category: Privilege Escalation

Content

| Component | Security Model |
|-----------|---------------|
| **Wallet passphrase** | Stored at `~/.lnget/lnd/wallet-password.txt` (0600) |
| **Seed mnemonic** | Stored at `~/.lnget/lnd/seed.txt` (0600) |
| **L402 tokens** | Stored at `~/.lnget/tokens/<domain>/` per domain |
| **lnd macaroons** | Standard lnd paths at `~/.lnd/data/chain/...` |

• Confidence: 92% confidence
• Finding: The documentation states that the wallet passphrase and seed mnemonic are stored in plaintext files under the user's home directory, even if mode 0600 is applied. On a compromised host, through backups, logs, accidental file disclosure, or local privilege abuse, these files can enable complete wallet compromise and theft of funds.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The skill includes commands that can trigger real Lightning payments (`lnget --max-cost ...`) but does not place an explicit warning adjacent to those commands that they may spend real funds if pointed at a live wallet or mainnet-connected node. In an agentic context, examples are often copied verbatim, so missing spending warnings increases the chance of unintended payment execution.

External Transmission

Medium

• Category: Data Exfiltration

Content

```bash
# Fetch an L402-protected resource
lnget --max-cost 1000 https://api.example.com/paid-data

# Preview without paying
lnget --no-pay https://api.example.com/paid-data

• Confidence: 50% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium

• Category: Data Exfiltration

Content

```bash
# Fetch an L402-protected resource
lnget --max-cost 1000 https://api.example.com/paid-data

# Preview without paying
lnget --no-pay https://api.example.com/paid-data

• Confidence: 50% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium

• Category: Data Exfiltration

Content

```bash
# Fetch an L402-protected resource
lnget --max-cost 1000 https://api.example.com/paid-data

# Preview without paying
lnget --no-pay https://api.example.com/paid-data

• Confidence: 50% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium

• Category: Data Exfiltration

Content

```bash
# Fetch an L402-protected resource
lnget --max-cost 1000 https://api.example.com/paid-data

# Preview without paying
lnget --no-pay https://api.example.com/paid-data

• Confidence: 50% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Missing User Warnings

Medium

• Confidence: 96% confidence
• Finding: The seller setup instructs users to run `skills/aperture/scripts/setup.sh --port 8081 --insecure` without a nearby explanation of what protections are disabled or the exposure created. Using an insecure reverse-proxy/paywall configuration can allow interception, credential/token leakage, or unsafe public exposure of the paid endpoint.

Static analysis

No suspicious patterns detected.