Common Weakness Enumeration

CWE-347

Allowed

Improper Verification of Cryptographic Signature

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product does not verify, or incorrectly verifies, the cryptographic signature for data.

1266 vulnerabilities reference this CWE, most recent first.

GHSA-849V-5927-J7JQ

Vulnerability from github – Published: 2025-11-04 03:30 – Updated: 2025-12-17 21:30
VLAI
Details

A downgrade issue affecting Intel-based Mac computers was addressed with additional code-signing restrictions. This issue is fixed in macOS Sonoma 14.8.2, macOS Sequoia 15.7.2. An app may be able to access sensitive user data.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-43468"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-04T02:15:51Z",
    "severity": "HIGH"
  },
  "details": "A downgrade issue affecting Intel-based Mac computers was addressed with additional code-signing restrictions. This issue is fixed in macOS Sonoma 14.8.2, macOS Sequoia 15.7.2. An app may be able to access sensitive user data.",
  "id": "GHSA-849v-5927-j7jq",
  "modified": "2025-12-17T21:30:38Z",
  "published": "2025-11-04T03:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43468"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/125634"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/125635"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/125636"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-84WC-9427-HW23

Vulnerability from github – Published: 2022-05-24 17:22 – Updated: 2025-10-22 00:31
VLAI
Details

When Security Assertion Markup Language (SAML) authentication is enabled and the 'Validate Identity Provider Certificate' option is disabled (unchecked), improper verification of signatures in PAN-OS SAML authentication enables an unauthenticated network-based attacker to access protected resources. The attacker must have network access to the vulnerable server to exploit this vulnerability. This issue affects PAN-OS 9.1 versions earlier than PAN-OS 9.1.3; PAN-OS 9.0 versions earlier than PAN-OS 9.0.9; PAN-OS 8.1 versions earlier than PAN-OS 8.1.15, and all versions of PAN-OS 8.0 (EOL). This issue does not affect PAN-OS 7.1. This issue cannot be exploited if SAML is not used for authentication. This issue cannot be exploited if the 'Validate Identity Provider Certificate' option is enabled (checked) in the SAML Identity Provider Server Profile. Resources that can be protected by SAML-based single sign-on (SSO) authentication are: GlobalProtect Gateway, GlobalProtect Portal, GlobalProtect Clientless VPN, Authentication and Captive Portal, PAN-OS next-generation firewalls (PA-Series, VM-Series) and Panorama web interfaces, Prisma Access In the case of GlobalProtect Gateways, GlobalProtect Portal, Clientless VPN, Captive Portal, and Prisma Access, an unauthenticated attacker with network access to the affected servers can gain access to protected resources if allowed by configured authentication and Security policies. There is no impact on the integrity and availability of the gateway, portal or VPN server. An attacker cannot inspect or tamper with sessions of regular users. In the worst case, this is a critical severity vulnerability with a CVSS Base Score of 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N). In the case of PAN-OS and Panorama web interfaces, this issue allows an unauthenticated attacker with network access to the PAN-OS or Panorama web interfaces to log in as an administrator and perform administrative actions. In the worst-case scenario, this is a critical severity vulnerability with a CVSS Base Score of 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). If the web interfaces are only accessible to a restricted management network, then the issue is lowered to a CVSS Base Score of 9.6 (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). Palo Alto Networks is not aware of any malicious attempts to exploit this vulnerability.

