Severity Taxonomy · Lightning Labs Security Advisories

This page explains how Lightning Labs classifies the severity of security vulnerabilities in our products. It is intended to help external reporters decide whether a finding is a security vulnerability under our policy, and to give a sense of the tier we would likely assign to it.

The taxonomy uses four tiers — T0, T1, T2, T3 — scored across four dimensions. Final tier assignment is always at Lightning Labs’ discretion; the rules below describe how we usually reach that decision, not a contractual entitlement.

Before scoring: is this a security issue?

Some findings do not need to be scored because they are not security vulnerabilities under this taxonomy. The following are out of scope:

Log spam or noisy debug output without information disclosure.
Minor rate-limiting gaps that do not produce denial of service at realistic scale.
Information leaks of non-sensitive data (for example, the presence of a feature flag in a status response).
General bugs, edge cases, or correctness issues with no fund-loss, liveness, or DoS implication.
Theoretical attacks that require unrealistic user action or misconfiguration.
Findings that duplicate a defect already fixed by a merged, public commit at the time of reporting.

No-adversary gate

Some findings describe a loss without an adversary causing one. Apply this gate before scoring any dimensions:

A finding is not a security vulnerability if the loss it describes follows from the system operating as designed under ordinary conditions, a documented design tradeoff, or operator-introduced exposure that deviates from a documented default.

Three recurring shapes:

Ordinary economic behavior. A node that declines to spend more claiming an output than the output is worth is not losing funds — the fee market, not a defect, determined the output was not worth claiming.
Documented design tradeoffs. For example, anchor channels require wallet UTXOs to CPFP a second-stage HTLC sweep. That is the documented cost of setting fees at broadcast time, not a defect, and a node whose wallet reserve is undersized for its outstanding HTLC exposure is running the format as documented.
Operator-introduced exposure. Some interfaces are unauthenticated by construction and protected by binding to localhost by default — the wallet-unlocker RPC, for instance, has no macaroon to check because no macaroon exists before a wallet does. A finding whose only path to reachability is an operator binding such an interface to a public one scores the operator’s deployment choice, not a defect. The exception from the threat model below still holds: a misconfiguration our own documentation plausibly leads to stays in scope, because the documentation is ours.

Look for the residual: a finding that fails this gate is often not empty. The fund-loss framing may be wrong while a narrower, real gap remains — typically a missing operator signal or a state transition that happens silently. The residual is scored on its own terms, at the tier it earns.

Privilege-escalation gate

Before scoring dimensions, apply this test:

If the actor required to trigger the finding already possesses a capability that yields the stated impact, there is no privilege escalation and the finding is not a security vulnerability, regardless of its impact score. Score the escalation, not the capability.

Compare what the required actor could do before the bug against what the same actor can do after. If the answer is the same, there is nothing to score. A credential deliberately baked narrower than the impact is the clear counterexample: a defect that lets its holder widen their own scope is an escalation beyond what was granted.

Stated as a counterfactual: absent this defect, could this actor already achieve the outcome through a supported interface? If yes, there is no vulnerability, however alarming the mechanism sounds on first read.

Identify the actor by who supplies the adversarial input, not whose hands are on the keyboard. Where an operator merely relays input another party authored — a malicious PSBT, a hostile invoice, a crafted payment request — the actor is the author of that input, not the operator relaying it.

Impact is not the only axis of the comparison. A capability that is broader in duration or transferable off-node is an escalation even where the immediate impact is identical: converting a revocable, node-bound credential into durable, transferable key material grants something the original credential did not.

Finally, key material reachable only with local access — TLS private keys, onion-service keys, macaroon-scoped secrets — is not a security issue under this taxonomy. Local access already reaches the plaintext material or an equivalent supported capability, so a defect that reaches the same material by a different route inside the same access boundary grants nothing.

Quick filter

Even for genuine DoS findings, the following combination exits the taxonomy:

Impact = Low AND Virality = Low AND either Exploitability = Low, or (Vector ≤ Med AND Exploitability ≤ Med).

An attacker who cannot engineer the trigger and cannot amortize across victims does not have an attack, and network reachability alone does not supply one. Findings that fall here should be tracked in the relevant product’s standard issue tracker.

Threat model

The taxonomy scores what an untrusted party can do to a victim node. Naming that party is a precondition for scoring anything else.

The parties we treat as untrusted, ordered roughly by reach:

Unauthenticated third parties. Any peer on the network, or the Bitcoin network itself by way of block and transaction broadcast. No prior relationship with the victim is required. This is the primary threat model.
Channel partners and established peers. A prior relationship exists, but the party remains untrusted; the Lightning protocol is built on the assumption that a counterparty may defect at any point.
Holders of a delegated credential narrower than the impact. For example, a macaroon scoped to one entity, or an account xpub exported for a limited purpose. Escalation beyond the granted scope is in the threat model, because the grant was deliberately narrow.

Explicitly outside the threat model: the node operator, and any party holding a credential that already grants the impact in question. An operator with an admin macaroon, file-system access, or the seed can already move funds, so a finding whose only actor is that party describes intended capability rather than a vulnerability. Operator misconfiguration of the operator’s own node likewise sits outside, with one exception: a misconfiguration a reasonable operator would plausibly land on by following our own documentation is in scope, because the documentation is ours.

Tier anchors

Before running the arithmetic, state in plain language which tier the finding belongs to:

T0. Viral fund loss. One action drains many victims, or one exploit template replays across them at negligible marginal cost per victim.
T1. Targeted fund loss, or invalidated liveness.
T2. Viral DoS, or fund loss whose trigger is rare.
T3. Reachable but non-viral DoS, operator-recoverable.

