How severe is CVE-2023-34451?

CVE-2023-34451 has a CVSS score of 8.2/10, rated HIGH. Immediate patching is strongly recommended.

Which packages are affected by CVE-2023-34451?

CVE-2023-34451 affects the following packages: github.com/cometbft/cometbft (Go), github.com/cometbft/cometbft (Go). Ecosystems affected: Go.

How do I fix CVE-2023-34451?

Update github.com/cometbft/cometbft to 0.34.29 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2023-34451 is resolved across your whole dependency graph.

How do I detect CVE-2023-34451 in my Go dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/cometbft/cometbft, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate CVE-2023-34451 if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Is CVE-2023-34451 actively exploited in the wild?

Yes. There are 2 known exploit references for CVE-2023-34451, including 2 in-the-wild exploitations observed on GitHub and other sources. Treat this as actively exploitable and prioritize patching immediately. All exploit code should only be run in an isolated sandbox environment for research or authorized testing — never against production systems without explicit written authorization.

What is the EPSS score for CVE-2023-34451?

CVE-2023-34451 has an EPSS (Exploit Prediction Scoring System) score of 0.9%, placing it in the 60th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is CVE-2023-34451?

CVE-2023-34451 is classified as CWE-401 (CWE-401). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was CVE-2023-34451 published, and has it been updated?

CVE-2023-34451 was published on July 3, 2023 and was last updated on October 28, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐹

🐹 Go

Not in CISA KEV

HIGH severity

CVE-2023-34451 — cometbft

HIGHFix: cometbft/cometbft#890

CVE-2023-34451 is a high-severity (CVSS 8.2) CWE-401 vulnerability in github.com/cometbft/cometbft. 2 public exploit or proof-of-concept references are indexed, so weaponization risk is real. A fix is available for github.com/cometbft/cometbft — see the affected versions and patch details below.

CometBFT may duplicate transactions in the mempool's data structures

Also known asGHSA-w24w-wp77-qffmGO-2023-1883

Published

Jul 3, 2023

Updated

Oct 28, 2026

Affected

2 pkgs

Patched

2 / 2

Exploits

2 known

Exploitation data as of Nov 4, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for CVE-2023-34451.

EPSS Exploitation Probability

via FIRST.org ↗

0.9%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs60th percentile — riskier than 60% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

2 pkgs affected

🐹github.com/cometbft/cometbft🐹github.com/cometbft/cometbft

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Impact

The mempool maintains two data structures to keep track of outstanding transactions: a list and a map. These two data structures are supposed to be in sync all the time in the sense that the map tracks the index (if any) of the transaction in the list.

Unfortunately, it is possible to have them out of sync. When this happens, the list may contain several copies of the same transaction. Because the map tracks a single index, it is then no longer possible to remove all the copies of the transaction from the list. This happens even if the duplicated transaction is later committed in a block. The only way to remove the transaction is by restarting the node.

These are the steps to cause the above duplication problem. Everything should happen within one height, that is no FinalizeBlock or BeginBlock ABCI calls should happen while these steps are reproduced:

send transaction tx1 to the target full node via RPC
send N more different transactions to the target full node, where N should be higher than the node's configured value for cache_size in config.toml
send transaction tx1 again to the target full node

One of the copies of tx1 is now stuck in the mempool's data structures. Effectively causing a memory leak, and having that node gossiping that transaction to its peers forever.

The above problem can be repeated on and on until a sizable number of transactions are stuck in the mempool, in order to try to bring down the target node.

This problem is present in releases: v0.37.0, and v0.37.1, as well as in v0.34.28, and all previous releases of the CometBFT repo. It will be fixed in releases v0.34.29 and v0.37.2.

Patches

The PR containing the fix is here.

Workarounds

Increasing the value of cache_size in config.toml makes it very difficult to effectively attack a full node.
Not exposing the transaction submission RPC's would mitigate the probability of a successful attack, as the attacker would then have to create a modified (byzantine) full node to be able to perform the attack via p2p.

References

PR that introduced the map to track transactions in the mempool.
PR containing the fix.

Affected Packages

2 total 2 fixed

Ecosystem	Package	Vulnerable range	Fix
🐹Go	`github.com/cometbft/cometbft`	all versions	0.34.29`go get github.com/cometbft/cometbft@v0.34.29`
🐹Go	`github.com/cometbft/cometbft`	≥ 0.37.0&&< 0.37.2	0.37.2`go get github.com/cometbft/cometbft@v0.37.2`

Affected Products

1 product · 2 configurations

Application

cometbftcometbft

≥ 0.37.0 && < 0.37.2

range

Exploits & PoCs

Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.

CometBFT is a Byzantine Fault Tolerant (BFT) middleware that takes a sta…

github.comNVDJul 2023

Report on github.com

github.comNVDJul 2023

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/cometbft/cometbft, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/cometbft/cometbft to 0.34.29 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2023-34451 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

### Impact The mempool maintains two data structures to keep track of outstanding transactions: a list and a map. These two data structures are supposed to be in sync all the time in the sense that the map tracks the index (if any) of the transaction in the list. Unfortunately, it is possible to have them out of sync. When this happens, the list may contain several copies of the same transaction. Because the map tracks a single index, it is then no longer possible to remove all the copies of the transaction from the list. This happens even if the duplicated transaction is later committed i