Critical severityWeb

Master Seed & API Secrets Logged in Plaintext in a Lightning-Network SDK (and a Signing-Validation Bypass)

Afaq AmjadFebruary 24, 20267 min read

Type: Sensitive data exposure / hardcoded credentials / broken authorization · Severity: Critical→Low · Reported to a private bug-bounty program via HackerOne.

Vendor and package names are redacted per coordinated-disclosure rules; this covers the vulnerability classes only.

1. Critical — master seed & API secrets logged in plaintext

A remote-signing server example printed the master seed, API client secret, and webhook secret to stdout at startup — the most sensitive material in a Lightning-Network node setup.

log.Printf("  - API_CLIENT_SECRET: %s", showEmpty(apiClientSecret))
log.Printf("  - WEBHOOK_SECRET: %s", showEmpty(webhookSecret))
log.Printf("  - MASTER_SEED_HEX: %s", showEmpty(masterSeedHex))

In any cloud log pipeline (CloudWatch, GCP Logging, Datadog) these land in durable storage. The master seed signs arbitrary Lightning transactions → complete fund theft; the API secret grants full account access; the webhook secret enables forged payment notifications.

Fix: redact — never log secret values, e.g. MASTER_SEED_HEX: [REDACTED - %d bytes loaded].

2. High — hardcoded default password in a server example

password := os.Getenv("RECEIVER_USER_PASSWORD")
if password == "" {
    password = "pa$$w0rd" // "Super secure, right?"
}

Copy-paste to production leaves the server reachable with a known password. Fix: refuse to start when the env var is unset instead of falling back to a default.

3. Medium — password echoed in the login error response

On failed login the server reflected the submitted password back into the HTML — exposing it in browser history, proxy logs, and to shoulder-surfers. Never return passwords to the client.

4. Medium — a validator that approves every signing request

func (v PositiveValidator) ShouldSign(webhook webhooks.WebhookEvent) bool {
    return true  // approves everything
}

Enabled by a VALIDATION_ENABLED=false flag, this signs any transaction with no validation — unauthorized fund transfers if shipped to production. Fix: at minimum log a loud runtime warning; ideally remove it from production paths.

Takeaway

Example code becomes production code. Secrets in logs, default passwords, and "approve everything" test validators are exactly the shortcuts attackers count on developers leaving in.

#Secrets#CWE-532#CWE-798#CWE-863#SDK Security

More research

Think your systems could have this?

Let Faseel find it before an attacker does.

Request an Assessment