CVE-2025-32013: LNbits SSRF Vulnerability

CVE-2025-32013 Overview

CVE-2025-32013 is a Server-Side Request Forgery (SSRF) vulnerability in LNbits, a Lightning Network wallet and accounts system. The flaw resides in the LNURL authentication handling functionality, where the application accepts a callback URL parameter and issues an HTTP request to that URL using the httpx library with redirect following enabled. The application fails to validate the callback URL, allowing attackers to direct requests at internal network addresses and access internal resources. The vulnerability is tracked as CWE-918: Server-Side Request Forgery.

Critical Impact

Unauthenticated remote attackers can coerce LNbits servers into making arbitrary HTTP requests to internal services, exposing sensitive data and metadata endpoints.

Affected Products

• LNbits (lnbits/lnbits) Lightning wallet and accounts system
• Deployments exposing the LNURL authentication endpoint
• Self-hosted LNbits instances reachable from untrusted networks

Discovery Timeline

• 2025-04-06 - CVE-2025-32013 published to NVD
• 2025-04-08 - Last updated in NVD database

Technical Details for CVE-2025-32013

Vulnerability Analysis

The vulnerability exists in the LNURL authentication request handler within LNbits. LNURL is a protocol that uses bech32-encoded URLs to facilitate Lightning Network interactions, including authentication flows. When a client initiates an LNURL-auth request, LNbits parses a callback URL parameter and dispatches an outbound HTTP request to that endpoint using the httpx HTTP client.

The handler enables redirect following on the httpx request without restricting the destination scheme, host, or IP range. An attacker can supply a callback URL pointing to private network ranges such as 127.0.0.1, 169.254.169.254, or RFC 1918 subnets. The server then performs the request on the attacker's behalf and may return the response body or observable side effects.

Root Cause

The root cause is missing URL validation before issuing server-side HTTP requests. The application trusts attacker-controlled input as a destination address and does not enforce an allowlist of permitted hosts or block private, loopback, and link-local IP ranges. Enabling automatic redirect following compounds the issue, because an attacker-controlled public host can return a 302 response that redirects the server to an internal target, bypassing naive host-based filters.

Attack Vector

Exploitation requires only network access to the LNbits LNURL authentication endpoint. No authentication, user interaction, or elevated privileges are required. An attacker crafts an LNURL-auth request containing a callback URL targeting an internal asset, then submits it to a vulnerable LNbits instance. Common targets include cloud metadata services (such as http://169.254.169.254/latest/meta-data/), internal admin panels, and unauthenticated internal APIs. The response or timing differences leak information about the internal network.

No verified public exploit code is available. Refer to the LNbits GitHub Security Advisory GHSA-qp8j-p87f-c8cc for the upstream technical description.

Detection Methods for CVE-2025-32013

Indicators of Compromise

• Outbound HTTP requests from LNbits processes targeting private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback 127.0.0.0/8, or cloud metadata IP 169.254.169.254.
• LNURL-auth request logs containing callback parameters with non-public hostnames or raw IP literals.
• Unexpected HTTP 3xx redirect chains in LNbits outbound traffic followed by connections to internal services.

Detection Strategies

• Inspect LNbits application logs for LNURL authentication callback URLs and flag entries whose resolved host falls outside expected public Lightning service domains.
• Correlate egress firewall or proxy logs with LNbits process identifiers to surface anomalous server-initiated requests to internal subnets.
• Deploy network detection rules that alert when application servers issue requests to cloud metadata endpoints or RFC 1918 ranges they have no business reaching.

Monitoring Recommendations

• Forward LNbits access logs, outbound proxy logs, and egress NetFlow records to a centralized analytics platform for correlation.
• Baseline LNbits outbound destinations and alert on deviations such as new internal IP targets or metadata service contact.
• Monitor for spikes in LNURL-auth endpoint traffic from single source IPs, which may indicate SSRF probing.

How to Mitigate CVE-2025-32013

Immediate Actions Required

• Upgrade LNbits to the patched release identified in the GitHub Security Advisory GHSA-qp8j-p87f-c8cc.
• Restrict outbound network access from the LNbits host to only the Lightning service endpoints it requires.
• Block LNbits egress to cloud metadata services, loopback, and private IP ranges at the network or host firewall layer.

Patch Information

The LNbits maintainers have published a fix referenced in the GitHub Security Advisory GHSA-qp8j-p87f-c8cc. Operators should consult the advisory for the exact fixed version and apply the upgrade promptly. Verify the upgrade by confirming that callback URLs targeting internal addresses are rejected by the LNURL authentication handler.

Workarounds

• Place LNbits behind an egress proxy that enforces a strict allowlist of permitted outbound destinations.
• Run LNbits in a network segment with no route to internal management networks or cloud metadata services.
• Disable or firewall the LNURL authentication endpoint at the reverse proxy until the patch is applied.
• For cloud deployments, enforce Instance Metadata Service v2 (IMDSv2) with hop limit 1 to prevent SSRF-based credential theft.

# Example iptables rule blocking LNbits egress to internal and metadata ranges
iptables -A OUTPUT -m owner --uid-owner lnbits -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner lnbits -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner lnbits -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner lnbits -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner lnbits -d 192.168.0.0/16 -j REJECT