Severity
10.0 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-2021"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-06-29T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "When Security Assertion Markup Language (SAML) authentication is enabled and the \u0027Validate Identity Provider Certificate\u0027 option is disabled (unchecked), improper verification of signatures in PAN-OS SAML authentication enables an unauthenticated network-based attacker to access protected resources. The attacker must have network access to the vulnerable server to exploit this vulnerability. This issue affects PAN-OS 9.1 versions earlier than PAN-OS 9.1.3; PAN-OS 9.0 versions earlier than PAN-OS 9.0.9; PAN-OS 8.1 versions earlier than PAN-OS 8.1.15, and all versions of PAN-OS 8.0 (EOL). This issue does not affect PAN-OS 7.1. This issue cannot be exploited if SAML is not used for authentication. This issue cannot be exploited if the \u0027Validate Identity Provider Certificate\u0027 option is enabled (checked) in the SAML Identity Provider Server Profile. Resources that can be protected by SAML-based single sign-on (SSO) authentication are: GlobalProtect Gateway, GlobalProtect Portal, GlobalProtect Clientless VPN, Authentication and Captive Portal, PAN-OS next-generation firewalls (PA-Series, VM-Series) and Panorama web interfaces, Prisma Access In the case of GlobalProtect Gateways, GlobalProtect Portal, Clientless VPN, Captive Portal, and Prisma Access, an unauthenticated attacker with network access to the affected servers can gain access to protected resources if allowed by configured authentication and Security policies. There is no impact on the integrity and availability of the gateway, portal or VPN server. An attacker cannot inspect or tamper with sessions of regular users. In the worst case, this is a critical severity vulnerability with a CVSS Base Score of 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N). In the case of PAN-OS and Panorama web interfaces, this issue allows an unauthenticated attacker with network access to the PAN-OS or Panorama web interfaces to log in as an administrator and perform administrative actions. In the worst-case scenario, this is a critical severity vulnerability with a CVSS Base Score of 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). If the web interfaces are only accessible to a restricted management network, then the issue is lowered to a CVSS Base Score of 9.6 (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). Palo Alto Networks is not aware of any malicious attempts to exploit this vulnerability.",
  "id": "GHSA-84wc-9427-hw23",
  "modified": "2025-10-22T00:31:55Z",
  "published": "2022-05-24T17:22:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-2021"
    },
    {
      "type": "WEB",
      "url": "https://security.paloaltonetworks.com/CVE-2020-2021"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2020-2021"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-84X5-5F67-WJP4

Vulnerability from github – Published: 2025-08-05 06:30 – Updated: 2025-08-05 06:30
VLAI
Details

An improper verification of cryptographic signature in Zscaler's SAML authentication mechanism on the server-side allowed an authentication abuse.

Severity
9.6 (Critical)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-54982"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-05T06:15:26Z",
    "severity": "CRITICAL"
  },
  "details": "An improper verification of cryptographic signature in Zscaler\u0027s SAML authentication mechanism on the server-side allowed an authentication abuse.",
  "id": "GHSA-84x5-5f67-wjp4",
  "modified": "2025-08-05T06:30:31Z",
  "published": "2025-08-05T06:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54982"
    },
    {
      "type": "WEB",
      "url": "https://help.zscaler.com/zia/about-identity-providers"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-854X-2JM6-MVWP

Vulnerability from github – Published: 2022-10-11 12:00 – Updated: 2022-10-14 12:00
VLAI
Details

A vulnerability in the software image verification functionality of Cisco IOS XE Software for Cisco Catalyst 9200 Series Switches could allow an unauthenticated, physical attacker to execute unsigned code at system boot time. This vulnerability is due to an improper check in the code function that manages the verification of the digital signatures of system image files during the initial boot process. An attacker could exploit this vulnerability by loading unsigned software on an affected device. A successful exploit could allow the attacker to boot a malicious software image or execute unsigned code and bypass the image verification check part of the boot process of the affected device. To exploit this vulnerability, the attacker needs either unauthenticated physical access to the device or privileged access to the root shell on the device. Note: In Cisco IOS XE Software releases 16.11.1 and later, root shell access is protected by the Consent Token mechanism. However, an attacker with level-15 privileges could easily downgrade the Cisco IOS XE Software running on a device to a release where root shell access is more readily available.

Severity
6.8 (Medium)
CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-20944"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-10T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the software image verification functionality of Cisco IOS XE Software for Cisco Catalyst 9200 Series Switches could allow an unauthenticated, physical attacker to execute unsigned code at system boot time. This vulnerability is due to an improper check in the code function that manages the verification of the digital signatures of system image files during the initial boot process. An attacker could exploit this vulnerability by loading unsigned software on an affected device. A successful exploit could allow the attacker to boot a malicious software image or execute unsigned code and bypass the image verification check part of the boot process of the affected device. To exploit this vulnerability, the attacker needs either unauthenticated physical access to the device or privileged access to the root shell on the device. Note: In Cisco IOS XE Software releases 16.11.1 and later, root shell access is protected by the Consent Token mechanism. However, an attacker with level-15 privileges could easily downgrade the Cisco IOS XE Software running on a device to a release where root shell access is more readily available.",
  "id": "GHSA-854x-2jm6-mvwp",
  "modified": "2022-10-14T12:00:25Z",
  "published": "2022-10-11T12:00:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20944"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ios-xe-cat-verify-D4NEQA6q"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-869P-CJFG-CM3X

Vulnerability from github – Published: 2025-12-04 16:54 – Updated: 2025-12-04 22:50
VLAI
Summary
auth0/node-jws Improperly Verifies HMAC Signature
Details

Overview

An improper signature verification vulnerability exists when using auth0/node-jws with the HS256 algorithm under specific conditions.

Am I Affected?

You are affected by this vulnerability if you meet all of the following preconditions:

  1. Application uses the auth0/node-jws implementation of JSON Web Signatures, versions <=3.2.2 || 4.0.0
  2. Application uses the jws.createVerify() function for HMAC algorithms
  3. Application uses user-provided data from the JSON Web Signature Protected Header or Payload in the HMAC secret lookup routines

You are NOT affected by this vulnerability if you meet any of the following preconditions: 1. Application uses the jws.verify() interface (note: auth0/node-jsonwebtoken users fall into this category and are therefore NOT affected by this vulnerability) 2. Application uses only asymmetric algorithms (e.g. RS256) 3. Application doesn’t use user-provided data from the JSON Web Signature Protected Header or Payload in the HMAC secret lookup routines

Fix

Upgrade auth0/node-jws version to version 3.2.3 or 4.0.1

Acknowledgement

Okta would like to thank Félix Charette for discovering this vulnerability.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "jws"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "jws"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "4.0.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2025-65945"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-04T16:54:15Z",
    "nvd_published_at": "2025-12-04T19:16:05Z",
    "severity": "HIGH"
  },
  "details": "### Overview\nAn improper signature verification vulnerability exists when using auth0/node-jws with the HS256 algorithm under specific conditions.\n\n### Am I Affected?\nYou are affected by this vulnerability if you meet all of the following preconditions:\n\n1. Application uses the auth0/node-jws implementation of JSON Web Signatures, versions \u003c=3.2.2 || 4.0.0\n2. Application uses the jws.createVerify() function for HMAC algorithms\n3. Application uses user-provided data from the JSON Web Signature Protected Header or Payload in the HMAC secret lookup routines\n\nYou are NOT affected by this vulnerability if you meet any of the following preconditions:\n1. Application uses the jws.verify() interface (note: `auth0/node-jsonwebtoken` users fall into this category and are therefore NOT affected by this vulnerability)\n2. Application uses only asymmetric algorithms (e.g. RS256)\n3. Application doesn\u2019t use user-provided data from the JSON Web Signature Protected Header or Payload in the HMAC secret lookup routines\n\n### Fix\nUpgrade auth0/node-jws version to version 3.2.3 or 4.0.1\n\n### Acknowledgement\nOkta would like to thank F\u00e9lix Charette for discovering this vulnerability.",
  "id": "GHSA-869p-cjfg-cm3x",
  "modified": "2025-12-04T22:50:03Z",
  "published": "2025-12-04T16:54:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/auth0/node-jws/security/advisories/GHSA-869p-cjfg-cm3x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-65945"
    },
    {
      "type": "WEB",
      "url": "https://github.com/auth0/node-jws/commit/34c45b2c04434f925b638de6a061de9339c0ea2e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/auth0/node-jws/commit/4f6e73f24df42f07d632dec6431ade8eda8d11a6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/auth0/node-jws"
    },
    {
      "type": "WEB",
      "url": "https://github.com/auth0/node-jws/releases/tag/v3.2.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/auth0/node-jws/releases/tag/v4.0.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "auth0/node-jws Improperly Verifies HMAC Signature"
}

