Common Weakness Enumeration

CWE-347

Allowed

Improper Verification of Cryptographic Signature

Abstraction: Base · Status: Draft

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

1127 vulnerabilities reference this CWE, most recent first.

GHSA-QJ6M-MJM6-Q6QR

Vulnerability from github – Published: 2024-04-04 00:33 – Updated: 2024-09-06 18:31
VLAI
Details

An issue in D-Link COVR 1100, 1102, 1103 AC1200 Dual-Band Whole-Home Mesh Wi-Fi System (Hardware Rev B1) truncates Wireless Access Point Passwords (WPA-PSK) allowing an attacker to gain unauthorized network access via weak authentication controls.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-52043"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-03T22:15:06Z",
    "severity": "HIGH"
  },
  "details": "An issue in D-Link COVR 1100, 1102, 1103 AC1200 Dual-Band Whole-Home Mesh Wi-Fi System (Hardware Rev B1) truncates Wireless Access Point Passwords (WPA-PSK) allowing an attacker to gain unauthorized network access via weak authentication controls.",
  "id": "GHSA-qj6m-mjm6-q6qr",
  "modified": "2024-09-06T18:31:26Z",
  "published": "2024-04-04T00:33:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52043"
    },
    {
      "type": "WEB",
      "url": "https://exploots.github.io/posts/2024/01/18/d-link-covr-1102-vulnerability.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QJWP-HRQ6-R26R

Vulnerability from github – Published: 2026-06-01 14:26 – Updated: 2026-06-01 14:26
VLAI
Summary
kas checks out SHA-like git branches as valid commits
Details

Impact

When relying solely on a git commit ID (SHA-1 or SHA-256) to qualify if a checkout of a repository is equivalent to the state validated while adding its commit ID to a kas configuration, users may be tricked to check out a branch of the same name from this repository. This implies that the referenced repository has been taken over by an attacker and modified to carry such a branch. SHA-1 commits may also be replaced by creating hash collisions, so the primary impact of this issue is on SHA-256 commit IDs.

Patches

Commit https://github.com/siemens/kas/commit/4cb4a3d01122ffaec9feaae768a5814092f6f9b5 is resolving this issue. It has been released along with kas version 5.3.

Workarounds

Avoid relying solely on the commit ID for integrity validation of a repository that might become under control of a malicious 3rd party. If available, additional validate cryptographically signed commits or tags. Alternatively, mirror the repository to a save place, validate its integrity, and use this instead of the original one.

Credits

That such issues exist was already reported 3 years ago by Aditya Sirish A Yelgundhalli. At this point, no strong integrity checks for external repositories were in place in kas, and Siemens stated in the kas documentation that such attacks are considered out of scope. This hasn't changed for SHA-1 commits as explained above. If a repo provides SHA-256 commits, though, those may be considered strong enough (even if not providing authenticity proof) and can be affected by this issue.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "kas"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47191"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-01T14:26:36Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Impact\nWhen relying solely on a git commit ID (SHA-1 or SHA-256) to qualify if a checkout of a repository is equivalent to the state validated while adding its commit ID to a kas configuration, users may be tricked to check out a branch of the same name from this repository. This implies that the referenced repository has been taken over by an attacker and modified to carry such a branch. SHA-1 commits may also be replaced by creating hash collisions, so the primary impact of this issue is on SHA-256 commit IDs.\n\n### Patches\nCommit https://github.com/siemens/kas/commit/4cb4a3d01122ffaec9feaae768a5814092f6f9b5 is resolving this issue. It has been released along with kas version 5.3.\n\n### Workarounds\nAvoid relying solely on the commit ID for integrity validation of a repository that might become under control of a malicious 3rd party. If available, additional validate cryptographically signed commits or tags. Alternatively, mirror the repository to a save place, validate its integrity, and use this instead of the original one.\n\n### Credits\nThat such issues exist was already reported 3 years ago by Aditya Sirish A Yelgundhalli. At this point, no strong integrity checks for external repositories were in place in kas, and Siemens stated in the kas documentation that such attacks are considered out of scope. This hasn\u0027t changed for SHA-1 commits as explained above. If a repo provides SHA-256 commits, though, those may be considered strong enough (even if not providing authenticity proof) and can be affected by this issue.",
  "id": "GHSA-qjwp-hrq6-r26r",
  "modified": "2026-06-01T14:26:36Z",
  "published": "2026-06-01T14:26:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/siemens/kas/security/advisories/GHSA-qjwp-hrq6-r26r"
    },
    {
      "type": "WEB",
      "url": "https://github.com/siemens/kas/commit/4cb4a3d01122ffaec9feaae768a5814092f6f9b5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/siemens/kas"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:P/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "kas checks out SHA-like git branches as valid commits"
}

