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.

1127 vulnerabilities reference this CWE, most recent first.

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"
    }
  ]
}

GHSA-8CJ2-JG77-QJ2P

Vulnerability from github – Published: 2022-05-03 00:01 – Updated: 2025-10-22 03:30
VLAI
Details

The WinVerifyTrust function in Microsoft Windows XP SP2 and SP3, Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2012 Gold and R2, and Windows RT Gold and 8.1 does not properly validate PE file digests during Authenticode signature verification, which allows remote attackers to execute arbitrary code via a crafted PE file, aka "WinVerifyTrust Signature Validation Vulnerability."

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

{
  "affected": [],
  "aliases": [
    "CVE-2013-3900"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2013-12-11T00:55:00Z",
    "severity": "HIGH"
  },
  "details": "The WinVerifyTrust function in Microsoft Windows XP SP2 and SP3, Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2012 Gold and R2, and Windows RT Gold and 8.1 does not properly validate PE file digests during Authenticode signature verification, which allows remote attackers to execute arbitrary code via a crafted PE file, aka \"WinVerifyTrust Signature Validation Vulnerability.\"",
  "id": "GHSA-8cj2-jg77-qj2p",
  "modified": "2025-10-22T03:30:35Z",
  "published": "2022-05-03T00:01:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-3900"
    },
    {
      "type": "WEB",
      "url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2013/ms13-098"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2013-3900"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2013-3900"
    },
    {
      "type": "WEB",
      "url": "http://blogs.technet.com/b/srd/archive/2013/12/10/ms13-098-update-to-enhance-the-security-of-authenticode.aspx"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8CJC-2W58-7V5J

Vulnerability from github – Published: 2022-05-17 02:33 – Updated: 2022-05-17 02:33
VLAI
Details

A PKCS#1 v1.5 signature verification routine in all Android releases from CAF using the Linux kernel may not check padding.

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

{
  "affected": [],
  "aliases": [
    "CVE-2014-9934"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-05-16T14:29:00Z",
    "severity": "HIGH"
  },
  "details": "A PKCS#1 v1.5 signature verification routine in all Android releases from CAF using the Linux kernel may not check padding.",
  "id": "GHSA-8cjc-2w58-7v5j",
  "modified": "2022-05-17T02:33:15Z",
  "published": "2022-05-17T02:33:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2014-9934"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2017-04-01"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/97329"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1038201"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8F4C-9GMV-RFM8

Vulnerability from github – Published: 2025-03-28 06:30 – Updated: 2025-03-28 06:30
VLAI
Details

The OpenSAML C++ library before 3.3.1 allows forging of signed SAML messages via parameter manipulation (when using SAML bindings that rely on non-XML signatures).

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-31335"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-28T06:15:34Z",
    "severity": "MODERATE"
  },
  "details": "The OpenSAML C++ library before 3.3.1 allows forging of signed SAML messages via parameter manipulation (when using SAML bindings that rely on non-XML signatures).",
  "id": "GHSA-8f4c-9gmv-rfm8",
  "modified": "2025-03-28T06:30:27Z",
  "published": "2025-03-28T06:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31335"
    },
    {
      "type": "WEB",
      "url": "https://git.shibboleth.net/view/?p=cpp-opensaml.git;a=commit;h=22a610b322e2178abd03e97cdbc8fb50b45efaee"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-security-announce/2025/msg00041.html"
    },
    {
      "type": "WEB",
      "url": "https://shibboleth.atlassian.net/browse/CPPOST-126"
    },
    {
      "type": "WEB",
      "url": "https://shibboleth.net/community/advisories/secadv_20250313.txt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8FFJ-4HX4-9PGF

Vulnerability from github – Published: 2026-04-08 00:17 – Updated: 2026-04-27 16:13
VLAI
Summary
lightrag-hku: JWT Algorithm Confusion Vulnerability
Details

Summary

The LightRAG API is vulnerable to a JWT algorithm confusion attack where an attacker can forge tokens by specifying 'alg': 'none' in the JWT header. Since the jwt.decode() call does not explicitly deny the 'none' algorithm, a crafted token without a signature will be accepted as valid, leading to unauthorized access.

Details

In lightrag/api/auth.py at line 128, the validate_token method calls:

payload = jwt.decode(token, self.secret, algorithms=[self.algorithm])

This allows any algorithm listed in the token's header to be processed, including 'none'. The code does not explicitly specify that 'none' is not allowed, making it possible for an attacker to bypass authentication.

PoC

An attacker can generate a JWT with the following structure:

{
  "header": {
    "alg": "none",
    "typ": "JWT"
  },
  "payload": {
    "sub": "admin",
    "exp": 1700000000,
    "role": "admin"
  }
}

Then send a request like:

curl -H "Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0." http://localhost:8000/api/protected-endpoint

Impact

An attacker can impersonate any user, including administrators, by forging a JWT with 'alg': 'none', gaining full access to protected resources without needing valid credentials.

Recommended Fix

Explicitly specify allowed algorithms and exclude 'none'. Modify the validate_token method to:

allowed_algorithms = [self.algorithm] if self.algorithm != 'none' else ['HS256', 'HS384', 'HS512']
payload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)