GHSA-88C7-XPJH-3F4J

Vulnerability from github – Published: 2022-05-24 17:17 – Updated: 2024-11-26 18:38
VLAI
Details

A vulnerability in the Image Signature Verification feature of Cisco Firepower Threat Defense (FTD) Software could allow an authenticated, remote attacker with administrator-level credentials to install a malicious software patch on an affected device. The vulnerability is due to improper verification of digital signatures for patch images. An attacker could exploit this vulnerability by crafting an unsigned software patch to bypass signature checks and loading it on an affected device. A successful exploit could allow the attacker to boot a malicious software patch image.

Severity
4.9 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-3308"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-05-06T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the Image Signature Verification feature of Cisco Firepower Threat Defense (FTD) Software could allow an authenticated, remote attacker with administrator-level credentials to install a malicious software patch on an affected device. The vulnerability is due to improper verification of digital signatures for patch images. An attacker could exploit this vulnerability by crafting an unsigned software patch to bypass signature checks and loading it on an affected device. A successful exploit could allow the attacker to boot a malicious software patch image.",
  "id": "GHSA-88c7-xpjh-3f4j",
  "modified": "2024-11-26T18:38:40Z",
  "published": "2022-05-24T17:17:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-3308"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sigbypass-FcvPPCeP"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-88H9-77C7-P6W4