GHSA-QMF6-MW8H-6M87

Vulnerability from github – Published: 2022-05-24 17:40 – Updated: 2022-05-24 17:40
VLAI
Details

Bash injection vulnerability and bypass of signature verification in Rostelecom CS-C2SHW 5.0.082.1. The camera reads firmware update configuration from SD card file vc\version.json. fw-sign parameter and from this configuration is directly inserted into a bash command. Firmware update is run automatically if there is special file on the inserted SD card.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-27540"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-26T18:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Bash injection vulnerability and bypass of signature verification in Rostelecom CS-C2SHW 5.0.082.1. The camera reads firmware update configuration from SD card file vc\\version.json. fw-sign parameter and from this configuration is directly inserted into a bash command. Firmware update is run automatically if there is special file on the inserted SD card.",
  "id": "GHSA-qmf6-mw8h-6m87",
  "modified": "2022-05-24T17:40:12Z",
  "published": "2022-05-24T17:40:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27540"
    },
    {
      "type": "WEB",
      "url": "https://dil4rd.medium.com/groundhog-day-in-iot-valley-or-5-cves-in-1-camera-7dc1d2864707"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-QPGW-J75C-J585

Vulnerability from github – Published: 2024-07-31 21:32 – Updated: 2024-08-15 15:30
VLAI
Details

An issue was discovered in litestream v0.3.13. The usage of the ssh.InsecureIgnoreHostKey() disables host key verification, possibly allowing attackers to obtain sensitive information via a man-in-the-middle attack.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-41254"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347",
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-31T21:15:17Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in litestream v0.3.13. The usage of the ssh.InsecureIgnoreHostKey() disables host key verification, possibly allowing attackers to obtain sensitive information via a man-in-the-middle attack.",
  "id": "GHSA-qpgw-j75c-j585",
  "modified": "2024-08-15T15:30:52Z",
  "published": "2024-07-31T21:32:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41254"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/nyxfqq/d857f268a53aa62402655c8dcd95c68f"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QPV2-RWC8-C993

Vulnerability from github – Published: 2026-04-28 18:30 – Updated: 2026-05-05 14:45
VLAI
Summary
Netmaker does not verify JWT signatures for host tokens
Details

Netmaker by Gravitl is an open-source WireGuard-based networking platform for creating and managing virtual overlay networks. The VerifyHostToken function in logic/jwts.go does not validate the JWT signature when verifying host tokens. After calling jwt.ParseWithClaims, the function only checks whether the returned token object is non-nil. It does not check token.Valid or the returned error. An attacker can forge a JWT signed with any key, set the claims to any host ID, and pull that host's full configuration including bcrypt-hashed passwords, MQTT credentials, and WireGuard peer data. The issue was patched in v1.5.0.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/gravitl/netmaker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-38651"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T14:45:55Z",
    "nvd_published_at": "2026-04-28T16:16:13Z",
    "severity": "CRITICAL"
  },
  "details": "Netmaker by Gravitl is an open-source WireGuard-based networking platform for creating and managing virtual overlay networks. The `VerifyHostToken` function in `logic/jwts.go` does not validate the JWT signature when verifying host tokens. After calling `jwt.ParseWithClaims`, the function only checks whether the returned token object is non-nil. It does not check `token.Valid` or the returned error. An attacker can forge a JWT signed with any key, set the claims to any host ID, and pull that host\u0027s full configuration including bcrypt-hashed passwords, MQTT credentials, and WireGuard peer data. The issue was patched in v1.5.0.",
  "id": "GHSA-qpv2-rwc8-c993",
  "modified": "2026-05-05T14:45:55Z",
  "published": "2026-04-28T18:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-38651"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gravitl/netmaker/commit/5309aa70d464ef565911369714d661a61481a79b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gravitl/netmaker"
    },
    {
      "type": "WEB",
      "url": "https://www.zyenra.com/advisories/netmaker-jwt-verification-bypass"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:H/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Netmaker does not verify JWT signatures for host tokens"
}

