CVE-2021-31876 json
Bitcoin Core 0.12.0 through 0.21.1 does not properly implement the replacement policy specified in BIP125, which makes it easier for attack…
published 5y ago modified 4mo ago also EUVD-2021-18751
- cvss
- 6.5
- version 3.1, NVD
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 1.6%
- EPSS 1.6% chance of exploitation in 30 days, percentile 76%
- public exploits
- 0
- none known
Summary
Bitcoin Core 0.12.0 through 0.21.1 does not properly implement the replacement policy specified in BIP125, which makes it easier for attackers to trigger a loss of funds, or a denial of service attack against downstream projects such as Lightning network nodes. An unconfirmed child transaction with nSequence = 0xff_ff_ff_ff, spending an unconfirmed parent with nSequence <= 0xff_ff_ff_fd, should be replaceable because there is inherited signaling by the child transaction. However, the actual PreChecks implementation does not enforce this. Instead, mempool rejects the replacement attempt of the unconfirmed child transaction.
Is CVE-2021-31876 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerExploit prediction
1.61% chance of exploitation in the next 30 days, higher than 76% of all scored CVEs (FIRST EPSS, 2026-11-09).
CVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| NVD | 3.1 | 6.5 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L |
| NVD | 2.0 | 6.4 | AV:N/AC:L/Au:N/C:N/I:P/A:P |
Classification
- Weakness
-
- CWE-863 Incorrect Authorization
References
-
bitcoinops.org
/en/topics/replace-by-fee/
vendor-advisory
-
bitcoinops.org
/en/newsletters/2021/05/12/
vendor-advisory
-
en.bitcoin.it
/wiki/Common_Vulnerabilities_and_Exposures#CVE-2021-31876
third-party-advisory
-
github.com
/bitcoin/bitcoin
third-party-advisory
-
lists.linuxfoundation.org
/pipermail/bitcoin-dev/2021-May/018893.html
mailing-list, third-party-advisory
Sources
- CVE List CVE-2021-31876
- NVD CVE-2021-31876
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.