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

Vulnerability from cvelistv5 – Published: 2025-02-03 21:20 – Updated: 2025-02-04 19:16
VLAI?
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.
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
Assigner
References
Impacted products
Vendor Product Version
cometbft cometbft Affected: < 0.38.17
Affected: = 1.0.0
Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2025-24371",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-02-04T19:15:05.677855Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-02-04T19:16:21.174Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "cometbft",
          "vendor": "cometbft",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 0.38.17"
            },
            {
              "status": "affected",
              "version": "= 1.0.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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\u0027t check for the case where `B` first reports `latest` height `X` and immediately after height `Y`, where `X \u003e 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."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 7.1,
            "baseSeverity": "HIGH",
            "privilegesRequired": "LOW",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "vectorString": "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",
            "version": "4.0",
            "vulnAvailabilityImpact": "HIGH",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "NONE"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-703",
              "description": "CWE-703: Improper Check or Handling of Exceptional Conditions",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-02-03T21:20:56.024Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/cometbft/cometbft/security/advisories/GHSA-22qq-3xwm-r5x4",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/cometbft/cometbft/security/advisories/GHSA-22qq-3xwm-r5x4"
        },
        {
          "name": "https://github.com/cometbft/cometbft/releases/tag/v0.38.17",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/cometbft/cometbft/releases/tag/v0.38.17"
        },
        {
          "name": "https://github.com/cometbft/cometbft/releases/tag/v1.0.1",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/cometbft/cometbft/releases/tag/v1.0.1"
        }
      ],
      "source": {
        "advisory": "GHSA-22qq-3xwm-r5x4",
        "discovery": "UNKNOWN"
      },
      "title": "Malicious peer can make node stuck in blocksync in github.com/cometbft/cometbft"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2025-24371",
    "datePublished": "2025-02-03T21:20:56.024Z",
    "dateReserved": "2025-01-20T15:18:26.991Z",
    "dateUpdated": "2025-02-04T19:16:21.174Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2025-24371\",\"sourceIdentifier\":\"security-advisories@github.com\",\"published\":\"2025-02-03T22:15:28.460\",\"lastModified\":\"2025-02-03T22:15:28.460\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"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\u0027t check for the case where `B` first reports `latest` height `X` and immediately after height `Y`, where `X \u003e 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.\"},{\"lang\":\"es\",\"value\":\"CometBFT es un motor de replicaci\u00f3n de m\u00e1quina de estados determinista, tolerante a fallas bizantinas y distribuido. En el protocolo `blocksync`, los pares env\u00edan sus alturas `base` y `latest` cuando se conectan a un nuevo nodo (`A`), que se sincroniza con la punta de una red. `base` act\u00faa como una base inferior e informa a `A` que el par solo tiene bloques que comienzan con la altura `base`. La altura `latest` informa a `A` sobre el \u00faltimo bloque en una red. Normalmente, los nodos solo informar\u00edan alturas crecientes. Si `B` no proporciona el \u00faltimo bloque, `B` se elimina y la altura `latest` (altura objetivo) se recalcula en funci\u00f3n de las alturas `latest` de otros nodos. Sin embargo, el c\u00f3digo existente no verifica el caso en el que `B` primero informa la `latest` altura `X` e inmediatamente despu\u00e9s la altura `Y`, donde `X \u0026gt; Y`. `A` intentar\u00e1 alcanzar el 2000 indefinidamente. Esta condici\u00f3n requiere la introducci\u00f3n de c\u00f3digo malicioso en el nodo completo que primero informa una altura `latest` inexistente, luego informa una altura `latest` menor y nodos que se sincronizan mediante el protocolo `blocksync`. Este problema se ha corregido en las versiones 1.0.1 y 0.38.17 y se recomienda a todos los usuarios que actualicen. Los operadores pueden intentar prohibir el acceso de pares maliciosos a la red como workaround.\"}],\"metrics\":{\"cvssMetricV40\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"4.0\",\"vectorString\":\"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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X\",\"baseScore\":7.1,\"baseSeverity\":\"HIGH\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"attackRequirements\":\"NONE\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"vulnConfidentialityImpact\":\"NONE\",\"vulnIntegrityImpact\":\"NONE\",\"vulnAvailabilityImpact\":\"HIGH\",\"subConfidentialityImpact\":\"NONE\",\"subIntegrityImpact\":\"NONE\",\"subAvailabilityImpact\":\"NONE\",\"exploitMaturity\":\"NOT_DEFINED\",\"confidentialityRequirement\":\"NOT_DEFINED\",\"integrityRequirement\":\"NOT_DEFINED\",\"availabilityRequirement\":\"NOT_DEFINED\",\"modifiedAttackVector\":\"NOT_DEFINED\",\"modifiedAttackComplexity\":\"NOT_DEFINED\",\"modifiedAttackRequirements\":\"NOT_DEFINED\",\"modifiedPrivilegesRequired\":\"NOT_DEFINED\",\"modifiedUserInteraction\":\"NOT_DEFINED\",\"modifiedVulnConfidentialityImpact\":\"NOT_DEFINED\",\"modifiedVulnIntegrityImpact\":\"NOT_DEFINED\",\"modifiedVulnAvailabilityImpact\":\"NOT_DEFINED\",\"modifiedSubConfidentialityImpact\":\"NOT_DEFINED\",\"modifiedSubIntegrityImpact\":\"NOT_DEFINED\",\"modifiedSubAvailabilityImpact\":\"NOT_DEFINED\",\"Safety\":\"NOT_DEFINED\",\"Automatable\":\"NOT_DEFINED\",\"Recovery\":\"NOT_DEFINED\",\"valueDensity\":\"NOT_DEFINED\",\"vulnerabilityResponseEffort\":\"NOT_DEFINED\",\"providerUrgency\":\"NOT_DEFINED\"}}]},\"weaknesses\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-703\"}]}],\"references\":[{\"url\":\"https://github.com/cometbft/cometbft/releases/tag/v0.38.17\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/cometbft/cometbft/releases/tag/v1.0.1\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/cometbft/cometbft/security/advisories/GHSA-22qq-3xwm-r5x4\",\"source\":\"security-advisories@github.com\"}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2025-24371\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2025-02-04T19:15:05.677855Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2025-02-04T19:16:10.482Z\"}}], \"cna\": {\"title\": \"Malicious peer can make node stuck in blocksync in github.com/cometbft/cometbft\", \"source\": {\"advisory\": \"GHSA-22qq-3xwm-r5x4\", \"discovery\": \"UNKNOWN\"}, \"metrics\": [{\"cvssV4_0\": {\"version\": \"4.0\", \"baseScore\": 7.1, \"attackVector\": \"NETWORK\", \"baseSeverity\": \"HIGH\", \"vectorString\": \"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\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"LOW\", \"attackRequirements\": \"NONE\", \"privilegesRequired\": \"LOW\", \"subIntegrityImpact\": \"NONE\", \"vulnIntegrityImpact\": \"NONE\", \"subAvailabilityImpact\": \"NONE\", \"vulnAvailabilityImpact\": \"HIGH\", \"subConfidentialityImpact\": \"NONE\", \"vulnConfidentialityImpact\": \"NONE\"}}], \"affected\": [{\"vendor\": \"cometbft\", \"product\": \"cometbft\", \"versions\": [{\"status\": \"affected\", \"version\": \"\u003c 0.38.17\"}, {\"status\": \"affected\", \"version\": \"= 1.0.0\"}]}], \"references\": [{\"url\": \"https://github.com/cometbft/cometbft/security/advisories/GHSA-22qq-3xwm-r5x4\", \"name\": \"https://github.com/cometbft/cometbft/security/advisories/GHSA-22qq-3xwm-r5x4\", \"tags\": [\"x_refsource_CONFIRM\"]}, {\"url\": \"https://github.com/cometbft/cometbft/releases/tag/v0.38.17\", \"name\": \"https://github.com/cometbft/cometbft/releases/tag/v0.38.17\", \"tags\": [\"x_refsource_MISC\"]}, {\"url\": \"https://github.com/cometbft/cometbft/releases/tag/v1.0.1\", \"name\": \"https://github.com/cometbft/cometbft/releases/tag/v1.0.1\", \"tags\": [\"x_refsource_MISC\"]}], \"descriptions\": [{\"lang\": \"en\", \"value\": \"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\u0027t check for the case where `B` first reports `latest` height `X` and immediately after height `Y`, where `X \u003e 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.\"}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-703\", \"description\": \"CWE-703: Improper Check or Handling of Exceptional Conditions\"}]}], \"providerMetadata\": {\"orgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"shortName\": \"GitHub_M\", \"dateUpdated\": \"2025-02-03T21:20:56.024Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2025-24371\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2025-02-04T19:16:21.174Z\", \"dateReserved\": \"2025-01-20T15:18:26.991Z\", \"assignerOrgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"datePublished\": \"2025-02-03T21:20:56.024Z\", \"assignerShortName\": \"GitHub_M\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.1"
    }
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.