Vulnerability from github – Published: 2025-11-12 21:45 – Updated: 2025-11-18 17:00
VLAI
Summary
Evervault Go SDK: Incomplete PCR Validation in Enclave Attestation for non-Evervault hosted Enclaves
Details

Summary

A vulnerability was identified in the evervault-go SDK’s attestation verification logic that may allow incomplete documents to pass validation. This may cause the client to trust an enclave operator that does not meet expected integrity guarantees.

The exploitability of this issue is limited in Evervault-hosted environments as an attacker would require the pre-requisite ability to serve requests from specific evervault domain names, following from our ACME challenge based TLS certificate acquisition pipeline.

The vulnerability primarily affects applications which only check PCR8. Though the efficacy is also reduced for applications that check all PCR values, the impact is largely remediated by checking PCR 0, 1 and 2.

Patches

The identified issue has been addressed in version 1.3.2 by validating attestation documents before storing in the cache, and replacing the naive equality checks with a new SatisfiedBy check.

Workarounds

If you are using evervault-go to attest Enclaves that are hosted outside of Evervault environments and cannot upgrade:

1) Modify your application logic to fail verification if PCR8 is not explicitly present and non-empty 2) Add custom pre-validation to reject documents that omit any required PCRs.

POC

package evervault
import (
        "testing"

        "github.com/evervault/evervault-go/attestation"
        "github.com/stretchr/testify/assert"
        "github.com/hf/nitrite"
)


func TestVulnerableCompare(t *testing.T) {
          assert := assert.New(t)
          // arrange
          expectedPCRs := []attestation.PCRs{
                attestation.PCRs{
                      PCR0:
"000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001",
                      PCR1:
"000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002",
                      PCR2:
"000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003",
                      PCR8:
"000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004",
                     },
           }
            actualDocument := nitrite.Document {}
            actualDocument.PCRs = map[uint][]byte{
                    10: make([]byte, 32),
            }
            // act
            v := verifyPCRs(expectedPCRs, actualDocument)

            // assert
            // Verify should not pass but it does

            assert.Equal(true, v)
}
Severity
8.7 (High)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/evervault/evervault-go"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-64186"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-12T21:45:06Z",
    "nvd_published_at": "2025-11-12T21:15:53Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA vulnerability was identified in the `evervault-go` SDK\u2019s attestation verification logic that may allow incomplete documents to pass validation. This may cause the client to trust an enclave operator that does not meet expected integrity guarantees.\n\nThe exploitability of this issue is limited in Evervault-hosted environments as an attacker would require the pre-requisite ability to serve requests from specific evervault domain names, following from our ACME challenge based TLS certificate acquisition pipeline. \n\nThe vulnerability primarily affects applications which only check PCR8. Though the efficacy is also reduced for applications that check all PCR values, the impact is largely remediated by checking PCR 0, 1 and 2.\n \n\n### Patches\nThe identified issue has been addressed in version [1.3.2](https://github.com/evervault/evervault-go/pull/48) by validating attestation documents before storing in the cache, and replacing the naive equality checks with a new SatisfiedBy check.\n\n### Workarounds\nIf you are using evervault-go to attest Enclaves that are hosted outside of Evervault environments and cannot upgrade:\n\n1) Modify your application logic to fail verification if PCR8 is not explicitly present and non-empty\n2) Add custom pre-validation to reject documents that omit any required PCRs.\n\n### POC\n```\npackage evervault\nimport (\n        \"testing\"\n\n        \"github.com/evervault/evervault-go/attestation\"\n        \"github.com/stretchr/testify/assert\"\n        \"github.com/hf/nitrite\"\n)\n\n\nfunc TestVulnerableCompare(t *testing.T) {\n          assert := assert.New(t)\n          // arrange\n          expectedPCRs := []attestation.PCRs{\n                attestation.PCRs{\n                      PCR0:\n\"000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001\",\n                      PCR1:\n\"000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002\",\n                      PCR2:\n\"000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003\",\n                      PCR8:\n\"000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004\",\n                     },\n           }\n            actualDocument := nitrite.Document {}\n            actualDocument.PCRs = map[uint][]byte{\n                    10: make([]byte, 32),\n            }\n            // act\n            v := verifyPCRs(expectedPCRs, actualDocument)\n            \n            // assert\n            // Verify should not pass but it does\n            \n            assert.Equal(true, v)\n}\n```",
  "id": "GHSA-88h9-77c7-p6w4",
  "modified": "2025-11-18T17:00:18Z",
  "published": "2025-11-12T21:45:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/evervault/evervault-go/security/advisories/GHSA-88h9-77c7-p6w4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64186"
    },
    {
      "type": "WEB",
      "url": "https://github.com/evervault/evervault-go/pull/48"
    },
    {
      "type": "WEB",
      "url": "https://github.com/evervault/evervault-go/commit/7c824d289bba11ec0bea46a338023f5b128bbb28"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/evervault/evervault-go"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Evervault Go SDK: Incomplete PCR Validation in Enclave Attestation for non-Evervault hosted Enclaves"
}

