Policy Document
Software Life Cycle
This page describes how long Lightning Labs maintains a released version of LND, which versions receive security fixes, and when a version reaches end of life. It is the companion to our Severity Taxonomy: the taxonomy says how severe a finding is, this page says which releases get the fix and when the advisory becomes public.
It is written for node operators, integrators, and security researchers who need to know whether the version they are running is still receiving security fixes.
Versioning
LND releases are tagged v0.MAJOR.MINOR-beta.
- The major number is the middle component.
v0.21.0-betaandv0.20.0-betaare different major releases. - The minor number is the trailing component.
v0.21.1-betais a minor release on thev0.21line. - Release candidates append
.rc1,.rc2, and so on — for examplev0.21.2-beta.rc1— and are not supported releases.
The leading 0. and the -beta suffix are historical. They do not indicate
that a release is unsupported, and they do not carry semantic-versioning
meaning. Treat the middle number as the major version.
A minor release carries changes that can be backported safely and reviewed in isolation:
- security fixes;
- bug fixes;
- stability and reliability improvements;
- performance improvements;
- protocol and specification updates;
- dependency and library upgrades;
- small UI/UX fixes, and occasionally a minor feature.
A major release is where the changes a minor release cannot carry land: new features, database migrations, API-breaking changes, and anything else that alters expected behaviour or requires operators to plan an upgrade.
We keep the patches in a minor release small and single-purpose. The distinction is about the risk a change carries and whether it can be reviewed on its own, not about how large the diff is.
A release line is a major release together with all of its minor
releases. v0.21 is a release line; v0.21.0-beta and v0.21.1-beta are
releases on it.
Maintained releases
Lightning Labs maintains the two most recent LND release lines: the current major line, and the one immediately before it.
Both maintained lines receive security fixes. When a security fix lands on the current line and applies to the previous line, it is normally backported there and shipped in a minor release on that line. The rare exception is a fix that cannot be safely backported; see What this policy does not promise.
When a new major release ships, the older of the two maintained lines reaches end of life that day. End of life is triggered by the arrival of a new major release, not by a calendar date.
Worked example: while v0.21 is the current line, v0.21 and v0.20 are
maintained and v0.19 is end of life. When v0.22.0-beta ships, v0.22 and
v0.21 become the maintained lines and v0.20 reaches end of life on that
date.
We recommend running the latest minor release of the most recent major line you are able to upgrade to. A maintained line only protects you if you are actually on its latest minor release.
End of life
A release line that has reached end of life receives no further releases of any kind, including security fixes. Known vulnerabilities affecting an end-of-life line are not backported to it, and future vulnerabilities affecting it will not be either.
We do not issue exceptions to this. If a critical vulnerability is found that affects an end-of-life line, the remedy we will offer is an upgrade to a maintained line.
Because end of life is triggered by the next major release rather than by a date, the length of a support window follows our major-release cadence: a line stays maintained until the second major release after it. We do not commit to a fixed major-release cadence, and therefore do not state a support window in months. The table below gives the dates for every past line.
LND release lines
| Line | First release | Latest minor release | Status | End of life |
|---|---|---|---|---|
| v0.21 | 2026-06-05 | v0.21.1-beta (2026-06-30) |
Maintained (current) | When v0.23.0-beta ships |
| v0.20 | 2025-11-20 | v0.20.2-beta (2026-07-08) |
Maintained (previous) | When v0.22.0-beta ships |
| v0.19 | 2025-05-22 | v0.19.3-beta (2025-08-21) |
End of life | 2026-06-05 (v0.21.0-beta shipped) |
| v0.18 | 2024-05-30 | v0.18.5-beta (2025-02-12) |
End of life | 2025-11-20 (v0.20.0-beta shipped) |
| v0.17 | 2023-10-03 | v0.17.5-beta (2024-04-23) |
End of life | 2025-05-22 (v0.19.0-beta shipped) |
| v0.16 and earlier | — | — | End of life | — |
End-of-life dates for lines that predate this policy are stated by applying the two-line rule retroactively, so that the table reads consistently. They describe when those lines stopped receiving fixes in practice.
The “Latest minor release” column was last verified on 2026-08-11. The lnd releases page is the source of truth for the latest minor release on each line.
Disclosure timing
Shipping a fix is not the same as publishing an advisory. A fix goes out in the earliest minor release it can; the advisory describing it is published on the schedule below, so that operators have a supported release to upgrade to before the details are public. Advisories are published to the security advisory list on this site.
| Tier | Advisory published |
|---|---|
| T0 | Ad hoc. Timing is set case by case, alongside the response itself. |
| T1 | Four weeks after the last affected major line reaches end of life. |
| T2 | Four weeks after the last affected major line reaches end of life. |
| T3 | Four weeks after the fix has shipped on every maintained line it applies to. |
“Last affected major line” means the most recent line the vulnerability affects. A T1 or T2 finding that affects the current line therefore waits until that line reaches end of life, which is to say until the second major release after it ships. A finding that affects only lines already at end of life receives no fix at all, since end-of-life lines receive no releases, but it still receives an advisory: operators running those lines need to know the remedy is to upgrade. In that case the advisory is published roughly four weeks after the finding is triaged.
Tiers are assigned using the Severity Taxonomy. We may publish earlier than the schedule above — for instance where a finding is already public, where a coordinating project is ready to disclose, or where operators are better served by details than by silence.
Notification of individual node operators ahead of publication is a separate matter, driven by the severity of the specific finding rather than by this policy or by the release schedule.
What this policy does not promise
- A major-release date. We do not commit to a release cadence, so we do not commit to when any current line will reach end of life.
- A fix for every reported issue on a maintained line. Maintained means a line is eligible for security backports, not that every finding is backportable. Where a fix cannot be safely backported, we will say so.
- Support for forks, distributions, or repackaged builds. This policy covers releases published by Lightning Labs.
- Coverage of products other than LND. This page describes LND, the first Lightning Labs product with a stated support window. We may extend this policy to other products in future; until we do, no support window is stated for them.
To report a vulnerability, email security@lightning.engineering.