EP
← All projectsElements Project

Core Lightning

Modular C implementation of the Lightning Network protocol and node stack.

BitcoinLightning NetworkActive incident
Repository coverage

1980 commits in the local evidence base

Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.

184security candidates280second-pass queue1894AI analyses
27commits · 30 days
184commits · 60 days
660commits · 180 days
1642commits · 365 days
Backfill bands
Aug 5 → Feb 61049 seen37 candidatesComplete
Feb 6 → Jun 6579 seen10 candidatesComplete
Jun 6 → Jul 678 seen1 candidatesComplete
Jul 6 → Aug 5147 seen16 candidatesComplete
Commit communication

Does the history explain itself?

Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.

71/100 average clarity
485Strong · 80–100
1224Adequate · 60–79
241Thin · 40–59
30Opaque · 0–39
Read the scoring rubric →
Developer activity

Who is changing the project?

Public Git author strings; identities are not independently verified.

DeveloperCommitsCandidatesAnalyzedHigh riskMessage avg.
cdecker14910384
Níckolas Goline63844277
Rusty Russell96475958172
daywalker90114895164
Lagrang386578170
Vincenzo Palazzo13411182
dovgopoly15015164
Sangbida Chaudhuri14931146066
Dusty Daemon821378066
ShahanaFarooqui931093063
Peter Neuroth1024101071
Christian Decker36436072
Analysis record

Published AI watches

Last scanned 44 minutes ago

Informational 15 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

contrib: add jaonoctus's signing key

This commit simply adds a new person's PGP public-key fingerprint to the list of trusted release signers in two documentation files. It does not change any code, fix any bug, or alter any security behavior of the software itself.

41278b4eby jaonoctus+2−02 files
No security note in commit
Informational 15 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: fixed timestamps for invented bookkeeper deposits

This is a tiny internal fix to make a bookkeeping migration produce stable event ordering. It changes the timestamp used when creating historical 'deposit' records during a one-time database migration, so the records sort consistently with…

498e5086by daywalker90+2−01 file
No security note in commit
Informational 21 AI analysisMessage 85 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

docs: document missing and fix erroneous JSON-RPC error codes

This commit is a documentation-only cleanup of the JSON-RPC command help files. It corrects which numeric error codes are listed for each command so the published schemas match what the software actually returns. No program logic, validati…

Documentation-only change with no executable code modificationsCorrects RPC schema error-code metadata to match actual handler behaviorNo change to input parsing, authorization, cryptography, or network behavior
d1b6963bby daywalker90+204−1224 files
No security note in commit
Low 46 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

channeld: initialize tx_sigs_allowed on startup

This commit fixes a bug where a setting that controls whether unexpected transaction signatures are allowed was not initialized when the channel daemon starts. If a peer sent such signatures before the channel was fully ready, the program …

use of uninitialized variableundefined behavior (invalid bool load)network-triggered code path
c09c4520by Erick Cestari+1−01 file
No security note in commit
Informational 15 AI analysisMessage 100 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

ci: fix the coverage nightly's profile handling

This commit fixes the project's internal nightly code-coverage CI workflow. It changes how test coverage files are collected, ensures the same LLVM compiler version is used to generate and merge coverage data, and uploads a Codecov-compati…

5685c9a3by cdecker+12−211 file
No security note in commit
Low 37 AI analysisMessage 78 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

schemas: make required fields match the code

This commit is a large cleanup of Core Lightning's API schemas, generated RPC bindings, and related plugin code. The stated goal is to make the documented 'required' fields match what the C code actually always produces or expects. In prac…

Large schema-only change with no accompanying security advisory or CVEOne semantic change to plugin hook response: invoice_payment hook can now reject with only failure_message and no resultMany fields change from optional to required in public RPC/protobuf interfaces
ddbd2963by daywalker90+1786−173950 files
No security note in commit
Informational 15 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

doc: document error 313 on every command which can return it

This commit only updates documentation. It adds error code 313 to the documented error lists for several Core Lightning commands (fundpsbt, utxopsbt, txprepare, multiwithdraw, and upgradewallet). The error code already existed in the code …

