Lnd

• Outcome: Review
• Latest audit: Sep 10, 2026 · 5:12 PM UTC
• Version: 1.0.1

Overview

The skill is for running a Lightning node, but its production path exposes wallet and signing authority in ways that could put real funds at risk.

Use this only for disposable testnet, signet, or regtest setups unless you harden it first. For real funds, keep the signer on a separate secured host, bind admin APIs to localhost or an internal network only, replace admin macaroons with least-privilege signing credentials, avoid plaintext seed/passphrase storage, validate credential archives before extraction, and pin or verify all images and source releases.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• 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

Findings (7)

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/import-credentials.sh:73
• Finding: Unvalidated Credential Archive Extraction Allows Arbitrary File Overwrite<![CDATA[ ## Vulnerability Details **File Location**: `scripts/import-credentials.sh:73-80` **Vulnerability Type**: Unsafe archive extraction **Risk Level**: High ### Vulnerable Code ```bash elif [ -f "$BUNDLE" ]; then # File: assume base64-encoded tar.gz. echo "Importing from file: $BUNDLE" base64 -d < "$BUNDLE" | tar -xzf - -C "$CREDS_DIR" else # Raw base64 string: decode and extract. echo "Importing from base64 string..." echo "$BUNDLE" | base64 -d | tar -xzf - -C "$CREDS_DIR" fi ``` ### Technical Analysis The script extracts a user-supplied archive directly into the credential directory without validating archive members. It does not reject: - Absolute paths - `../` path traversal - Symbolic or hard links - Device nodes or other special files - Files outside the expected `accounts.json`, `tls.cert`, and `admin.macaroon` allowlist The later existence and permission checks do not undo files written outside the destination. A malicious tar archive can therefore use traversal entries or links to overwrite arbitrary files writable by the invoking user. ### Attack Path 1. An attacker supplies a crafted base64-encoded tarball as the signer credential bundle. 2. The victim invokes the documented `import-credentials.sh --bundle` workflow. 3. `tar` processes a malicious traversal or link entry. 4. The entry escapes `~/.lnget/lnd/signer-credentials`. 5. An attacker-selected configuration, shell startup file, executable, or other user-writable file is overwritten. 6. The overwritten file may subsequently trigger code execution under the victim's account. ### Impact Assessment An attacker can overwrite files with the privileges of the user running the Skill. Depending on writable targets and subsequent application behavior, this can cause credential replacement, configuration poisoning, denial of service, or local code execution. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Decode the bundle into a newly created directory from `mktemp -d`. 2. List and validate every archive member before extraction. 3. Reject absolute paths, `..` components, links, devices, FIFOs, and unexpected file types. 4. Permit exactly three regular files with fixed names. 5. Extract with restrictive ownership and permission options. 6. Copy validated files into the destination only after all checks succeed. 7. Remove the temporary directory using a safely quoted trap. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: templates/docker-compose-watchonly.yml:31
• Finding: Production Watch-Only Deployment Co-Locates the Private-Key Signer with the Agent Node<![CDATA[ ## Vulnerability Details **File Location**: `templates/docker-compose-watchonly.yml:31-42` **Vulnerability Type**: Broken remote-signer isolation and excessive privilege exposure **Risk Level**: High ### Vulnerable Code ```yaml signer: image: ${LND_IMAGE:-lightninglabs/lnd}:${LND_VERSION:-v0.20.0-beta} container_name: litd-signer restart: unless-stopped entrypoint: ["/bin/sh", "-c", "touch /root/.lnd/wallet-password.txt && cp /tmp/lnd.conf /root/.lnd/lnd.conf && exec lnd"] ports: - "${SIGNER_RPC_PORT:-10012}:10012" - "${SIGNER_REST_PORT:-10013}:10013" volumes: - signer-data:/root/.lnd - ${SIGNER_CONF_PATH:-../../lightning-security-module/templates/signer-lnd.conf.template}:/tmp/lnd.conf:ro networks: - litd-watchonly ``` ### Technical Analysis The Skill describes watch-only mode as a production architecture in which private keys remain on a separate signer machine. The supplied production-oriented Compose template instead launches the signer on the same Docker host and stores its key-bearing LND data in a local Docker volume. This does not provide a meaningful isolation boundary against compromise of the agent host or any agent account with Docker access. Docker access generally permits container execution, inspection, volume mounting, and modification of the signer service. ### Attack Path 1. An attacker compromises the agent account or another process with access to the Docker daemon. 2. The attacker inspects or executes commands inside `litd-signer`, or mounts the `signer-data` volume into another container. 3. The attacker accesses signer wallet state, credentials, or exposed signing interfaces. 4. The attacker extracts key material where available or causes the signer to authorize malicious transactions. ### Impact Assessment The compromise scope can include the private-key signer and all funds controlled by it. This defeats the claimed protection that compromise of the watch-only ...[truncated 66 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Do not start the production signer in the agent-host Compose stack. 2. Place the signer on a separately secured host or hardware-backed signing environment. 3. Connect over an authenticated private network with strict firewall rules. 4. Use a signing-only macaroon rather than administrative credentials. 5. Deny the agent account access to the signer host and Docker daemon. 6. Clearly classify the current two-container deployment as development or test-only. 7. Document that Docker containers on one host do not constitute a secure signer separation boundary. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: templates/docker-compose-watchonly.yml:36
• Finding: Signer and Wallet Administrative APIs Are Published on All Host Interfaces<![CDATA[ ## Vulnerability Details **File Location**: `templates/docker-compose-watchonly.yml:36-56` **Vulnerability Type**: Excessive network service exposure **Risk Level**: High ### Vulnerable Code ```yaml ports: - "${SIGNER_RPC_PORT:-10012}:10012" - "${SIGNER_REST_PORT:-10013}:10013" volumes: - signer-data:/root/.lnd - ${SIGNER_CONF_PATH:-../../lightning-security-module/templates/signer-lnd.conf.template}:/tmp/lnd.conf:ro networks: - litd-watchonly litd: image: ${LITD_IMAGE:-lightninglabs/lightning-terminal}:${LITD_VERSION:-v0.16.0-alpha} container_name: litd restart: unless-stopped depends_on: - signer entrypoint: ["/bin/sh", "-c", "touch /root/.lnd/wallet-password.txt && cp /tmp/lit.conf /root/.lit/lit.conf && exec litd"] ports: - "${LITD_HTTPS_PORT:-8443}:8443" - "${LND_GRPC_PORT:-10009}:10009" - "${LND_P2P_PORT:-9735}:9735" - "${LND_REST_PORT:-8080}:8080" ``` ### Technical Analysis Docker Compose short-form port mappings without an explicit host address normally bind to all host interfaces. The template consequently publishes the signer RPC and REST interfaces, as well as LND administrative APIs, beyond the internal Docker network. The signer ports are only required for communication between `litd` and the signer and therefore exceed minimum privilege when published to the host. Similar unrestricted mappings also appear in the standalone and regtest Compose templates. ### Attack Path 1. An attacker gains network reachability to the Docker host. 2. The attacker scans the documented ports, including 10012, 10013, 10009, and 8080. 3. The attacker interacts with signer or wallet-management endpoints. 4. A leaked macaroon, weak deployment configuration, initialization-state issue, or service vulnerability is used to authenticate or bypass intended controls. 5. The attacker invokes wallet, signing, payment, or administrative operations. ### Impact Assessm ...[truncated 263 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove host `ports` entries for signer RPC and REST services. 2. Use the internal Compose network or `expose` for container-to-container communication. 3. Bind required administrative interfaces to `127.0.0.1`, for example `127.0.0.1:10009:10009`. 4. Publish only the Lightning peer-to-peer port where external access is operationally required. 5. Apply host firewall rules and network segmentation. 6. Enforce TLS verification and least-privilege macaroon authentication. 7. Provide explicit opt-in configuration for remote administrative access rather than enabling it by default. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: scripts/import-credentials.sh:102
• Finding: Full-Privilege Signer Admin Macaroon Is Required and Duplicated into the Agent Container<![CDATA[ ## Vulnerability Details **File Location**: `scripts/import-credentials.sh:102-131` **Vulnerability Type**: Excessive bearer-token privileges **Risk Level**: Critical ### Vulnerable Code ```bash if [ -f "$CREDS_DIR/admin.macaroon" ]; then echo " admin.macaroon — OK" else echo " admin.macaroon — MISSING" >&2 MISSING=true fi if [ "$MISSING" = true ]; then echo "" >&2 echo "Error: Credentials bundle is incomplete." >&2 echo "Expected: accounts.json, tls.cert, admin.macaroon" >&2 exit 1 fi # Set restrictive permissions on credential files. chmod 600 "$CREDS_DIR/accounts.json" chmod 600 "$CREDS_DIR/tls.cert" chmod 600 "$CREDS_DIR/admin.macaroon" echo "" # If a litd container is running, copy credentials into it so the # remotesigner config paths resolve inside the container. if command -v docker &>/dev/null; then for candidate in litd litd-shared; do if docker ps --format '{{.Names}}' 2>/dev/null | grep -qx "$candidate"; then docker exec "$candidate" mkdir -p /root/.lnd/signer-credentials docker cp "$CREDS_DIR/tls.cert" "$candidate:/root/.lnd/signer-credentials/tls.cert" docker cp "$CREDS_DIR/admin.macaroon" "$candidate:/root/.lnd/signer-credentials/admin.macaroon" docker cp "$CREDS_DIR/accounts.json" "$candidate:/root/.lnd/signer-credentials/accounts.json" ``` ### Technical Analysis The importer requires an `admin.macaroon` even though the Skill's own security guidance states that agents should not receive administrative macaroons in production. The macaroon is a bearer capability and is copied into both host storage and the watch-only container. Remote signing requires only signer-specific permissions. Requiring full administrative authority violates least privilege and increases the number of compromise locations. File mode `0600` does not protect the token from the owning agent account, root, Docker-capable processes, or compromise of the destination con ...[truncated 732 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Replace the mandatory `admin.macaroon` with a signing-only macaroon. 2. Use a neutral filename such as `signer.macaroon`. 3. Reject administrative macaroons in production mode where token permissions can be inspected. 4. Avoid duplicating the token across host and container storage. 5. Mount the credential read-only from a protected secret store where possible. 6. Add token rotation and revocation procedures. 7. Keep the signer RPC interface internal and inaccessible from untrusted networks. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/create-wallet.sh:224
• Finding: Standalone Wallet Seed and Unlock Passphrase Are Stored Together in Plaintext<![CDATA[ ## Vulnerability Details **File Location**: `scripts/create-wallet.sh:224-245,420-431` **Vulnerability Type**: Plaintext storage of complete wallet recovery credentials **Risk Level**: Critical ### Vulnerable Code ```bash # Create credential storage directory with restricted permissions. mkdir -p "$LNGET_LND_DIR" chmod 700 "$LNGET_LND_DIR" PASSWORD_FILE="$LNGET_LND_DIR/wallet-password.txt" SEED_OUTPUT="$LNGET_LND_DIR/seed.txt" # Generate or use provided passphrase. if [ -n "$PASSWORD" ]; then echo "Using provided passphrase." else echo "Generating secure passphrase..." PASSWORD=$(openssl rand -base64 32 | tr -d '/+=' | head -c 32) fi # Store passphrase with restricted permissions on host. echo -n "$PASSWORD" > "$PASSWORD_FILE" chmod 600 "$PASSWORD_FILE" echo "Passphrase saved to $PASSWORD_FILE (mode 0600)" echo "" # Copy password file into container if applicable. if [ -n "$CONTAINER" ]; then docker cp "$PASSWORD_FILE" "$CONTAINER:/root/.lnd/wallet-password.txt" echo "Password file copied into container." fi ``` ```bash # Store seed with restricted permissions on host. echo "$MNEMONIC" > "$SEED_OUTPUT" chmod 600 "$SEED_OUTPUT" echo "Seed mnemonic saved to $SEED_OUTPUT (mode 0600)" echo "" # Initialize wallet with password and seed. SEED_JSON=$(echo "$MNEMONIC" | jq -R . | jq -s .) PAYLOAD=$(jq -n \ --arg pass "$(echo -n "$PASSWORD" | base64)" \ --argjson seed "$SEED_JSON" \ '{wallet_password: $pass, cipher_seed_mnemonic: $seed}') ``` ### Technical Analysis Standalone mode writes both the master seed mnemonic and the wallet encryption passphrase as plaintext files under the same user-controlled directory. The password is additionally copied into the container. Unix mode `0600` only restricts access from other unprivileged local users. It does not protect against compromise of the owning account, root access, malware running as that user, Docker daemon access, insecure backups, or storage snapshots. Because both ...[truncated 785 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Do not persist the mnemonic by default. 2. Present it once through an explicit interactive backup workflow. 3. Require confirmation that an offline backup has been completed. 4. Store unlock credentials in an OS keychain, hardware-backed secret store, or dedicated secrets manager. 5. Keep the mnemonic and unlock passphrase in separate security domains. 6. Prevent standalone mode on mainnet unless the operator supplies an explicit high-risk override. 7. Remove temporary shell variables and files as soon as practicable and disable verbose tracing around secret operations. 8. Prefer a genuinely remote, separately secured signer for production funds. ]]>

T08 · Insecure Dependencies

Error

• Location: scripts/install.sh:91
• Finding: Docker Images and Source Releases Are Executed Without Cryptographic Integrity Verification<![CDATA[ ## Vulnerability Details **File Location**: `scripts/install.sh:91-123,163-176` **Vulnerability Type**: Unverified third-party dependency installation **Risk Level**: High ### Vulnerable Code ```bash # Clone lnd into a temp directory and build from source. TMPDIR=$(mktemp -d) trap "rm -rf $TMPDIR" EXIT echo "Cloning lnd..." git clone --quiet https://github.com/lightningnetwork/lnd.git "$TMPDIR/lnd" cd "$TMPDIR/lnd" # Checkout specific version if requested, otherwise use latest tag. if [ -n "$SOURCE_VERSION" ]; then echo "Checking out $SOURCE_VERSION..." git checkout --quiet "$SOURCE_VERSION" else LATEST_TAG=$(git describe --tags --abbrev=0 2>/dev/null || echo "") if [ -n "$LATEST_TAG" ]; then echo "Using latest tag: $LATEST_TAG" git checkout --quiet "$LATEST_TAG" else echo "Using HEAD (no tags found)." fi fi echo "" GOBIN=$(go env GOPATH)/bin # Build lnd. echo "Building lnd..." go build -tags "$BUILD_TAGS" -o "$GOBIN/lnd" ./cmd/lnd echo "Done." # Build lncli. echo "Building lncli..." go build -tags "$BUILD_TAGS" -o "$GOBIN/lncli" ./cmd/lncli ``` ```bash IMAGE="${LITD_IMAGE:-lightninglabs/lightning-terminal}" TAG="${VERSION:-${LITD_VERSION:-v0.16.0-alpha}}" echo "Image: $IMAGE:$TAG" echo "" # Pull the image. echo "Pulling image..." docker pull "$IMAGE:$TAG" echo "" # Verify the image works. echo "Verifying installation..." docker run --rm "$IMAGE:$TAG" litd --version 2>/dev/null || true ``` ### Technical Analysis Container images are referenced by mutable tags rather than immutable content digests. Source installation checks out a supplied tag or the repository's latest tag without verifying a signed release, expected commit hash, or checksum. Executing `litd --version` only confirms that the downloaded image runs; it does not verify its provenance or integrity. The command also executes the unverified artifact. Environment variables can override image names, further expanding the trust boun ...[truncated 850 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin Docker images using immutable SHA-256 digests. 2. Verify image signatures and provenance attestations before execution. 3. Pin source builds to reviewed commit hashes. 4. Verify signed release tags against trusted maintainer keys. 5. Validate published checksums and fail closed on any mismatch. 6. Do not fall back to repository HEAD when a pinned version is unavailable. 7. Restrict or validate environment-variable image overrides in production. 8. Update documentation so a version command is not described as integrity verification. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: templates/docker-compose-regtest.yml:40
• Finding: Regtest Bitcoin RPC Uses Public Fixed Credentials and Unrestricted Binding<![CDATA[ ## Vulnerability Details **File Location**: `templates/docker-compose-regtest.yml:40-57` **Vulnerability Type**: Hardcoded credentials and unrestricted RPC exposure **Risk Level**: Medium ### Vulnerable Code ```yaml command: - -regtest - -server=1 - -rpcuser=devuser - -rpcpassword=devpass - -rpcallowip=0.0.0.0/0 - -rpcbind=0.0.0.0 - -txindex=1 - -fallbackfee=0.00001 - -addresstype=bech32m - -changetype=bech32m - -zmqpubrawblock=tcp://0.0.0.0:28332 - -zmqpubrawtx=tcp://0.0.0.0:28333 - -zmqpubhashblock=tcp://0.0.0.0:28332 - -zmqpubhashtx=tcp://0.0.0.0:28333 ports: - "18443:18443" - "28332:28332" - "28333:28333" ``` ### Technical Analysis The regtest Bitcoin Core service uses hardcoded, documented credentials and accepts RPC traffic from every source address. Port 18443 is published on all host interfaces by default. Although regtest does not control real Bitcoin, the service remains a privileged test-environment control plane. Any network client that can reach the port knows the credentials and can invoke Bitcoin Core RPC commands. ### Attack Path 1. An attacker obtains network access to the host running the regtest stack. 2. The attacker connects to TCP port 18443. 3. The attacker authenticates with `devuser` and `devpass`, which are embedded in the template and documentation. 4. The attacker invokes arbitrary enabled Bitcoin Core RPC methods. 5. The attacker modifies blockchain test state, disrupts integration tests, consumes resources, or manipulates dependent application behavior. ### Impact Assessment The direct impact is primarily confined to the regtest environment. An attacker can control test-chain state, invalidate test results, disrupt dependent services, and potentially use the exposed daemon as a foothold in a broader development-environment attack. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Do not publish Bitcoin RPC outside the Compose network unless explicitly required. 2. Bind any necessary host mapping to `127.0.0.1`. 3. Restrict `rpcallowip` to the exact internal Compose subnet or service addresses. 4. Generate a random per-deployment RPC password. 5. Pass credentials through a protected secret file or Docker secret rather than command-line arguments. 6. Add a clear warning that the regtest stack must not be exposed to untrusted networks. 7. Restrict ZMQ port publication when only internal `litd` access is required. ]]>

SkillSpector

Vulnerability Patterns

• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration

Findings (53)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 94% confidence
• Finding: The description centers on running Lightning services, but the skill also reads a wallet passphrase from disk and unlocks wallets via REST against local, containerized, or remote nodes. That materially increases the sensitivity of the skill because it moves from infrastructure setup into credential use and operational control over funds.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The description centers on running Lightning services, but the skill also reads a wallet passphrase from disk and unlocks wallets via REST against local, containerized, or remote nodes. That materially increases the sensitivity of the skill because it moves from infrastructure setup into credential use and operational control over funds.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 96% confidence
• Finding: The description centers on running Lightning services, but the skill also reads a wallet passphrase from disk and unlocks wallets via REST against local, containerized, or remote nodes. That materially increases the sensitivity of the skill because it moves from infrastructure setup into credential use and operational control over funds.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 95% confidence
• Finding: The description centers on running Lightning services, but the skill also reads a wallet passphrase from disk and unlocks wallets via REST against local, containerized, or remote nodes. That materially increases the sensitivity of the skill because it moves from infrastructure setup into credential use and operational control over funds.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 95% confidence
• Finding: The description centers on running Lightning services, but the skill also reads a wallet passphrase from disk and unlocks wallets via REST against local, containerized, or remote nodes. That materially increases the sensitivity of the skill because it moves from infrastructure setup into credential use and operational control over funds.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The description centers on running Lightning services, but the skill also reads a wallet passphrase from disk and unlocks wallets via REST against local, containerized, or remote nodes. That materially increases the sensitivity of the skill because it moves from infrastructure setup into credential use and operational control over funds.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 94% confidence
• Finding: The description centers on running Lightning services, but the skill also reads a wallet passphrase from disk and unlocks wallets via REST against local, containerized, or remote nodes. That materially increases the sensitivity of the skill because it moves from infrastructure setup into credential use and operational control over funds.

Credential Access

High

• Category: Privilege Escalation

Content

2. Calls `/v1/genseed` to generate a 24-word seed mnemonic
3. Calls `/v1/initwallet` with the passphrase and seed
4. Stores credentials securely:
   - `~/.lnget/lnd/wallet-password.txt` (mode 0600)
   - `~/.lnget/lnd/seed.txt` (mode 0600)

### Unlock Wallet

• Confidence: 97% confidence
• Finding: The skill documents generating and storing a wallet passphrase and seed mnemonic on local disk. Even with 0600 permissions, local plaintext storage of wallet recovery material is highly sensitive; compromise of the host, backups, logs, or user account can expose funds and enable wallet takeover.

Credential Access

High

• Category: Privilege Escalation

Content

| Path | Purpose |
|------|---------|
| `~/.lnget/lnd/wallet-password.txt` | Wallet unlock passphrase (0600) |
| `~/.lnget/lnd/seed.txt` | 24-word mnemonic backup (0600, standalone only) |
| `~/.lnget/lnd/signer-credentials/` | Imported signer credentials (watch-only) |
| `versions.env` | Pinned container image versions |

• Confidence: 96% confidence
• Finding: The documented file locations include plaintext wallet unlock material and seed backups under the user's home directory. Publishing stable credential paths increases discoverability for malware, other local users, or misconfigured backup/sync tooling, raising the risk of credential theft and fund loss.

Credential Access

High

• Category: Privilege Escalation

Content

| File | Contents | Permissions |
|------|----------|-------------|
| `~/.lnget/lnd/wallet-password.txt` | Wallet unlock passphrase | 0600 |
| `~/.lnget/lnd/seed.txt` | 24-word BIP39 mnemonic | 0600 |

**This is suitable for:**

• Confidence: 98% confidence
• Finding: The documentation identifies storage of the wallet unlock password and the 24-word seed in plaintext files under the agent user's home directory. Those two files are sufficient for full wallet recovery and spending, so any local compromise, same-user process access, backup leakage, or disk exfiltration can result in complete loss of funds.

Credential Access

High

• Category: Privilege Escalation

Content

wallet recovery.

2. **OS keychain:** Store the seed in the operating system's keychain (macOS
   Keychain, Linux Secret Service). Requires keychain unlock but survives
   disk inspection.

3. **Migrate to remote signer:** The recommended path. Use the

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

#   standalone  — generates seed locally (keys on disk, less secure)
#
# Stores credentials at:
#   ~/.lnget/lnd/wallet-password.txt  (mode 0600)
#   ~/.lnget/lnd/seed.txt             (mode 0600, standalone mode only)

set -e

• Confidence: 92% confidence
• Finding: The script explicitly stores the wallet passphrase on disk in ~/.lnget/lnd/wallet-password.txt, and in standalone mode also stores the seed phrase in plaintext. Even with 0600 permissions, plaintext wallet secrets on disk materially increase the blast radius of local compromise, backups leakage, endpoint malware, or accidental exfiltration.

Credential Access

High

• Category: Privilege Escalation

Content

mkdir -p "$LNGET_LND_DIR"
chmod 700 "$LNGET_LND_DIR"

PASSWORD_FILE="$LNGET_LND_DIR/wallet-password.txt"
SEED_OUTPUT="$LNGET_LND_DIR/seed.txt"

# Generate or use provided passphrase.

• Confidence: 95% confidence
• Finding: This line defines a fixed path for storing the wallet passphrase as a plaintext file, which is then used later in the workflow. In the context of a Lightning node, persistent local storage of wallet unlock material can allow unauthorized wallet access after host compromise and is especially risky because this skill handles financial assets.

Credential Access

High

• Category: Privilege Escalation

Content

# Copy password file into container if applicable.
if [ -n "$CONTAINER" ]; then
    docker cp "$PASSWORD_FILE" "$CONTAINER:/root/.lnd/wallet-password.txt"
    echo "Password file copied into container."
fi

• Confidence: 94% confidence
• Finding: Copying the plaintext password file into the container duplicates sensitive wallet unlock material and expands the number of locations from which it can be recovered. If the container filesystem, image layers, backups, or runtime environment are exposed, the wallet passphrase may be obtained by an attacker.

Credential Access

High

• Category: Privilege Escalation

Content

else
        echo "Error: Profile '$PROFILE' not found." >&2
        echo "Available profiles:"
        ls -1 "$PROFILE_DIR"/*.env 2>/dev/null | xargs -n1 basename | sed 's/.env$//'
        exit 1
    fi
fi

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

else
        echo "Error: Profile '$PROFILE' not found." >&2
        echo "Available profiles:"
        ls -1 "$PROFILE_DIR"/*.env 2>/dev/null | xargs -n1 basename | sed 's/.env$//'
        exit 1
    fi
fi

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

set -e

LNGET_LND_DIR="${LNGET_LND_DIR:-$HOME/.lnget/lnd}"
PASSWORD_FILE="$LNGET_LND_DIR/wallet-password.txt"
REST_PORT=8080
REST_HOST="localhost"
CONTAINER=""

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

set -e

LNGET_LND_DIR="${LNGET_LND_DIR:-$HOME/.lnget/lnd}"
PASSWORD_FILE="$LNGET_LND_DIR/wallet-password.txt"
REST_PORT=8080
REST_HOST="localhost"
CONTAINER=""

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

set -e

LNGET_LND_DIR="${LNGET_LND_DIR:-$HOME/.lnget/lnd}"
PASSWORD_FILE="$LNGET_LND_DIR/wallet-password.txt"
REST_PORT=8080
REST_HOST="localhost"
CONTAINER=""

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

set -e

LNGET_LND_DIR="${LNGET_LND_DIR:-$HOME/.lnget/lnd}"
PASSWORD_FILE="$LNGET_LND_DIR/wallet-password.txt"
REST_PORT=8080
REST_HOST="localhost"
CONTAINER=""

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

set -e

LNGET_LND_DIR="${LNGET_LND_DIR:-$HOME/.lnget/lnd}"
PASSWORD_FILE="$LNGET_LND_DIR/wallet-password.txt"
REST_PORT=8080
REST_HOST="localhost"
CONTAINER=""

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

set -e

LNGET_LND_DIR="${LNGET_LND_DIR:-$HOME/.lnget/lnd}"
PASSWORD_FILE="$LNGET_LND_DIR/wallet-password.txt"
REST_PORT=8080
REST_HOST="localhost"
CONTAINER=""

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

set -e

LNGET_LND_DIR="${LNGET_LND_DIR:-$HOME/.lnget/lnd}"
PASSWORD_FILE="$LNGET_LND_DIR/wallet-password.txt"
REST_PORT=8080
REST_HOST="localhost"
CONTAINER=""

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

set -e

LNGET_LND_DIR="${LNGET_LND_DIR:-$HOME/.lnget/lnd}"
PASSWORD_FILE="$LNGET_LND_DIR/wallet-password.txt"
REST_PORT=8080
REST_HOST="localhost"
CONTAINER=""

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 93% confidence
• Finding: The skill documents extensive shell-based operations that install software, start containers, manage wallets, and interact with remote services, but it declares no explicit tool scope or allowed-tools boundary. That omission increases the chance an agent is granted broader shell access than necessary, making accidental or unsafe command execution more likely in a high-risk financial context.

Static analysis

No suspicious patterns detected.