Vulnerability-Lookup - Search a vulnerability

CVE-2023-34451 (GCVE-0-2023-34451)

Vulnerability from cvelistv5

Published

2023-07-03 16:35

Modified

2024-11-22 16:43

Severity ?

8.2 (High) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H

CWE

CWE-401 - Missing Release of Memory after Effective Lifetime

Summary

CometBFT is a Byzantine Fault Tolerant (BFT) middleware that takes a state transition machine and replicates it on many machines. 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. In `v0.37.0`, and `v0.37.1`, as well as in `v0.34.28`, and all previous releases of the CometBFT repo2, 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. 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. The problem is fixed in releases `v0.34.29` and `v0.37.2`. Some workarounds are available. 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

►

URL

	Vendor	Product	Version
	cometbft	cometbft	Version: < 0.34.29 Version: >= 0.37.0, < 0.37.2

CVE-2025-24371 (GCVE-0-2025-24371)

Vulnerability from cvelistv5

Published

2025-02-03 21:20

Modified

2025-02-04 19:16

Severity ?

7.1 (High) - CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

CWE

CWE-703 - Improper Check or Handling of Exceptional Conditions

Summary

CometBFT is a distributed, Byzantine fault-tolerant, deterministic state machine replication engine. In the `blocksync` protocol peers send their `base` and `latest` heights when they connect to a new node (`A`), which is syncing to the tip of a network. `base` acts as a lower ground and informs `A` that the peer only has blocks starting from height `base`. `latest` height informs `A` about the latest block in a network. Normally, nodes would only report increasing heights. If `B` fails to provide the latest block, `B` is removed and the `latest` height (target height) is recalculated based on other nodes `latest` heights. The existing code however doesn't check for the case where `B` first reports `latest` height `X` and immediately after height `Y`, where `X > Y`. `A` will be trying to catch up to 2000 indefinitely. This condition requires the introduction of malicious code in the full node first reporting some non-existing `latest` height, then reporting lower `latest` height and nodes which are syncing using `blocksync` protocol. This issue has been patched in versions 1.0.1 and 0.38.17 and all users are advised to upgrade. Operators may attempt to ban malicious peers from the network as a workaround.

References

►

URL

	Vendor	Product	Version
	cometbft	cometbft	Version: < 0.38.17 Version: = 1.0.0

CVE-2023-34450 (GCVE-0-2023-34450)

Vulnerability from cvelistv5

Published

2023-07-03 16:36

Modified

2024-10-29 13:49

Severity ?

3.7 (Low) - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L

CWE

CWE-401 - Missing Release of Memory after Effective Lifetime
CWE-770 - Allocation of Resources Without Limits or Throttling

Summary

CometBFT is a Byzantine Fault Tolerant (BFT) middleware that takes a state transition machine and replicates it on many machines. An internal modification made in versions 0.34.28 and 0.37.1 to the way struct `PeerState` is serialized to JSON introduced a deadlock when new function MarshallJSON is called. This function can be called from two places. The first is via logs, setting the `consensus` logging module to "debug" level (should not happen in production), and setting the log output format to JSON. The second is via RPC `dump_consensus_state`. Case 1, which should not be hit in production, will eventually hit the deadlock in most goroutines, effectively halting the node. In case 2, only the data structures related to the first peer will be deadlocked, together with the thread(s) dealing with the RPC request(s). This means that only one of the channels of communication to the node's peers will be blocked. Eventually the peer will timeout and excluded from the list (typically after 2 minutes). The goroutines involved in the deadlock will not be garbage collected, but they will not interfere with the system after the peer is excluded. The theoretical worst case for case 2, is a network with only two validator nodes. In this case, each of the nodes only has one `PeerState` struct. If `dump_consensus_state` is called in either node (or both), the chain will halt until the peer connections time out, after which the nodes will reconnect (with different `PeerState` structs) and the chain will progress again. Then, the same process can be repeated. As the number of nodes in a network increases, and thus, the number of peer struct each node maintains, the possibility of reproducing the perturbation visible with two nodes decreases. Only the first `PeerState` struct will deadlock, and not the others (RPC `dump_consensus_state` accesses them in a for loop, so the deadlock at the first iteration causes the rest of the iterations of that "for" loop to never be reached). This regression was fixed in versions 0.34.29 and 0.37.2. Some workarounds are available. For case 1 (hitting the deadlock via logs), either don't set the log output to "json", leave at "plain", or don't set the consensus logging module to "debug", leave it at "info" or higher. For case 2 (hitting the deadlock via RPC `dump_consensus_state`), do not expose `dump_consensus_state` RPC endpoint to the public internet (e.g., via rules in one's nginx setup).

