CVE-2023-43635 (GCVE-0-2023-43635)
Vulnerability from cvelistv5
Published
2023-09-20 14:58
Modified
2024-09-25 14:37
CWE
  • CWE-522 - Insufficiently Protected Credentials
  • CWE-328 - Use of Weak Hash
Summary
Vault Key Sealed With SHA1 PCRs The measured boot solution implemented in EVE OS leans on a PCR locking mechanism. Different parts of the system update different PCR values in the TPM, resulting in a unique value for each PCR entry. These PCRs are then used in order to seal/unseal a key from the TPM which is used to encrypt/decrypt the “vault” directory. This “vault” directory is the most sensitive point in the system and as such, its content should be protected. This mechanism is noted in Zededa’s documentation as the “measured boot” mechanism, designed to protect said “vault”. The code that’s responsible for generating and fetching the key from the TPM assumes that SHA256 PCRs are used in order to seal/unseal the key, and as such their presence is being checked. The issue here is that the key is not sealed using SHA256 PCRs, but using SHA1 PCRs. This leads to several issues: • Machines that have their SHA256 PCRs enabled but SHA1 PCRs disabled, as well as not sealing their keys at all, meaning the “vault” is not protected from an attacker. • SHA1 is considered insecure and reduces the complexity level required to unseal the key in machines which have their SHA1 PCRs enabled. An attacker can very easily retrieve the contents of the “vault”, which will effectively render the “measured boot” mechanism meaningless.
Impacted products
Show details on NVD website