GHSA-89Q4-G827-GP8H

Vulnerability from github – Published: 2022-03-31 00:00 – Updated: 2022-04-09 00:01
VLAI
Details

Yubico ykneo-openpgp before 1.0.10 has a typo in which an invalid PIN can be used. When first powered up, a signature will be issued even though the PIN has not been validated.

Severity
8.8 (High)
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2015-3298"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-03-30T00:15:00Z",
    "severity": "HIGH"
  },
  "details": "Yubico ykneo-openpgp before 1.0.10 has a typo in which an invalid PIN can be used. When first powered up, a signature will be issued even though the PIN has not been validated.",
  "id": "GHSA-89q4-g827-gp8h",
  "modified": "2022-04-09T00:01:00Z",
  "published": "2022-03-31T00:00:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-3298"
    },
    {
      "type": "WEB",
      "url": "https://developers.yubico.com/ykneo-openpgp/SecurityAdvisory%202015-04-14.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-89V2-G37M-G3FF

Vulnerability from github – Published: 2021-06-01 21:18 – Updated: 2021-06-01 18:53
VLAI
Summary
Improper Verification of Cryptographic Signature in aws-encryption-sdk-cli
Details

Impact

This advisory addresses several LOW severity issues with streaming signed messages and restricting processing of certain types of invalid messages.

This ESDK supports a streaming mode where callers may stream the plaintext of signed messages before the ECDSA signature is validated. In addition to these signatures, the ESDK uses AES-GCM encryption and all plaintext is verified before being released to a caller. There is no impact on the integrity of the ciphertext or decrypted plaintext, however some callers may rely on the the ECDSA signature for non-repudiation. Without validating the ECDSA signature, an actor with trusted KMS permissions to decrypt a message may also be able to encrypt messages. This update introduces a new API for callers who wish to stream only unsigned messages.

For customers who process ESDK messages from untrusted sources, this update also introduces a new configuration to limit the number of Encrypted Data Keys (EDKs) that the ESDK will attempt to process per message. This configuration provides customers with a way to limit the number of AWS KMS Decrypt API calls that the ESDK will make per message. This setting will reject messages with more EDKs than the configured limit.

Finally, this update adds early rejection of invalid messages with certain invalid combinations of algorithm suite and header data.

Patches

Fixed in versions 1.9 and 2.2. We recommend that all users upgrade to address these issues.

Customers leveraging the ESDK’s streaming features have several options to protect signature validation. One is to ensure that client code reads to the end of the stream before using released plaintext. With this release, using the new API for streaming and falling back to the non-streaming decrypt API for signed messages prevents using any plaintext from signed data before the signature is validated. See https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/about-versions.html#version2.2.x

Users processing ESDK messages from untrusted sources should use the new maximum encrypted data keys parameter. See https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/about-versions.html#version2.2.x

Workarounds

None

For more information

https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/concepts.html#digital-sigs

https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/about-versions.html#version2.2.x

Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "aws-encryption-sdk-cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "aws-encryption-sdk-cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-06-01T18:53:10Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nThis advisory addresses several LOW severity issues with streaming signed messages and restricting processing of certain types of invalid messages. \n\nThis ESDK supports a streaming mode where callers may stream the plaintext of signed messages before the ECDSA signature is validated. In addition to these signatures, the ESDK uses AES-GCM encryption and all plaintext is verified before being released to a caller. There is no impact on the integrity of the ciphertext or decrypted plaintext, however some callers may rely on the the ECDSA signature for non-repudiation. Without validating the ECDSA signature, an actor with trusted KMS permissions to decrypt a message may also be able to encrypt messages. This update introduces a new API for callers who wish to stream only unsigned messages. \n\nFor customers who process ESDK messages from untrusted sources, this update also introduces a new configuration to limit the number of Encrypted Data Keys (EDKs) that the ESDK will attempt to process per message. This configuration provides customers with a way to limit the number of AWS KMS Decrypt API calls that the ESDK will make per message. This setting will reject messages with more EDKs than the configured limit.\n\nFinally, this update adds early rejection of invalid messages with certain invalid combinations of algorithm suite and header data.\n\n### Patches\n\nFixed in versions 1.9 and 2.2. We recommend that all users upgrade to address these issues.\n\nCustomers leveraging the ESDK\u2019s streaming features have several options to protect signature validation. One is to ensure that client code reads to the end of the stream before using released plaintext. With this release, using the new API for streaming and falling back to the non-streaming decrypt API for signed messages prevents using any plaintext from signed data before the signature is validated. See https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/about-versions.html#version2.2.x\n\nUsers processing ESDK messages from untrusted sources should use the new maximum encrypted data keys parameter. See https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/about-versions.html#version2.2.x\n\n### Workarounds\n\nNone\n\n### For more information\n\nhttps://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/concepts.html#digital-sigs\n\nhttps://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/about-versions.html#version2.2.x\n",
  "id": "GHSA-89v2-g37m-g3ff",
  "modified": "2021-06-01T18:53:10Z",
  "published": "2021-06-01T21:18:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/aws/aws-encryption-sdk-cli/security/advisories/GHSA-89v2-g37m-g3ff"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Improper Verification of Cryptographic Signature in aws-encryption-sdk-cli"
}