GHSA-QQW8-7C2R-JXCH

Vulnerability from github – Published: 2026-06-30 18:10 – Updated: 2026-06-30 18:10
VLAI
Summary
Sigstore Java has a vulnerability with bundle verification of integratedTime
Details

Summary

Regression: Verification of integratedTime from Rekor V1 Log Entry against Fuclio Certificate validity was missing

Details

  • PR #1008 erroneously removed verification of the integrated (Rekor entry) time) against the Fulcio certificate.
  • PR #1185 re-added this verification with enhancements that adhere to the Sigstore verification spec.
  • old sigstore-conformance test for this check was built incorrectly

PoC

A new bundle was added to sigstore-conformance to test this: sigstore-java:2.0.0 can be tested against it and shown to be unexpectedly passing Verify this bundle against a.txt

$ git clone git@github.com:sigstore/sigstore-java
$ git checkout v2.0.0
$ ./gradlew :sigstore-cli:build
$ tar -xf sigstore-cli/build/distributions/sigstore-cli-*-SNAPSHOT.tar --strip-components 1
$ ./bin/sigstore-cli verify --bundle=bundle.sigstore.json a.txt
# expect error but none

Impact

This vulnerability impacts only users verifying bundles with dev.sigstore:sigstore-java:2.0.0. Older versions are not affected, it is fixed in dev.sigstore:sigstore-java:2.1.0

A malicious actor may exploit this if they were able to access a users system and exfiltrate the temporary private key used during signing and then reuse an old fulcio certificate later without requiring direct access to the user's credentials.