{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-02T19:44:43.776Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://asrg.io/security-advisories/cve-2023-43635/"
          }
        ],
        "title": "CVE Program Container"
      },
      {
        "affected": [
          {
            "cpes": [
              "cpe:2.3:o:linuxfoundation:edge_virtualization_engine:*:*:*:*:*:*:*:*"
            ],
            "defaultStatus": "unknown",
            "product": "edge_virtualization_engine",
            "vendor": "linuxfoundation",
            "versions": [
              {
                "lessThan": "9.5.0",
                "status": "affected",
                "version": "0",
                "versionType": "custom"
              }
            ]
          }
        ],
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2023-43635",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-09-25T14:32:23.099233Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-09-25T14:37:39.566Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "packageName": "EVE OS",
          "product": "EVE OS",
          "programFiles": [
            "https://github.com/lf-edge/eve/blob/master/pkg/pillar/evetpm/tpm.go"
          ],
          "repo": "https://github.com/lf-edge/eve",
          "vendor": " LF-Edge, Zededa",
          "versions": [
            {
              "lessThan": "9.5.0",
              "status": "affected",
              "version": "0",
              "versionType": "release"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "user": "00000000-0000-4000-9000-000000000000",
          "value": "Ilay Levi"
        }
      ],
      "datePublic": "2023-09-20T14:57:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\n\nVault Key Sealed With SHA1 PCRs\n\n\n\u003cbr\u003e\u003cbr\u003e\n\nThe measured boot solution implemented in EVE OS leans on a PCR locking mechanism.\n\u003cbr\u003eDifferent parts of the system update different PCR values in the TPM, resulting in a unique\nvalue for each PCR entry.\n\u003cbr\u003eThese PCRs are then used in order to seal/unseal a key from the TPM which is used to\nencrypt/decrypt the \u201cvault\u201d directory.\n\u003cbr\u003eThis \u201cvault\u201d directory is the most sensitive point in the system and as such, its content should\nbe protected.\n\u003cbr\u003eThis mechanism is noted in Zededa\u2019s documentation as the \u201cmeasured boot\u201d mechanism,\ndesigned to protect said \u201cvault\u201d.\n\u003cbr\u003eThe code that\u2019s responsible for generating and fetching the key from the TPM assumes that\nSHA256 PCRs are used in order to seal/unseal the key, and as such their presence is being\nchecked.\n\u003cbr\u003eThe issue here is that the key is not sealed using SHA256 PCRs, but using SHA1 PCRs.\nThis leads to several issues:\n\u003cbr\u003e\u2022 Machines that have their SHA256 PCRs enabled but SHA1 PCRs disabled, as well\nas not sealing their keys at all, meaning the \u201cvault\u201d is not protected from an attacker.\n\u003cbr\u003e\u2022 SHA1 is considered insecure and reduces the complexity level required to unseal the\nkey in machines which have their SHA1 PCRs enabled.\u003cbr\u003e\u003cbr\u003e\n\nAn attacker can very easily retrieve the contents of the \u201cvault\u201d, which will effectively render\nthe \u201cmeasured boot\u201d mechanism meaningless.\n\n\n\n\n\u003cbr\u003e"
            }
          ],
          "value": "\nVault Key Sealed With SHA1 PCRs\n\n\n\n\n\n\nThe measured boot solution implemented in EVE OS leans on a PCR locking mechanism.\n\nDifferent parts of the system update different PCR values in the TPM, resulting in a unique\nvalue for each PCR entry.\n\nThese PCRs are then used in order to seal/unseal a key from the TPM which is used to\nencrypt/decrypt the \u201cvault\u201d directory.\n\nThis \u201cvault\u201d directory is the most sensitive point in the system and as such, its content should\nbe protected.\n\nThis mechanism is noted in Zededa\u2019s documentation as the \u201cmeasured boot\u201d mechanism,\ndesigned to protect said \u201cvault\u201d.\n\nThe code that\u2019s responsible for generating and fetching the key from the TPM assumes that\nSHA256 PCRs are used in order to seal/unseal the key, and as such their presence is being\nchecked.\n\nThe issue here is that the key is not sealed using SHA256 PCRs, but using SHA1 PCRs.\nThis leads to several issues:\n\n\u2022 Machines that have their SHA256 PCRs enabled but SHA1 PCRs disabled, as well\nas not sealing their keys at all, meaning the \u201cvault\u201d is not protected from an attacker.\n\n\u2022 SHA1 is considered insecure and reduces the complexity level required to unseal the\nkey in machines which have their SHA1 PCRs enabled.\n\n\n\nAn attacker can very easily retrieve the contents of the \u201cvault\u201d, which will effectively render\nthe \u201cmeasured boot\u201d mechanism meaningless.\n\n\n\n\n\n"
        }
      ],
      "impacts": [
        {
          "capecId": "CAPEC-115",
          "descriptions": [
            {
              "lang": "en",
              "value": "CAPEC-115 Authentication Bypass"
            }
          ]
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "LOCAL",
            "availabilityImpact": "HIGH",
            "baseScore": 8.8,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-522",
              "description": "CWE-522 Insufficiently Protected Credentials",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-328",
              "description": "CWE-328 Use of Weak Hash",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2023-09-28T05:36:04.512Z",
        "orgId": "c15abc07-96a9-4d11-a503-5d621bfe42ba",
        "shortName": "ASRG"
      },
      "references": [
        {
          "url": "https://asrg.io/security-advisories/cve-2023-43635/"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Vault Key Sealed With SHA1 PCRs",
      "x_generator": {
        "engine": "Vulnogram 0.1.0-dev"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "c15abc07-96a9-4d11-a503-5d621bfe42ba",
    "assignerShortName": "ASRG",
    "cveId": "CVE-2023-43635",
    "datePublished": "2023-09-20T14:58:07.687Z",
    "dateReserved": "2023-09-20T14:34:14.874Z",
    "dateUpdated": "2024-09-25T14:37:39.566Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2023-43635\",\"sourceIdentifier\":\"cve@asrg.io\",\"published\":\"2023-09-20T15:15:11.987\",\"lastModified\":\"2024-11-21T08:24:30.877\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"\\nVault Key Sealed With SHA1 PCRs\\n\\n\\n\\n\\n\\n\\nThe measured boot solution implemented in EVE OS leans on a PCR locking mechanism.\\n\\nDifferent parts of the system update different PCR values in the TPM, resulting in a unique\\nvalue for each PCR entry.\\n\\nThese PCRs are then used in order to seal/unseal a key from the TPM which is used to\\nencrypt/decrypt the \u201cvault\u201d directory.\\n\\nThis \u201cvault\u201d directory is the most sensitive point in the system and as such, its content should\\nbe protected.\\n\\nThis mechanism is noted in Zededa\u2019s documentation as the \u201cmeasured boot\u201d mechanism,\\ndesigned to protect said \u201cvault\u201d.\\n\\nThe code that\u2019s responsible for generating and fetching the key from the TPM assumes that\\nSHA256 PCRs are used in order to seal/unseal the key, and as such their presence is being\\nchecked.\\n\\nThe issue here is that the key is not sealed using SHA256 PCRs, but using SHA1 PCRs.\\nThis leads to several issues:\\n\\n\u2022 Machines that have their SHA256 PCRs enabled but SHA1 PCRs disabled, as well\\nas not sealing their keys at all, meaning the \u201cvault\u201d is not protected from an attacker.\\n\\n\u2022 SHA1 is considered insecure and reduces the complexity level required to unseal the\\nkey in machines which have their SHA1 PCRs enabled.\\n\\n\\n\\nAn attacker can very easily retrieve the contents of the \u201cvault\u201d, which will effectively render\\nthe \u201cmeasured boot\u201d mechanism meaningless.\\n\\n\\n\\n\\n\\n\"},{\"lang\":\"es\",\"value\":\"Vault Key Sealed With SHA1 PCRs La soluci\u00f3n de arranque medido implementada en EVE OS se apoya en un mecanismo de bloqueo de PCR. Diferentes partes del sistema actualizan diferentes valores de PCR en el TPM, lo que da como resultado un valor \u00fanico para cada entrada de PCR. Estos PCR se utilizan luego para sellar/abrir una clave del TPM que se utiliza para cifrar/descifrar el directorio \\\"vault\\\". Este directorio \\\"vault\\\" es el punto m\u00e1s sensible del sistema y, como tal, su contenido debe estar protegido. Este mecanismo est\u00e1 se\u00f1alado en la documentaci\u00f3n de Zededa como el mecanismo de \u201cmeasured boot\u201d, dise\u00f1ado para proteger dicha \u201cvault\u201d. El c\u00f3digo responsable de generar y obtener la clave del TPM asume que se utilizan PCR SHA256 para sellar/abrir la clave y, como tal, se verifica su presencia. El problema aqu\u00ed es que la clave no se sella mediante PCR SHA256, sino mediante PCR SHA1. Esto genera varios problemas: \u2022 M\u00e1quinas que tienen sus PCR SHA256 habilitadas pero las PCR SHA1 deshabilitadas, adem\u00e1s de que no sellan sus claves en absoluto, lo que significa que la \u201cvault\u201d no est\u00e1 protegida de un atacante. \u2022 SHA1 se considera inseguro y reduce el nivel de complejidad requerido para desbloquear la clave en m\u00e1quinas que tienen sus PCR SHA1 habilitados. Un atacante puede recuperar muy f\u00e1cilmente el contenido de la \\\"vault\\\", lo que efectivamente dejar\u00e1 sin sentido el mecanismo de \\\"measured boot\\\".\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"cve@asrg.io\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H\",\"baseScore\":8.8,\"baseSeverity\":\"HIGH\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"CHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":2.0,\"impactScore\":6.0},{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H\",\"baseScore\":8.8,\"baseSeverity\":\"HIGH\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"CHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":2.0,\"impactScore\":6.0}]},\"weaknesses\":[{\"source\":\"cve@asrg.io\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-328\"},{\"lang\":\"en\",\"value\":\"CWE-522\"}]},{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-327\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linuxfoundation:edge_virtualization_engine:*:*:*:*:*:*:*:*\",\"versionEndExcluding\":\"9.5.0\",\"matchCriteriaId\":\"B3C18178-A893-4EA6-8BBF-51F05CE4CB7E\"}]}]}],\"references\":[{\"url\":\"https://asrg.io/security-advisories/cve-2023-43635/\",\"source\":\"cve@asrg.io\"},{\"url\":\"https://asrg.io/security-advisories/cve-2023-43635/\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CVE Program Container\", \"references\": [{\"url\": \"https://asrg.io/security-advisories/cve-2023-43635/\", \"tags\": [\"x_transferred\"]}], \"providerMetadata\": {\"orgId\": \"af854a3a-2127-422b-91ae-364da2661108\", \"shortName\": \"CVE\", \"dateUpdated\": \"2024-08-02T19:44:43.776Z\"}}, {\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2023-43635\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"total\"}], \"version\": \"2.0.3\", \"timestamp\": \"2024-09-25T14:32:23.099233Z\"}}}], \"affected\": [{\"cpes\": [\"cpe:2.3:o:linuxfoundation:edge_virtualization_engine:*:*:*:*:*:*:*:*\"], \"vendor\": \"linuxfoundation\", \"product\": \"edge_virtualization_engine\", \"versions\": [{\"status\": \"affected\", \"version\": \"0\", \"lessThan\": \"9.5.0\", \"versionType\": \"custom\"}], \"defaultStatus\": \"unknown\"}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2024-09-25T14:37:00.579Z\"}}], \"cna\": {\"title\": \"Vault Key Sealed With SHA1 PCRs\", \"source\": {\"discovery\": \"UNKNOWN\"}, \"credits\": [{\"lang\": \"en\", \"type\": \"finder\", \"user\": \"00000000-0000-4000-9000-000000000000\", \"value\": \"Ilay Levi\"}], \"impacts\": [{\"capecId\": \"CAPEC-115\", \"descriptions\": [{\"lang\": \"en\", \"value\": \"CAPEC-115 Authentication Bypass\"}]}], \"metrics\": [{\"format\": \"CVSS\", \"cvssV3_1\": {\"scope\": \"CHANGED\", \"version\": \"3.1\", \"baseScore\": 8.8, \"attackVector\": \"LOCAL\", \"baseSeverity\": \"HIGH\", \"vectorString\": \"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H\", \"integrityImpact\": \"HIGH\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"LOW\", \"availabilityImpact\": \"HIGH\", \"privilegesRequired\": \"LOW\", \"confidentialityImpact\": \"HIGH\"}, \"scenarios\": [{\"lang\": \"en\", \"value\": \"GENERAL\"}]}], \"affected\": [{\"repo\": \"https://github.com/lf-edge/eve\", \"vendor\": \" LF-Edge, Zededa\", \"product\": \"EVE OS\", \"versions\": [{\"status\": \"affected\", \"version\": \"0\", \"lessThan\": \"9.5.0\", \"versionType\": \"release\"}], \"packageName\": \"EVE OS\", \"programFiles\": [\"https://github.com/lf-edge/eve/blob/master/pkg/pillar/evetpm/tpm.go\"], \"defaultStatus\": \"unaffected\"}], \"datePublic\": \"2023-09-20T14:57:00.000Z\", \"references\": [{\"url\": \"https://asrg.io/security-advisories/cve-2023-43635/\"}], \"x_generator\": {\"engine\": \"Vulnogram 0.1.0-dev\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"\\nVault Key Sealed With SHA1 PCRs\\n\\n\\n\\n\\n\\n\\nThe measured boot solution implemented in EVE OS leans on a PCR locking mechanism.\\n\\nDifferent parts of the system update different PCR values in the TPM, resulting in a unique\\nvalue for each PCR entry.\\n\\nThese PCRs are then used in order to seal/unseal a key from the TPM which is used to\\nencrypt/decrypt the \\u201cvault\\u201d directory.\\n\\nThis \\u201cvault\\u201d directory is the most sensitive point in the system and as such, its content should\\nbe protected.\\n\\nThis mechanism is noted in Zededa\\u2019s documentation as the \\u201cmeasured boot\\u201d mechanism,\\ndesigned to protect said \\u201cvault\\u201d.\\n\\nThe code that\\u2019s responsible for generating and fetching the key from the TPM assumes that\\nSHA256 PCRs are used in order to seal/unseal the key, and as such their presence is being\\nchecked.\\n\\nThe issue here is that the key is not sealed using SHA256 PCRs, but using SHA1 PCRs.\\nThis leads to several issues:\\n\\n\\u2022 Machines that have their SHA256 PCRs enabled but SHA1 PCRs disabled, as well\\nas not sealing their keys at all, meaning the \\u201cvault\\u201d is not protected from an attacker.\\n\\n\\u2022 SHA1 is considered insecure and reduces the complexity level required to unseal the\\nkey in machines which have their SHA1 PCRs enabled.\\n\\n\\n\\nAn attacker can very easily retrieve the contents of the \\u201cvault\\u201d, which will effectively render\\nthe \\u201cmeasured boot\\u201d mechanism meaningless.\\n\\n\\n\\n\\n\\n\", \"supportingMedia\": [{\"type\": \"text/html\", \"value\": \"\\n\\nVault Key Sealed With SHA1 PCRs\\n\\n\\n\u003cbr\u003e\u003cbr\u003e\\n\\nThe measured boot solution implemented in EVE OS leans on a PCR locking mechanism.\\n\u003cbr\u003eDifferent parts of the system update different PCR values in the TPM, resulting in a unique\\nvalue for each PCR entry.\\n\u003cbr\u003eThese PCRs are then used in order to seal/unseal a key from the TPM which is used to\\nencrypt/decrypt the \\u201cvault\\u201d directory.\\n\u003cbr\u003eThis \\u201cvault\\u201d directory is the most sensitive point in the system and as such, its content should\\nbe protected.\\n\u003cbr\u003eThis mechanism is noted in Zededa\\u2019s documentation as the \\u201cmeasured boot\\u201d mechanism,\\ndesigned to protect said \\u201cvault\\u201d.\\n\u003cbr\u003eThe code that\\u2019s responsible for generating and fetching the key from the TPM assumes that\\nSHA256 PCRs are used in order to seal/unseal the key, and as such their presence is being\\nchecked.\\n\u003cbr\u003eThe issue here is that the key is not sealed using SHA256 PCRs, but using SHA1 PCRs.\\nThis leads to several issues:\\n\u003cbr\u003e\\u2022 Machines that have their SHA256 PCRs enabled but SHA1 PCRs disabled, as well\\nas not sealing their keys at all, meaning the \\u201cvault\\u201d is not protected from an attacker.\\n\u003cbr\u003e\\u2022 SHA1 is considered insecure and reduces the complexity level required to unseal the\\nkey in machines which have their SHA1 PCRs enabled.\u003cbr\u003e\u003cbr\u003e\\n\\nAn attacker can very easily retrieve the contents of the \\u201cvault\\u201d, which will effectively render\\nthe \\u201cmeasured boot\\u201d mechanism meaningless.\\n\\n\\n\\n\\n\u003cbr\u003e\", \"base64\": false}]}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-522\", \"description\": \"CWE-522 Insufficiently Protected Credentials\"}]}, {\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-328\", \"description\": \"CWE-328 Use of Weak Hash\"}]}], \"providerMetadata\": {\"orgId\": \"c15abc07-96a9-4d11-a503-5d621bfe42ba\", \"shortName\": \"ASRG\", \"dateUpdated\": \"2023-09-28T05:36:04.512Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2023-43635\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2024-09-25T14:37:39.566Z\", \"dateReserved\": \"2023-09-20T14:34:14.874Z\", \"assignerOrgId\": \"c15abc07-96a9-4d11-a503-5d621bfe42ba\", \"datePublished\": \"2023-09-20T14:58:07.687Z\", \"assignerShortName\": \"ASRG\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.1"
    }
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

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.


Loading…

Loading…