GHSA-8C5W-9G3P-G72C

Vulnerability from github – Published: 2023-07-13 18:30 – Updated: 2024-04-04 06:07
VLAI
Details

Incorrect signature verification of the firmware during the Device Firmware Update process of Belkin Wemo Smart Plug WSP080 v1.2 allows attackers to cause a Denial of Service (DoS) via a crafted firmware file.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-33768"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-13T16:15:09Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect signature verification of the firmware during the Device Firmware Update process of Belkin Wemo Smart Plug WSP080 v1.2 allows attackers to cause a Denial of Service (DoS) via a crafted firmware file.",
  "id": "GHSA-8c5w-9g3p-g72c",
  "modified": "2024-04-04T06:07:29Z",
  "published": "2023-07-13T18:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-33768"
    },
    {
      "type": "WEB",
      "url": "https://github.com/purseclab/CVE-2023-33768"
    },
    {
      "type": "WEB",
      "url": "https://play.google.com/store/apps/details?id=com.belkin.wemoandroid\u0026hl=en_US\u0026gl=US"
    },
    {
      "type": "WEB",
      "url": "https://www.amazon.com/Control-Devices-Remotely-Assistant-HomeKit/dp/B08CJGZZZ1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-463: Padding Oracle Crypto Attack

An adversary is able to efficiently decrypt data without knowing the decryption key if a target system leaks data on whether or not a padding error happened while decrypting the ciphertext. A target system that leaks this type of information becomes the padding oracle and an adversary is able to make use of that oracle to efficiently decrypt data without knowing the decryption key by issuing on average 128*b calls to the padding oracle (where b is the number of bytes in the ciphertext block). In addition to performing decryption, an adversary is also able to produce valid ciphertexts (i.e., perform encryption) by using the padding oracle, all without knowing the encryption key.

CAPEC-475: Signature Spoofing by Improper Validation

An adversary exploits a cryptographic weakness in the signature verification algorithm implementation to generate a valid signature without knowing the key.

← Back to the CWE list