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
Impacted products
Vendor Product Version
cometbft cometbft Version: = 0.34.28
Version: = 0.37.1
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-02T16:10:06.972Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "name": "https://github.com/cometbft/cometbft/security/advisories/GHSA-mvj3-qrqh-cjvr",
            "tags": [
              "x_refsource_CONFIRM",
              "x_transferred"
            ],
            "url": "https://github.com/cometbft/cometbft/security/advisories/GHSA-mvj3-qrqh-cjvr"
          },
          {
            "name": "https://github.com/cometbft/cometbft/pull/524",
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/cometbft/cometbft/pull/524"
          },
          {
            "name": "https://github.com/cometbft/cometbft/pull/863",
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/cometbft/cometbft/pull/863"
          },
          {
            "name": "https://github.com/cometbft/cometbft/pull/865",
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/cometbft/cometbft/pull/865"
          }
        ],
        "title": "CVE Program Container"
      },
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2023-34450",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-10-28T19:22:20.977405Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-10-29T13:49:01.399Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "cometbft",
          "vendor": "cometbft",
          "versions": [
            {
              "status": "affected",
              "version": "= 0.34.28"
            },
            {
              "status": "affected",
              "version": "= 0.37.1"
            }
          ]
        }
      ],
      "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)."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "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"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-401",
              "description": "CWE-401: Missing Release of Memory after Effective Lifetime",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770: Allocation of Resources Without Limits or Throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2023-07-03T16:36:34.419Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/cometbft/cometbft/security/advisories/GHSA-mvj3-qrqh-cjvr",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/cometbft/cometbft/security/advisories/GHSA-mvj3-qrqh-cjvr"
        },
        {
          "name": "https://github.com/cometbft/cometbft/pull/524",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/cometbft/cometbft/pull/524"
        },
        {
          "name": "https://github.com/cometbft/cometbft/pull/863",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/cometbft/cometbft/pull/863"
        },
        {
          "name": "https://github.com/cometbft/cometbft/pull/865",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/cometbft/cometbft/pull/865"
        }
      ],
      "source": {
        "advisory": "GHSA-mvj3-qrqh-cjvr",
        "discovery": "UNKNOWN"
      },
      "title": "CometBFT PeerState JSON serialization deadlock"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2023-34450",
    "datePublished": "2023-07-03T16:36:34.419Z",
    "dateReserved": "2023-06-06T16:16:53.558Z",
    "dateUpdated": "2024-10-29T13:49:01.399Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2023-34450\",\"sourceIdentifier\":\"security-advisories@github.com\",\"published\":\"2023-07-03T17:15:09.147\",\"lastModified\":\"2024-11-21T08:07:16.810\",\"vulnStatus\":\"Modified\",\"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).\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L\",\"baseScore\":3.7,\"baseSeverity\":\"LOW\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"HIGH\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"LOW\"},\"exploitabilityScore\":2.2,\"impactScore\":1.4},{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L\",\"baseScore\":5.3,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"LOW\"},\"exploitabilityScore\":3.9,\"impactScore\":1.4}]},\"weaknesses\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-401\"},{\"lang\":\"en\",\"value\":\"CWE-770\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:a:cometbft:cometbft:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"0.34.28\",\"versionEndExcluding\":\"0.34.29\",\"matchCriteriaId\":\"2B0D29CE-1BCD-4051-80E5-21B4A169379D\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:a:cometbft:cometbft:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"0.37.1\",\"versionEndExcluding\":\"0.37.2\",\"matchCriteriaId\":\"4BA387F2-81AB-44AD-BF16-87BAD58322B2\"}]}]}],\"references\":[{\"url\":\"https://github.com/cometbft/cometbft/pull/524\",\"source\":\"security-advisories@github.com\",\"tags\":[\"Exploit\",\"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\":[\"Patch\"]},{\"url\":\"https://github.com/cometbft/cometbft/security/advisories/GHSA-mvj3-qrqh-cjvr\",\"source\":\"security-advisories@github.com\",\"tags\":[\"Exploit\",\"Issue Tracking\",\"Patch\"]},{\"url\":\"https://github.com/cometbft/cometbft/pull/524\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Exploit\",\"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\":[\"Patch\"]},{\"url\":\"https://github.com/cometbft/cometbft/security/advisories/GHSA-mvj3-qrqh-cjvr\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Exploit\",\"Issue Tracking\",\"Patch\"]}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CVE Program Container\", \"references\": [{\"url\": \"https://github.com/cometbft/cometbft/security/advisories/GHSA-mvj3-qrqh-cjvr\", \"name\": \"https://github.com/cometbft/cometbft/security/advisories/GHSA-mvj3-qrqh-cjvr\", \"tags\": [\"x_refsource_CONFIRM\", \"x_transferred\"]}, {\"url\": \"https://github.com/cometbft/cometbft/pull/524\", \"name\": \"https://github.com/cometbft/cometbft/pull/524\", \"tags\": [\"x_refsource_MISC\", \"x_transferred\"]}, {\"url\": \"https://github.com/cometbft/cometbft/pull/863\", \"name\": \"https://github.com/cometbft/cometbft/pull/863\", \"tags\": [\"x_refsource_MISC\", \"x_transferred\"]}, {\"url\": \"https://github.com/cometbft/cometbft/pull/865\", \"name\": \"https://github.com/cometbft/cometbft/pull/865\", \"tags\": [\"x_refsource_MISC\", \"x_transferred\"]}], \"providerMetadata\": {\"orgId\": \"af854a3a-2127-422b-91ae-364da2661108\", \"shortName\": \"CVE\", \"dateUpdated\": \"2024-08-02T16:10:06.972Z\"}}, {\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2023-34450\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2024-10-28T19:22:20.977405Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2024-10-29T13:47:37.838Z\"}}], \"cna\": {\"title\": \"CometBFT PeerState JSON serialization deadlock\", \"source\": {\"advisory\": \"GHSA-mvj3-qrqh-cjvr\", \"discovery\": \"UNKNOWN\"}, \"metrics\": [{\"cvssV3_1\": {\"scope\": \"UNCHANGED\", \"version\": \"3.1\", \"baseScore\": 3.7, \"attackVector\": \"NETWORK\", \"baseSeverity\": \"LOW\", \"vectorString\": \"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L\", \"integrityImpact\": \"NONE\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"HIGH\", \"availabilityImpact\": \"LOW\", \"privilegesRequired\": \"NONE\", \"confidentialityImpact\": \"NONE\"}}], \"affected\": [{\"vendor\": \"cometbft\", \"product\": \"cometbft\", \"versions\": [{\"status\": \"affected\", \"version\": \"= 0.34.28\"}, {\"status\": \"affected\", \"version\": \"= 0.37.1\"}]}], \"references\": [{\"url\": \"https://github.com/cometbft/cometbft/security/advisories/GHSA-mvj3-qrqh-cjvr\", \"name\": \"https://github.com/cometbft/cometbft/security/advisories/GHSA-mvj3-qrqh-cjvr\", \"tags\": [\"x_refsource_CONFIRM\"]}, {\"url\": \"https://github.com/cometbft/cometbft/pull/524\", \"name\": \"https://github.com/cometbft/cometbft/pull/524\", \"tags\": [\"x_refsource_MISC\"]}, {\"url\": \"https://github.com/cometbft/cometbft/pull/863\", \"name\": \"https://github.com/cometbft/cometbft/pull/863\", \"tags\": [\"x_refsource_MISC\"]}, {\"url\": \"https://github.com/cometbft/cometbft/pull/865\", \"name\": \"https://github.com/cometbft/cometbft/pull/865\", \"tags\": [\"x_refsource_MISC\"]}], \"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).\"}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-401\", \"description\": \"CWE-401: Missing Release of Memory after Effective Lifetime\"}]}, {\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-770\", \"description\": \"CWE-770: Allocation of Resources Without Limits or Throttling\"}]}], \"providerMetadata\": {\"orgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"shortName\": \"GitHub_M\", \"dateUpdated\": \"2023-07-03T16:36:34.419Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2023-34450\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2024-10-29T13:49:01.399Z\", \"dateReserved\": \"2023-06-06T16:16:53.558Z\", \"assignerOrgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"datePublished\": \"2023-07-03T16:36:34.419Z\", \"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 seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.