Taproot Assets

• Two separate defects, one in tapd and one in lnd, combined to make canceled HTLCs show up as settled invoices.
• The root fixes shipped in Taproot Assets v0.5.1 on Feb. 12, 2025 and lnd v0.19.0-beta on May 22, 2025, well before the disclosure.
• Lightning Terminal v0.15.0-alpha bundles both fixes; operators who cannot upgrade can disable Taproot Assets mode as a workaround.

• Sep 21 ’26 disclosure date, 19 months after the underlying code was patched
• Feb 12 ’25 date tapd v0.5.1 fixed the invoice-interceptor trigger
• May 22 ’25 date lnd v0.19.0-beta fixed the settlement accounting error

A Lightning payment moves through a hashed time-locked contract, or HTLC, that either settles or gets canceled and returned to the sender. In the affected setup, the underlying HTLC was canceled on the network while the receiving node’s software still recorded the linked invoice as settled, according to Lightning Labs, as reported by CryptoSlate. A merchant checking invoice status alone would see “paid” on a payment that had, in fact, bounced back to the customer.

Tapd’s Strict-Forwarding Rule Canceled Payments It Should Have Passed Through

Lightning Terminal bundles tapd, the software for Taproot Assets, with the lnd Lightning node. When tapd’s invoice interceptor was enabled, it treated any HTLC carrying custom wire records as an asset payment, even ordinary Bitcoin transfers.

Some sender implementations attach an experimental endorsement record to plain BTC payments. That record tripped tapd’s strict-forwarding rule, which instructed lnd to cancel the entire HTLC set, according to the advisory. Crucially, the trigger fired even on merchant nodes with no open asset channels, meaning operators who never touched Taproot Assets could still be exposed.

The second defect lived inside lnd itself. When an interceptor canceled an HTLC set, affected versions correctly canceled the payment on the wire but still wrote “settled” into the invoice database.

Lightning Labs notes that any other client of lnd’s HtlcModifier interface that cancels an HTLC set could trigger the identical mismatch, meaning the bug’s blast radius extended beyond tapd specifically.

Lightning Labs Rates the Bug High Severity Despite No Reported Losses

Lightning Labs classifies the issue as high severity on its security advisory page because a false “paid” status could lead an operator or payment processor to release value against a payment that never completed. That framing puts the risk on the receiving side of Lightning commerce, from point-of-sale merchants to custodial payment services that automate fulfillment based on invoice state.

The advisory is explicit that sender funds were never at risk; the HTLC returned to the payer as designed. The exposure sat entirely with recipients trusting a settlement flag that had drifted out of sync with the network’s actual outcome.

That distinction matters for how the crypto industry is thinking about payment reliability more broadly, an issue our earlier piece on why infrastructure needs guarantees it can’t break also raised in a different context. A settlement layer that silently disagrees with itself undermines the automation that Lightning-based commerce depends on.

Terminal v0.15.0-alpha Bundles Both Fixes, Nineteen Months After the Root Patches

Lightning Labs lists earlier Terminal versions as affected, along with Taproot Assets through v0.5.0 and lnd 0.18.4-beta through 0.18.5-beta. Terminal v0.14.1-alpha had already picked up the tapd fix from v0.5.1, but its bundled lnd release still carried the unrelated invoice-accounting defect, so the combined vulnerability persisted until both pieces landed together in v0.15.0-alpha.

In effect, the September 2026 advisory disclosed a vulnerability whose component fixes had already shipped separately more than a year earlier, in February and May 2025. For operators who cannot upgrade and run no asset channels, Lightning Labs points to the –taproot-assets-mode=disable flag as a way to avoid the tapd trigger without a full version bump.

The CCS read. The nineteen-month lag between patch and disclosure tells institutional operators more than the bug itself: Lightning’s security process trades public transparency for private remediation time, which is the right tradeoff for a live payment network but means anyone auditing Lightning infrastructure today should verify running versions against advisories retroactively, not just react to new ones.

Lightning Labs has not disclosed how many Terminal operators remain on pre-v0.15.0-alpha releases or whether any merchant reported a loss tied to the flaw before the fixes shipped in 2025; that gap in the public record leaves node operators to check their own version numbers against the advisory rather than wait for a follow-up disclosure.