a34b9758by Peter Neuroth+30−86 files
No security note in commit
Low 25 AI analysisMessage 88 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

tools/build-release.sh: name the checksum file when verifying the signature

This commit fixes a release-script check that verifies the cryptographic signature on a file of checksums. Previously, the script only told GPG to verify the signature file itself. If someone replaced that signature file with an inline-sig…

Incorrect cryptographic verification logic in release toolingPotential false-positive signature verification with inline-signed .asc substitutionRelease-integrity hardening
8e495707by Peter Neuroth+5−21 file
No security note in commit
Low 42 AI analysisMessage 95 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

doc: pass the manifest explicitly to gpg --verify

This commit updates Core Lightning's release documentation to tell users and release managers to run gpg --verify with both the signature file and the manifest file named explicitly. The old one-argument form can silently succeed even if t…

Verification bypass risk in release artifact validationgpg --verify single-argument form can exit 0 without reading the intended manifestDocumentation-only hardening of release process
2dee8699by Peter Neuroth+9−62 files
Vendor flagged security relevance
Low 25 AI analysisMessage 58 · Thin
EP Elements ProjectCore Lightning BitcoinLightning Network

Cargo.lock: update dependencies

This commit is a routine update to the Rust dependency lock file (Cargo.lock), bumping many third-party libraries to newer patch or minor versions. The commit message gives no security reason for the update, and no verified references link…

Routine dependency refresh with no stated security rationaleUpdates to security-sensitive transitive crates (rustls, hyper, h2, tokio, webpki-roots) but no evidence these versions fix known vulnerabilitiesNo source-code changes or patch-specific fixes visible in the diff
c1551c55by daywalker90+298−2761 file
No security note in commit
High 80 AI analysisMessage 85 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

common: bound JSON nesting depth when parsing

This commit fixes a stack-overflow risk in Core Lightning's JSON parser. Before the fix, an attacker could send a valid JSON-RPC message containing thousands of nested brackets or braces. The parser's own helper functions used recursion fo…

Stack-overflow via deeply nested JSONRecursive JSON traversal without depth boundDenial-of-service vector in JSON-RPC input parsing
83f92e4bby Níckolas Goline+90−22 files
Vendor flagged security relevance
Informational 15 AI analysisMessage 28 · Opaque
EP Elements ProjectCore Lightning BitcoinLightning Network

common: minor typo fixes

This commit only fixes typos and comment style. It changes two C-style comments from // to /* */ and corrects a grammar error in a documentation comment ('element' to 'elements'). There are no code behavior changes, no bug fixes, and no se…

273d7f02by w3lld1+3−32 files
No security note in commit
Informational 20 AI analysisMessage 90 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

pyln-testing: truncate long testnames

This change fixes a test-infrastructure bug in Core Lightning's Python testing helpers. When running tests against a PostgreSQL database, very long test names could be silently shortened by PostgreSQL, causing different test runs or nodes …

No security-relevant signal: change is in test framework code onlyFixes a test reliability issue, not a runtime vulnerabilityNo input sanitization, authentication, cryptography, or network changes
c4fe4cbaby Peter Neuroth+59−12 files
No security note in commit
Moderate 60 AI analysisMessage 73 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: exclude immature coinbase outputs from fee rescue selection

This fix prevents Core Lightning from trying to use freshly created bitcoins (immature coinbase rewards) as emergency funds for fee-bump transactions. Such a transaction would be invalid under Bitcoin's rules and would be rejected by the n…

Consensus-invalid transaction generation preventedFee rescue / CPFP failure mode mitigatedCoinbase maturity check added to coin selection
34883ff7by cdecker+5−12 files
Vendor flagged security relevance
Moderate 59 AI analysisMessage 91 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

askrene: fix crash loading node bias with description

This commit fixes a bug in Core Lightning's askrene plugin that could prevent a node from restarting. When a saved routing layer contained a node bias with a description, the plugin accidentally freed the description's memory while using i…