References

►

URL

	Vendor	Product	Version
	cometbft	cometbft	Version: = 0.34.28 Version: = 0.37.1

Vulnerability from fkie_nvd

Published

2023-07-03 17:15

Modified

2024-11-21 08:07

Severity ?

8.2 (High) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H
8.2 (High) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H

Summary

CometBFT is a Byzantine Fault Tolerant (BFT) middleware that takes a state transition machine and replicates it on many machines. 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. In `v0.37.0`, and `v0.37.1`, as well as in `v0.34.28`, and all previous releases of the CometBFT repo2, 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. 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. The problem is fixed in releases `v0.34.29` and `v0.37.2`. Some workarounds are available. 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

URL	Tags
security-advisories@github.com	https://github.com/cometbft/cometbft/pull/890	Exploit, Issue Tracking, Patch
security-advisories@github.com	https://github.com/cometbft/cometbft/security/advisories/GHSA-w24w-wp77-qffm	Exploit, Mitigation, Vendor Advisory
security-advisories@github.com	https://github.com/tendermint/tendermint/pull/2778	Issue Tracking, Patch
af854a3a-2127-422b-91ae-364da2661108	https://github.com/cometbft/cometbft/pull/890	Exploit, Issue Tracking, Patch
af854a3a-2127-422b-91ae-364da2661108	https://github.com/cometbft/cometbft/security/advisories/GHSA-w24w-wp77-qffm	Exploit, Mitigation, Vendor Advisory
af854a3a-2127-422b-91ae-364da2661108	https://github.com/tendermint/tendermint/pull/2778	Issue Tracking, Patch

Impacted products

	Vendor	Product	Version
	cometbft	cometbft	*
	cometbft	cometbft	*

JSON

To clipboard

{
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:a:cometbft:cometbft:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "2B0D29CE-1BCD-4051-80E5-21B4A169379D",
              "versionEndExcluding": "0.34.29",
              "versionStartIncluding": "0.34.28",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:a:cometbft:cometbft:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "291321F2-A061-4495-9585-5BBAAB9BCCCE",
              "versionEndExcluding": "0.37.2",
              "versionStartIncluding": "0.37.0",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "CometBFT is a Byzantine Fault Tolerant (BFT) middleware that takes a state transition machine and replicates it on many machines. The mempool maintains two data structures to keep track of outstanding transactions: a list and a map.\nThese 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. In `v0.37.0`, and `v0.37.1`, as well as in `v0.34.28`, and all previous releases of the CometBFT repo2, 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.\n\nThe 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. The problem is fixed in releases `v0.34.29` and `v0.37.2`. Some workarounds are available. 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\u0027s 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."
    }
  ],
  "id": "CVE-2023-34451",
  "lastModified": "2024-11-21T08:07:16.957",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "HIGH",
          "baseScore": 8.2,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "NONE",
          "integrityImpact": "LOW",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 3.9,
        "impactScore": 4.2,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      },
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "HIGH",
          "baseScore": 8.2,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "NONE",
          "integrityImpact": "LOW",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 3.9,
        "impactScore": 4.2,
        "source": "nvd@nist.gov",
        "type": "Primary"
      }
    ]
  },
  "published": "2023-07-03T17:15:09.240",
  "references": [
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Exploit",
        "Issue Tracking",
        "Patch"
      ],
      "url": "https://github.com/cometbft/cometbft/pull/890"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Exploit",
        "Mitigation",
        "Vendor Advisory"
      ],
      "url": "https://github.com/cometbft/cometbft/security/advisories/GHSA-w24w-wp77-qffm"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Issue Tracking",
        "Patch"
      ],
      "url": "https://github.com/tendermint/tendermint/pull/2778"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Exploit",
        "Issue Tracking",
        "Patch"
      ],
      "url": "https://github.com/cometbft/cometbft/pull/890"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Exploit",
        "Mitigation",
        "Vendor Advisory"
      ],
      "url": "https://github.com/cometbft/cometbft/security/advisories/GHSA-w24w-wp77-qffm"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Issue Tracking",
        "Patch"
      ],
      "url": "https://github.com/tendermint/tendermint/pull/2778"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Modified",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-401"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    },
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-401"
        }
      ],
      "source": "nvd@nist.gov",
      "type": "Primary"
    }
  ]
}