Or better yet, hardcode the expected algorithm(s):

payload = jwt.decode(token, self.secret, algorithms=['HS256'])
Severity
4.2 (Medium)
CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.4.13"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "lightrag-hku"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-39413"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-08T00:17:50Z",
    "nvd_published_at": "2026-04-08T20:16:25Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\nThe LightRAG API is vulnerable to a JWT algorithm confusion attack where an attacker can forge tokens by specifying \u0027alg\u0027: \u0027none\u0027 in the JWT header. Since the `jwt.decode()` call does not explicitly deny the \u0027none\u0027 algorithm, a crafted token without a signature will be accepted as valid, leading to unauthorized access.\n\n## Details\nIn `lightrag/api/auth.py` at line 128, the `validate_token` method calls:\n\n```python\npayload = jwt.decode(token, self.secret, algorithms=[self.algorithm])\n```\n\nThis allows any algorithm listed in the token\u0027s header to be processed, including \u0027none\u0027. The code does not explicitly specify that \u0027none\u0027 is not allowed, making it possible for an attacker to bypass authentication.\n\n## PoC\nAn attacker can generate a JWT with the following structure:\n\n```json\n{\n  \"header\": {\n    \"alg\": \"none\",\n    \"typ\": \"JWT\"\n  },\n  \"payload\": {\n    \"sub\": \"admin\",\n    \"exp\": 1700000000,\n    \"role\": \"admin\"\n  }\n}\n```\n\nThen send a request like:\n\n```bash\ncurl -H \"Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0.\" http://localhost:8000/api/protected-endpoint\n```\n\n## Impact\nAn attacker can impersonate any user, including administrators, by forging a JWT with \u0027alg\u0027: \u0027none\u0027, gaining full access to protected resources without needing valid credentials.\n\n## Recommended Fix\nExplicitly specify allowed algorithms and exclude \u0027none\u0027. Modify the `validate_token` method to:\n\n```python\nallowed_algorithms = [self.algorithm] if self.algorithm != \u0027none\u0027 else [\u0027HS256\u0027, \u0027HS384\u0027, \u0027HS512\u0027]\npayload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)\n```\n\nOr better yet, hardcode the expected algorithm(s):\n\n```python\npayload = jwt.decode(token, self.secret, algorithms=[\u0027HS256\u0027])\n```",
  "id": "GHSA-8ffj-4hx4-9pgf",
  "modified": "2026-04-27T16:13:13Z",
  "published": "2026-04-08T00:17:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/HKUDS/LightRAG/security/advisories/GHSA-8ffj-4hx4-9pgf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39413"
    },
    {
      "type": "WEB",
      "url": "https://github.com/HKUDS/LightRAG/commit/728f2e54509d93e0a44f929c7f83f2c88d6d291b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/HKUDS/LightRAG"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "lightrag-hku: JWT Algorithm Confusion Vulnerability "
}

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