Use-after-free / double-take of a tal-allocated string during plugin startupDenial-of-service-like symptom: lightningd aborts before replying to init, node cannot restartFixes publicly reported issue #9433 by endothermicdev
4681177dby Vincenzo Palazzo+2−32 files
No security note in commit
Informational 12 AI analysisMessage 91 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

tests: restart the node which owns the layer in node bias test

This commit only fixes a test case so it actually exercises the intended code path. It does not change any production code, so it cannot introduce or fix a real-world security vulnerability by itself. The test change is a reproducer for a …

0f3f67a0by Vincenzo Palazzo+3−21 file
No security note in commit
High 78 AI analysisMessage 68 · Adequate
EP Elements ProjectCore Lightning BitcoinLightning Network

dualopend: bound the feerates a peer opens at

This commit fixes a bug in Core Lightning's experimental dual-funded channel feature. When another node tried to open a channel, Core Lightning was not checking whether the proposed transaction fees were reasonable. A peer could request a …

Missing input validation on wire-parsed feerate fieldsPeer could induce signing and storage of feerate == 0RBF remote path allowed unbounded upward feerate walks
ba08356fby cdecker+140−04 files
Vendor flagged security relevance
High 72 AI analysisMessage 100 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

tests: regression coverage for out-of-range feerates