Vulnerability from fkie_nvd

Published

2023-07-03 17:15

Modified

2024-11-21 08:07

Severity ?

3.7 (Low) - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L
5.3 (Medium) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Summary

CometBFT is a Byzantine Fault Tolerant (BFT) middleware that takes a state transition machine and replicates it on many machines. An internal modification made in versions 0.34.28 and 0.37.1 to the way struct `PeerState` is serialized to JSON introduced a deadlock when new function MarshallJSON is called. This function can be called from two places. The first is via logs, setting the `consensus` logging module to "debug" level (should not happen in production), and setting the log output format to JSON. The second is via RPC `dump_consensus_state`. Case 1, which should not be hit in production, will eventually hit the deadlock in most goroutines, effectively halting the node. In case 2, only the data structures related to the first peer will be deadlocked, together with the thread(s) dealing with the RPC request(s). This means that only one of the channels of communication to the node's peers will be blocked. Eventually the peer will timeout and excluded from the list (typically after 2 minutes). The goroutines involved in the deadlock will not be garbage collected, but they will not interfere with the system after the peer is excluded. The theoretical worst case for case 2, is a network with only two validator nodes. In this case, each of the nodes only has one `PeerState` struct. If `dump_consensus_state` is called in either node (or both), the chain will halt until the peer connections time out, after which the nodes will reconnect (with different `PeerState` structs) and the chain will progress again. Then, the same process can be repeated. As the number of nodes in a network increases, and thus, the number of peer struct each node maintains, the possibility of reproducing the perturbation visible with two nodes decreases. Only the first `PeerState` struct will deadlock, and not the others (RPC `dump_consensus_state` accesses them in a for loop, so the deadlock at the first iteration causes the rest of the iterations of that "for" loop to never be reached). This regression was fixed in versions 0.34.29 and 0.37.2. Some workarounds are available. For case 1 (hitting the deadlock via logs), either don't set the log output to "json", leave at "plain", or don't set the consensus logging module to "debug", leave it at "info" or higher. For case 2 (hitting the deadlock via RPC `dump_consensus_state`), do not expose `dump_consensus_state` RPC endpoint to the public internet (e.g., via rules in one's nginx setup).

References

URL	Tags
security-advisories@github.com	https://github.com/cometbft/cometbft/pull/524	Exploit, Patch
security-advisories@github.com	https://github.com/cometbft/cometbft/pull/863	Patch
security-advisories@github.com	https://github.com/cometbft/cometbft/pull/865	Patch
security-advisories@github.com	https://github.com/cometbft/cometbft/security/advisories/GHSA-mvj3-qrqh-cjvr	Exploit, Issue Tracking, Patch
af854a3a-2127-422b-91ae-364da2661108	https://github.com/cometbft/cometbft/pull/524	Exploit, Patch
af854a3a-2127-422b-91ae-364da2661108	https://github.com/cometbft/cometbft/pull/863	Patch
af854a3a-2127-422b-91ae-364da2661108	https://github.com/cometbft/cometbft/pull/865	Patch
af854a3a-2127-422b-91ae-364da2661108	https://github.com/cometbft/cometbft/security/advisories/GHSA-mvj3-qrqh-cjvr	Exploit, Issue Tracking, Patch

Impacted products

	Vendor	Product	Version
	cometbft	cometbft	*
	cometbft	cometbft	*

JSON

To clipboard