Users may protect themselves by re-verifying their artifacts using the newest sigstore-java or another current sigstore client. Transparency logs may also be audited for unauthorized signatures for a suspected reused identity.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "dev.sigstore:sigstore-java"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.0.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48791"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-30T18:10:28Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Summary\nRegression: Verification of `integratedTime` from Rekor V1 Log Entry against Fuclio Certificate validity was missing\n\n### Details\n- PR [#1008](https://github.com/sigstore/sigstore-java/pull/1008) erroneously removed verification of the integrated (Rekor entry) time) against the Fulcio certificate. \n- PR [#1185](https://github.com/sigstore/sigstore-java/pull/1185) re-added this verification with enhancements that adhere to the Sigstore verification spec.\n- old sigstore-conformance test for this check was built incorrectly\n\n### PoC\nA new bundle was added to sigstore-conformance to test this: sigstore-java:2.0.0 can be tested against it and shown to be unexpectedly passing\nVerify this [bundle](https://github.com/aaronlew02/sigstore-conformance/blob/8b45823fd0d82236ff42aea5b06c98d5109a0e6d/test/assets/bundle-verify/integrated-time-in-future_fail/bundle.sigstore.json) against [`a.txt`](https://github.com/aaronlew02/sigstore-conformance/blob/8b45823fd0d82236ff42aea5b06c98d5109a0e6d/test/assets/a.txt)\n\n```\n$ git clone git@github.com:sigstore/sigstore-java\n$ git checkout v2.0.0\n$ ./gradlew :sigstore-cli:build\n$ tar -xf sigstore-cli/build/distributions/sigstore-cli-*-SNAPSHOT.tar --strip-components 1\n$ ./bin/sigstore-cli verify --bundle=bundle.sigstore.json a.txt\n# expect error but none\n```\n\n### Impact\nThis vulnerability impacts only users verifying bundles with `dev.sigstore:sigstore-java:2.0.0`. Older versions are not affected, it is fixed in `dev.sigstore:sigstore-java:2.1.0`\n\nA malicious actor may exploit this if they were able to access a users system and exfiltrate the temporary private key used during signing and then reuse an old fulcio certificate later without requiring direct access to the user\u0027s credentials.\n\nUsers may protect themselves by re-verifying their artifacts using the newest sigstore-java or another current sigstore client. Transparency logs may also be audited for unauthorized signatures for a suspected reused identity.",
  "id": "GHSA-qqw8-7c2r-jxch",
  "modified": "2026-06-30T18:10:28Z",
  "published": "2026-06-30T18:10:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore-java/security/advisories/GHSA-qqw8-7c2r-jxch"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore-java/pull/1008"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore-java/pull/1185"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore-java/commit/4b7a49ebb1813f5b1ff113bcad63246358222d61"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore-java/commit/b529335728fc5cfb574161b4b3c06859a8a2aa88"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/sigstore-java"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Sigstore Java has a vulnerability with bundle verification of integratedTime"
}

GHSA-QR37-M54M-GWG9

Vulnerability from github – Published: 2025-12-09 21:31 – Updated: 2025-12-09 21:31
VLAI
Details

Acrobat Reader versions 24.001.30264, 20.005.30793, 25.001.20982, 24.001.30273, 20.005.30803 and earlier are affected by an Improper Verification of Cryptographic Signature vulnerability that could result in a Security feature bypass. An attacker could leverage this vulnerability to gain limited unauthorized write access. Exploitation of this issue does not require user interaction.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-64786"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-09T21:15:59Z",
    "severity": "LOW"
  },
  "details": "Acrobat Reader versions 24.001.30264, 20.005.30793, 25.001.20982, 24.001.30273, 20.005.30803 and earlier are affected by an Improper Verification of Cryptographic Signature vulnerability that could result in a Security feature bypass. An attacker could leverage this vulnerability to gain limited unauthorized write access. Exploitation of this issue does not require user interaction.",
  "id": "GHSA-qr37-m54m-gwg9",
  "modified": "2025-12-09T21:31:49Z",
  "published": "2025-12-09T21:31:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64786"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/acrobat/apsb25-119.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QV7W-V773-3XQM

Vulnerability from github – Published: 2026-01-21 16:13 – Updated: 2026-01-22 15:43
VLAI
Summary
sm-crypto Affected by Signature Malleability in SM2-DSA
Details

Summary

A signature malleability vulnerability exists in the SM2 signature verification logic of the sm-crypto library. An attacker can derive a new valid signature for a previously signed message from an existing signature.

Credit

This vulnerability was discovered by: - XlabAI Team of Tencent Xuanwu Lab - Atuin Automated Vulnerability Discovery Engine

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "sm-crypto"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-23967"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-21T16:13:35Z",
    "nvd_published_at": "2026-01-22T03:15:47Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA signature malleability vulnerability exists in the SM2 signature verification logic of the sm-crypto library. An attacker can derive a new valid signature for a previously signed message from an existing signature.\n\n### Credit\n\nThis vulnerability was discovered by:\n- XlabAI Team of Tencent Xuanwu Lab\n- Atuin Automated Vulnerability Discovery Engine",
  "id": "GHSA-qv7w-v773-3xqm",
  "modified": "2026-01-22T15:43:21Z",
  "published": "2026-01-21T16:13:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/JuneAndGreen/sm-crypto/security/advisories/GHSA-qv7w-v773-3xqm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23967"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/JuneAndGreen/sm-crypto"
    }
  ],
  "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": "sm-crypto Affected by Signature Malleability in SM2-DSA"
}