This commit adds regression tests for three related bugs where wildly wrong Bitcoin transaction feerates could enter Core Lightning. In the worst case, a malicious or broken fee source could make the node think a feerate was zero (due to a…

Integer overflow in feerate conversion (u32 wrap from 0xFFFFFFFF perkb to 0 perkw)Absurd feerate from external fee source bypassing sanity ceilingDatabase-stored out-of-range feerate causing startup abort/crash loop
65bdbc47by cdecker+137−02 files
No security note in commit
Moderate 64 AI analysisMessage 86 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

lightningd: don't assert on funding feerates read from the db

This update fixes a crash bug in Core Lightning. When the software tried to list details of a channel opening in progress, it could crash if a stored fee rate was extremely large or zero. The crash happened because the code used an interna…

Integer overflow in RBF escalation (u32 * 25 / 24) leading to assertion failureAssertion failure in read-only introspection RPC (listpeerchannels) causing crash-loop at startupDatabase value treated as invariant despite originating from external fee estimator
d67c4936by cdecker+72−227 files
Vendor flagged security relevance
Moderate 53 AI analysisMessage 86 · Strong
EP Elements ProjectCore Lightning BitcoinLightning Network

wallet: clamp absurd inflight funding feerates on upgrade

This commit fixes a bug where Core Lightning nodes could get stuck in a crash loop. If a node had previously stored an extremely high or zero fee rate for an in-progress channel funding operation (a 'splice' or dual-funded channel RBF), a …

Integer overflow in fee-rate calculation (u32 overflow when multiplying by 25/24)Assertion failure leading to daemon crash loop at startupDatabase migration clamps out-of-range stored funding feerates
f057c692by cdecker+34−01 file
Vendor flagged security relevance
Repository ledger

Explore captured commits

Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.

AI review queuedfeat: replace poetry with uv for dependency managementby Lakshya Singh · 69102c62 · Aug 11, 2025 · 4 filesMessage 85 · StrongInformational 15Details
Commit message · Lakshya Singh

feat: replace poetry with uv for dependency management

Replace poetry with uv for managing Python dependencies and running
commands across CI workflow.

- Add astral-sh/setup-uv@v5 action to install uv
- Replace all poetry run commands with uv run
- Remove poetry-specific installation steps
- Update Python setup in multiple jobs

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
Why it was queued
documentation-only discountsecond-pass: broader security terminology
AI analysis · Informational 15/100

This commit is a routine build-tooling change: it swaps the Python dependency manager used by the project's automated CI workflows from Poetry to uv. It does not modify Core Lightning's actual node code, wallet logic, network protocol handling, or any user-facing behavior. There is no security-relevant change visible in the diff.

AI review queuedfix: coincurve build issueby Lakshya Singh · 0ca833fe · Aug 11, 2025 · 2 filesMessage 90 · StrongInformational 19Details
Commit message · Lakshya Singh

fix: coincurve build issue

hatchling build requires license file but the build that coincurve
21.0.0 uses doesn’t account for that in `build_hatch.py` this was added
to prevent need of `cffi` as a runtime dependency but we can probably
live without it until it gets fixed.

change MR: https://github.com/ofek/coincurve/pull/176

reported issue: https://github.com/ofek/coincurve/issues/187

90/100 · StrongMessage clarity
✓ Descriptive subject✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
Why it was queued
second-pass: broader security terminology
AI analysis · Informational 19/100

This commit fixes a build problem by pinning a Python cryptography helper library (coincurve) to an older version. It is a build/dependency workaround, not a fix for a security vulnerability in Core Lightning itself. The change prevents installation failures caused by a packaging bug in coincurve 21.0.0, but it does not patch any runtime security flaw.

AI review queuedfuzz-tests: Make `fuzz-bolt12-invrequest-decode` roundripby Chandra Pratap · d9685a6c · Aug 6, 2025 · 1 fileMessage 91 · StrongInformational 15Details
Commit message · Chandra Pratap

fuzz-tests: Make `fuzz-bolt12-invrequest-decode` roundrip

Changelog-None: Currently, the `BOLT #12` invrequest parsing test
only tests the invrequest decode function. Add a test for the
encoding function as well by making the test roundtrip.

91/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
Why it was queued
fuzzing or regression evidenceparser or protocol pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit only changes a fuzz test file. It extends an existing test so that after decoding a BOLT 12 invoice request, it re-encodes the result and decodes it again, then checks the two decoded versions match. There is no change to production code, no bug fix, and no security patch.

AI review queuedfuzz-tests: Add coverage increasing inputs to seed corporaby Chandra Pratap · a1c554fd · Aug 6, 2025 · 107 filesMessage 83 · StrongInformational 15Details
Commit message · Chandra Pratap

fuzz-tests: Add coverage increasing inputs to seed corpora

Improvements in the fuzz-testing scheme of
`fuzz-bolt12-invrequest-decode` led to the discovery of test inputs
that result in greater in code coverage.

Add these inputs to the test's seed corpus.

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
fuzzing or regression evidenceparser or protocol pathsecond-pass: unusually broad changesecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit only adds 107 new test input files to a fuzz-test seed corpus. Fuzz-test seed corpora are collections of example inputs used to exercise code during automated testing. The commit does not change any production code, libraries, or configuration used by running Core Lightning nodes. It is purely a testing improvement and has no direct security impact on deployed software.

AI review queuedconfigure: Fix debug symbols for installed binaries on macOSby Sangbida Chaudhuri · 9e55e8dd · Aug 6, 2025 · 2 filesMessage 95 · StrongInformational 19Details
Commit message · Sangbida Chaudhuri

configure: Fix debug symbols for installed binaries on macOS

When installing core lightning on macOS I found that the debug symbols were not being preserved leading to "no debug info in
Mach-O executable". This is because the .dSYM files, which contain the debug information, is generated in the build directory and could not be found by the installed binaries.

Changes:
- Add -fno-standalone-debug flag to CDEBUGFLAGS on macOS to reduce
dependency on absolute source paths
- Modify install-program target to copy .dSYM bundles alongside
binaries for BIN_PROGRAMS, PKGLIBEXEC_PROGRAMS, and PLUGINS

Testing:
1. ./configure --reconfigure
2. make install PREFIX=/tmp/lightning-install
3. make clean (removes all .dSYM files from build directory)
4. /tmp/lightning-install/bin/lightningd --help
5. Verified stack traces now work correctly without "no debug info" errors

95/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
Why it was queued
second-pass: broader security terminology
AI analysis · Informational 19/100

This commit fixes a macOS build/install issue where debug symbol files (.dSYM bundles) were left behind in the build directory instead of being copied during installation. It adds a compiler flag to make debug info less dependent on absolute source paths and updates the install step to copy the .dSYM bundles next to the installed binaries and plugins. There is no security vulnerability here; it is a developer-experience/operability fix for debugging stack traces on macOS.