{
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:a:cometbft:cometbft:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "2B0D29CE-1BCD-4051-80E5-21B4A169379D",
              "versionEndExcluding": "0.34.29",
              "versionStartIncluding": "0.34.28",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:a:cometbft:cometbft:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "4BA387F2-81AB-44AD-BF16-87BAD58322B2",
              "versionEndExcluding": "0.37.2",
              "versionStartIncluding": "0.37.1",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "CometBFT is a Byzantine Fault Tolerant (BFT) middleware that takes a state transition machine and replicates it on many machines. An internal modification made in versions 0.34.28 and 0.37.1 to the way struct `PeerState` is serialized to JSON introduced a deadlock when new function MarshallJSON is called. This function can be called from two places. The first is via logs, setting the `consensus` logging module to \"debug\" level (should not happen in production), and setting the log output format to JSON. The second is via RPC `dump_consensus_state`.\n\nCase 1, which should not be hit in production, will eventually hit the deadlock in most goroutines, effectively halting the node.\n\nIn case 2, only the data structures related to the first peer will be deadlocked, together with the thread(s) dealing with the RPC request(s). This means that only one of the channels of communication to the node\u0027s peers will be blocked. Eventually the peer will timeout and excluded from the list (typically after 2 minutes). The goroutines involved in the deadlock will not be garbage collected, but they will not interfere with the system after the peer is excluded.\n\nThe theoretical worst case for case 2, is a network with only two validator nodes. In this case, each of the nodes only has one `PeerState` struct. If `dump_consensus_state` is called in either node (or both), the chain will halt until the peer connections time out, after which the nodes will reconnect (with different `PeerState` structs) and the chain will progress again. Then, the same process can be repeated.\n\nAs the number of nodes in a network increases, and thus, the number of peer struct each node maintains, the possibility of reproducing the perturbation visible with two nodes decreases. Only the first `PeerState` struct will deadlock, and not the others (RPC `dump_consensus_state` accesses them in a for loop, so the deadlock at the first iteration causes the rest of the iterations of that \"for\" loop to never be reached).\n\nThis regression was fixed in versions 0.34.29 and 0.37.2. Some workarounds are available. For case 1 (hitting the deadlock via logs), either don\u0027t set the log output to \"json\", leave at \"plain\", or don\u0027t set the consensus logging module to \"debug\", leave it at \"info\" or higher. For case 2 (hitting the deadlock via RPC `dump_consensus_state`), do not expose `dump_consensus_state` RPC endpoint to the public internet (e.g., via rules in one\u0027s nginx setup)."
    }
  ],
  "id": "CVE-2023-34450",
  "lastModified": "2024-11-21T08:07:16.810",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "HIGH",
          "attackVector": "NETWORK",
          "availabilityImpact": "LOW",
          "baseScore": 3.7,
          "baseSeverity": "LOW",
          "confidentialityImpact": "NONE",
          "integrityImpact": "NONE",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
          "version": "3.1"
        },
        "exploitabilityScore": 2.2,
        "impactScore": 1.4,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      },
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "LOW",
          "baseScore": 5.3,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "NONE",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
          "version": "3.1"
        },
        "exploitabilityScore": 3.9,
        "impactScore": 1.4,
        "source": "nvd@nist.gov",
        "type": "Primary"
      }
    ]
  },
  "published": "2023-07-03T17:15:09.147",
  "references": [
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Exploit",
        "Patch"
      ],
      "url": "https://github.com/cometbft/cometbft/pull/524"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Patch"
      ],
      "url": "https://github.com/cometbft/cometbft/pull/863"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Patch"
      ],
      "url": "https://github.com/cometbft/cometbft/pull/865"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Exploit",
        "Issue Tracking",
        "Patch"
      ],
      "url": "https://github.com/cometbft/cometbft/security/advisories/GHSA-mvj3-qrqh-cjvr"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Exploit",
        "Patch"
      ],
      "url": "https://github.com/cometbft/cometbft/pull/524"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://github.com/cometbft/cometbft/pull/863"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch"
      ],
      "url": "https://github.com/cometbft/cometbft/pull/865"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Exploit",
        "Issue Tracking",
        "Patch"
      ],
      "url": "https://github.com/cometbft/cometbft/security/advisories/GHSA-mvj3-qrqh-cjvr"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Modified",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-401"
        },
        {
          "lang": "en",
          "value": "CWE-770"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Primary"
    }
  ]
}

Vulnerabilites related to cometbft - cometbft

CVE-2023-34451 (GCVE-0-2023-34451)

Vulnerability from cvelistv5

CVE-2025-24371 (GCVE-0-2025-24371)

Vulnerability from cvelistv5

CVE-2023-34450 (GCVE-0-2023-34450)

Vulnerability from cvelistv5

Vulnerability from fkie_nvd

Vulnerability from fkie_nvd