Per-victim fund loss is T1, not T2 — T2’s fund-loss clause is about rarity of trigger alone.

These anchors are the intent the tier rules encode. If dimension arithmetic disagrees with these anchors, that is usually a signal to re-check the dimension scores rather than to trust the arithmetic; a mismatch nearly always means a dimension was scored against the wrong actor, the wrong trigger, or a loss the finding does not own.

The four dimensions

Each dimension is scored Low / Med / High.

Dimension	Question	Low	Med	High
Impact	Worst-case outcome if the trigger fires	Transient service disruption, DoS, OOM — operator-recoverable	Per-victim fund loss, forced channel closure, or sustained unavailability that invalidates liveness	Widespread fund loss with amortization, or existential threat to the Lightning Network
Attack Vector	Where the attack lands	Local (operator, RPC, local system)	Adjacent (channel partner, established peer connection, gossip neighbor)	Network (any peer, or Bitcoin network broadcast)
Exploitability	How reliably the trigger fires against a typical victim	Rare conditions, unobservable to the attacker	Specific conditions, present in a fraction of the affected population	Reliably triggers against a typical victim
Virality	How one attack action amortizes across victims	Per-victim effort	Replayable template, near-zero marginal cost per additional victim	Automatic network propagation

Impact — key clarifications

Impact is a delta, not a state of the world. Score the harm the bug contributes, not the harm visible in the situation the bug was observed in. If fixing this finding alone would not have prevented the loss, this finding does not own that loss. A finding that mislabels or mishandles an outcome already determined by a different defect inherits none of that defect’s Impact.

Low vs Med turns on persistence, not on whether the node briefly stopped. A crash whose recovery is bounded by a process restart cycle is Low; a crash whose recovery is bounded by operator response time (manual db repair, poison-state cleanup, an ongoing attacker-controlled connection the victim cannot drop) is Med.

Med vs High turns on whether the loss stays bounded by the thing the defect touches. Med is the bounded case: this channel’s balance, this HTLC, the contents of this file, where each further unit of loss costs the attacker new work. High is the case where one exploit template keeps paying. The scale test runs against the technique, not the dollar figure: a single victim’s loss is Med however large it is in absolute terms, because nothing about it compounds without new attacker work against a second victim.

Reporting-integrity defects (a node affirmatively signals success for an operation that failed) score Impact = Low by default. They rise above Low only where the false signal is itself the cause of a loss — for instance, where an operator who would otherwise have acted inside a time window does not act because the node reported the matter resolved.

Exploitability — score against the population

Score against the affected population, not against a specific targeted victim the attacker cannot observe. If the required precondition is present in a non-trivial fraction of the population, that is Med, not Low.

Virality — per-attacker repetition does not count

Repeating an attack from one attacker machine against many victims does not by itself count as virality. Spamming TCP connections from one IP at many victims is per-victim effort regardless of how trivial each connection is. Virality = High means the network’s own mechanisms carry the attack — gossip propagation, block or transaction broadcast, cascading organic triggers.

Findings on a shared causal chain

When finding B is reachable only because finding A exists, score B’s Exploitability against B’s own trigger — not against A’s. B does not inherit High Exploitability from the observation that B fires reliably once A has fired. Impact splits the same way: attribute each consequence to the finding whose fix would have prevented that consequence.

Tier rules

The base tier is anchored on Impact; the other three dimensions adjust.

Rule 1 — Impact = High

Base: T1.

Promote to T0 if Vector ≥ Med AND Exploitability ≥ Med AND Virality ≥ Med.
Otherwise stay at T1. There is no demotion path within this rule (subject to the gates above: the privilege-escalation gate keeps out findings whose required actor already holds the impact, and the no-adversary gate keeps out findings with no adversary or defect at all).

Fund loss is fund loss: a High-Impact bug floors at T1 even with a Local vector and Low exploitability/virality.

Rule 2 — Impact = Med

Base: T1.

Promote to T0 if Vector = High AND Exploitability = High AND Virality = High. (Under review; this promotion may be tightened or removed in a later revision.)
Demote to T2 if Exploitability = Low, OR (Vector = Low AND Virality = Low).
Otherwise stay at T1.

Promotion here is stricter than Rule 1’s (all three at High, not just ≥ Med) because reaching T0 from a Med-Impact base requires that scale and reachability compensate for the Impact assessment.

Rule 3 — Impact = Low

Base: T3.

Promote to T2 if Virality = High.
Promote to T1 (two-tier promotion) if Virality = High AND Vector = High AND Exploitability = High. (Under review; this two-tier promotion may be tightened or removed in a later revision.)
Exit the taxonomy if (Virality = Low AND Exploitability = Low), or if the quick-filter condition above holds.
Otherwise stay at T3.

A reachable but non-viral DoS caps at T3. Trivial-but-bounded DoS is addressed by rate limiting and connection caps and does not need the disclosure machinery T2 implies. Vector alone does not hold a finding inside the taxonomy: Impact and Exploitability govern the exit.

Vulnerability tracking

Findings tracked under this taxonomy carry the four dimension scores as fields, alongside the resulting tier:

Severity — T0 / T1 / T2 / T3
Attack Vector — Local / Adjacent / Network
Exploitability — Low / Med / High
Impact — Low / Med / High
Virality — Low / Med / High

Discretion

The rubric describes how we usually arrive at a tier. Final classification — including whether a finding is a security vulnerability at all, which dimension scores apply, and the resulting tier — is at Lightning Labs’ discretion. Where the rubric’s mechanical output obviously fails a specific case, we may land one tier off with a rationale recorded on the underlying issue.

If you are unsure whether a finding is in scope, please report it to security@lightning.engineering and we will make the call.