GHSA-QW5Q-44P2-MFCM

Vulnerability from github – Published: 2022-05-24 16:45 – Updated: 2023-03-24 18:30
VLAI
Details

A vulnerability in the Image Signature Verification feature of Cisco NX-OS Software could allow an authenticated, local attacker with administrator-level credentials to install a malicious software image on an affected device. The vulnerability exists because software digital signatures are not properly verified during CLI command execution. An attacker could exploit this vulnerability to install an unsigned software image on an affected device.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-1811"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-05-15T23:29:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the Image Signature Verification feature of Cisco NX-OS Software could allow an authenticated, local attacker with administrator-level credentials to install a malicious software image on an affected device. The vulnerability exists because software digital signatures are not properly verified during CLI command execution. An attacker could exploit this vulnerability to install an unsigned software image on an affected device.",
  "id": "GHSA-qw5q-44p2-mfcm",
  "modified": "2023-03-24T18:30:20Z",
  "published": "2022-05-24T16:45:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1811"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190515-nxos-sisv2"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/108425"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QWPH-4952-7XR6

Vulnerability from github – Published: 2022-12-22 03:32 – Updated: 2025-02-13 18:33
VLAI
Summary
jsonwebtoken vulnerable to signature validation bypass due to insecure default algorithm in jwt.verify()
Details

Overview

In versions <=8.5.1 of jsonwebtoken library, lack of algorithm definition and a falsy secret or key in the jwt.verify() function can lead to signature validation bypass due to defaulting to the none algorithm for signature verification.

Am I affected?

You will be affected if all the following are true in the jwt.verify() function: - a token with no signature is received - no algorithms are specified - a falsy (e.g. null, false, undefined) secret or key is passed

How do I fix it?

Update to version 9.0.0 which removes the default support for the none algorithm in the jwt.verify() method.

Will the fix impact my users?

There will be no impact, if you update to version 9.0.0 and you don’t need to allow for the none algorithm. If you need 'none' algorithm, you have to explicitly specify that in jwt.verify() options.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "jsonwebtoken"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "9.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-23540"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-327",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-22T03:32:59Z",
    "nvd_published_at": "2022-12-22T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "# Overview\n\nIn versions \u003c=8.5.1 of jsonwebtoken library, lack of algorithm definition and a falsy secret or key in the `jwt.verify()` function can lead to signature validation bypass due to defaulting to the `none` algorithm for signature verification.\n\n# Am I affected?\nYou will be affected if all the following are true in the `jwt.verify()` function:\n- a token with no signature is received\n- no algorithms are specified \n- a falsy (e.g. null, false, undefined) secret or key is passed \n\n# How do I fix it?\n \nUpdate to version 9.0.0 which removes the default support for the none algorithm in the `jwt.verify()` method. \n\n# Will the fix impact my users?\n\nThere will be no impact, if you update to version 9.0.0 and you don\u2019t need to allow for the `none` algorithm. If you need \u0027none\u0027 algorithm, you have to explicitly specify that in `jwt.verify()` options.",
  "id": "GHSA-qwph-4952-7xr6",
  "modified": "2025-02-13T18:33:13Z",
  "published": "2022-12-22T03:32:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/auth0/node-jsonwebtoken/security/advisories/GHSA-qwph-4952-7xr6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23540"
    },
    {
      "type": "WEB",
      "url": "https://github.com/auth0/node-jsonwebtoken/commit/e1fa9dcc12054a8681db4e6373da1b30cf7016e3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/auth0/node-jsonwebtoken"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240621-0007"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "jsonwebtoken vulnerable to signature validation bypass due to insecure default algorithm in jwt.verify()"
}

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.