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.

1120 vulnerabilities reference this CWE, most recent first.

GHSA-P3W6-JCG4-52XH

Vulnerability from github – Published: 2019-07-02 15:43 – Updated: 2024-09-16 21:58
VLAI
Summary
Improper Verification of Cryptographic Signature in django-rest-registration
Details

Misusing the Django Signer API leads to predictable signatures used in verification emails

Impact

The vulnerability is a high severity one. Anyone using Django REST Registration library versions 0.2.* - 0.4.* with e-mail verification option (which is recommended, but needs additional configuration) is affected. In the worst case, the attacker can take over any Django user by resetting his/her password without even receiving the reset password verification link, just by guessing the signature from publicly available data (more detailed description below).

Patches

The problem has been patched in version 0.5.0. All library users should upgrade to version 0.5.0 or higher. The fix will invalidate all previously generated signatures , and in consequence, all verification links in previously sent verification e-mails. Therefore semi-major version 0.5.0 was released instead of version 0.4.6 to mark that incompatibility.

Workarounds

The easiest way way is to disable the verification options by using something like the minimal configuration described here. This will unfortunately disable checking whether the given e-mail is valid and make unable to users who registered an account but didn't verify it before config change.

Less harsh way is to temporarily disable just the the reset password functionality:

REST_REGISTRATION = {
    # ...
    'RESET_PASSWORD_VERIFICATION_ENABLED': False,
    # ...
}

Which should disallow the worst case, which is account takeover by an attacker. The attacker can still use the register-email endpoint to change the email to its own (but it is less critical than resetting the password in this case).

If one already set 'RESET_PASSWORD_VERIFICATION_ONE_TIME_USE' setting key to True in REST_REGISTRATION Django setting (which is not the default setting) then it should mitigate the security issue in case of password reset (in this case, the signature is much harder to guess by the attacker). But even in this case upgrade to newest version is highly recommended.

Technical description

After the code was refactored to use the official Signer class the salt was passed wrongly as secret key, replacing the SECRET_KEY set in Django settings file. This leads to the Django SECRET_KEY not being used by the signer object. The secret key of the signer ends to be the salt which in most cases is a static string which is publicly available.

In consequence this allows, with verification enabled, to guess the signature contained in the verification link (which is sent in a verification e-mail) by a potential attacker very easily.

The bug went unnoticed for very long time so multiple versions are affected: this bug affects versions 0.2.*, 0.3.*, 0.4.*; version 0.1.* is not affected.

Recently released version 0.5.0 contains the fix which correctly passes the salt to the Signer constructor as keyword argument instead as a positonal argument. It also contains additonal test so this problem should not reappear in the future.

Thanks

I'd like to thank @peterthomassen from https://desec.io DNS security project for finding the bug. I'd like also to thank his employer, SSE (https://www.securesystems.de) for funding his work.

For more information

If you have any questions or comments about this advisory: * Open an issue in GitHub issues project page * Email @apragacz, author of the library

Severity
9.8 (Critical)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
9.3 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "django-rest-registration"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.2.0"
            },
            {
              "fixed": "0.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-13177"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T21:47:52Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "## Misusing the Django Signer API leads to predictable signatures used in verification emails\n\n### Impact\nThe vulnerability is a high severity one. Anyone using Django REST Registration library versions `0.2.*` - `0.4.*` with e-mail verification option (which is recommended, but needs [additional configuration](https://django-rest-registration.readthedocs.io/en/latest/quickstart.html#preferred-configuration)) is affected.\nIn the worst case, the attacker can take over any Django user by resetting his/her password without even receiving the reset password verification link, just by guessing the signature from publicly available data (more detailed description below).\n\n### Patches\nThe problem has been patched in version `0.5.0`. All library users should upgrade to version `0.5.0` or higher.\nThe fix will invalidate all previously generated signatures , and in consequence, all verification links in previously sent verification e-mails. Therefore semi-major version `0.5.0` was released instead of version `0.4.6` to mark that incompatibility.\n\n### Workarounds\nThe easiest way way is to disable the verification options by using something like the minimal configuration described [here](https://django-rest-registration.readthedocs.io/en/latest/quickstart.html#minimal-configuration). This will unfortunately disable checking whether the given e-mail is valid and make unable to users who registered an account but didn\u0027t verify it before config change.\n\nLess harsh way is to temporarily disable just the the reset password functionality:\n\n```python\nREST_REGISTRATION = {\n    # ...\n    \u0027RESET_PASSWORD_VERIFICATION_ENABLED\u0027: False,\n    # ...\n}\n```\nWhich should disallow the worst case, which is account takeover by an attacker. The attacker can still use the register-email endpoint to change the email to its own (but it is less critical than resetting the password in this case).\n\nIf one already set `\u0027RESET_PASSWORD_VERIFICATION_ONE_TIME_USE\u0027` setting key to `True` in `REST_REGISTRATION` Django setting (which is not the default setting) then it should mitigate the security issue in case of password reset (in this case, the signature is much harder to guess by the attacker). But even in this case upgrade to newest version is highly recommended.\n\n### Technical description\nAfter the code [was refactored](https://github.com/apragacz/django-rest-registration/commit/b6d921e9decc9bb36a4c6d58bc607471aa824a2e) to use the [official Signer class](https://docs.djangoproject.com/en/dev/topics/signing/) the salt\nwas passed wrongly as secret key, replacing the `SECRET_KEY` set in\nDjango settings file. This leads to the Django `SECRET_KEY` not being used by the signer object. The secret key of the signer ends to be the salt which in most cases is a static string which is publicly available.\n\nIn consequence this allows, with verification enabled, to guess\nthe signature contained in the verification link (which is sent in a verification e-mail) by a potential attacker very easily.\n\nThe bug went unnoticed for very long time so multiple versions are affected:\nthis bug affects versions `0.2.*`, `0.3.*`, `0.4.*`; version `0.1.*` is not affected.\n\nRecently released version `0.5.0` contains the [fix](https://github.com/apragacz/django-rest-registration/commit/26d094fab65ea8c2694fdfb6a3ab95a7808b62d5) which correctly passes the salt to the Signer constructor as keyword argument instead as a positonal argument. It also contains additonal test so this problem should not reappear in the future.\n\n### Thanks\nI\u0027d like to thank @peterthomassen from https://desec.io DNS security project for finding the bug. I\u0027d like also to thank his employer, SSE (https://www.securesystems.de) for funding his work.\n\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [GitHub issues project page](https://github.com/apragacz/django-rest-registration/issues)\n* Email @apragacz, author of the library ",
  "id": "GHSA-p3w6-jcg4-52xh",
  "modified": "2024-09-16T21:58:34Z",
  "published": "2019-07-02T15:43:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/apragacz/django-rest-registration/security/advisories/GHSA-p3w6-jcg4-52xh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-13177"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apragacz/django-rest-registration/commit/26d094fab65ea8c2694fdfb6a3ab95a7808b62d5"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-p3w6-jcg4-52xh"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apragacz/django-rest-registration"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apragacz/django-rest-registration/releases/tag/0.5.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/django-rest-registration/PYSEC-2019-20.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Improper Verification of Cryptographic Signature in django-rest-registration"
}

GHSA-P53J-G8PW-4W5F

Vulnerability from github – Published: 2025-03-13 06:30 – Updated: 2025-03-13 16:24
VLAI
Summary
Ed25519 Signature Malleability in ed25519-java Due to Missing Scalar Range Check
Details

The implementation of EdDSA in EdDSA-Java (aka ed25519-java) through 0.3.0 exhibits signature malleability and does not satisfy the SUF-CMA (Strong Existential Unforgeability under Chosen Message Attacks) property. This allows attackers to create new valid signatures different from previous signatures for a known message.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "net.i2p.crypto:eddsa"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "net.i2p:i2p"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.39"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-36843"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-13T16:24:28Z",
    "nvd_published_at": "2025-03-13T06:15:34Z",
    "severity": "MODERATE"
  },
  "details": "The implementation of EdDSA in EdDSA-Java (aka ed25519-java) through 0.3.0 exhibits signature malleability and does not satisfy the SUF-CMA (Strong Existential Unforgeability under Chosen Message Attacks) property. This allows attackers to create new valid signatures different from previous signatures for a known message.",
  "id": "GHSA-p53j-g8pw-4w5f",
  "modified": "2025-03-13T16:24:28Z",
  "published": "2025-03-13T06:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36843"
    },
    {
      "type": "WEB",
      "url": "https://github.com/str4d/ed25519-java/issues/82#issue-727629226"
    },
    {
      "type": "WEB",
      "url": "https://github.com/i2p/i2p.i2p/commit/d7d1dcb5399c61cf2916ccc45aa25b0209c88712#diff-658f7b1aa34b58d27796fccdb8b756c72702d64ae44703374960f1cb89a5a5c3"
    },
    {
      "type": "WEB",
      "url": "https://eprint.iacr.org/2020/1244"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/str4d/ed25519-java"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Ed25519 Signature Malleability in ed25519-java Due to Missing Scalar Range Check"
}

GHSA-P6J6-G4FC-G496

Vulnerability from github – Published: 2026-04-03 21:31 – Updated: 2026-05-01 12:30
VLAI
Details

A flaw was found in rust-rpm-sequoia. An attacker can exploit this vulnerability by providing a specially crafted Red Hat Package Manager (RPM) file. During the RPM signature verification process, this crafted file can trigger an error in the OpenPGP signature parsing code, leading to an unconditional termination of the rpm process. This issue results in an application level denial of service, making the system unable to process RPM files for signature verification.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-2625"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-03T19:17:22Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in rust-rpm-sequoia. An attacker can exploit this vulnerability by providing a specially crafted Red Hat Package Manager (RPM) file. During the RPM signature verification process, this crafted file can trigger an error in the OpenPGP signature parsing code, leading to an unconditional termination of the rpm process. This issue results in an application level denial of service, making the system unable to process RPM files for signature verification.",
  "id": "GHSA-p6j6-g4fc-g496",
  "modified": "2026-05-01T12:30:24Z",
  "published": "2026-04-03T21:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2625"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:12682"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-2625"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2440357"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P6RV-Q5PX-G7G8

Vulnerability from github – Published: 2022-05-24 16:56 – Updated: 2024-04-04 01:59
VLAI
Details

A vulnerability in the Image Verification feature of Cisco IOS XE Software could allow an authenticated, local attacker to install and boot a malicious software image or execute unsigned binaries on an affected device. The vulnerability exists because, under certain circumstances, an affected device can be configured to not verify the digital signatures of system image files during the boot process. An attacker could exploit this vulnerability by abusing a specific feature that is part of the device boot process. A successful exploit could allow the attacker to install and boot a malicious software image or execute unsigned binaries on the targeted device.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-12649"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-09-25T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the Image Verification feature of Cisco IOS XE Software could allow an authenticated, local attacker to install and boot a malicious software image or execute unsigned binaries on an affected device. The vulnerability exists because, under certain circumstances, an affected device can be configured to not verify the digital signatures of system image files during the boot process. An attacker could exploit this vulnerability by abusing a specific feature that is part of the device boot process. A successful exploit could allow the attacker to install and boot a malicious software image or execute unsigned binaries on the targeted device.",
  "id": "GHSA-p6rv-q5px-g7g8",
  "modified": "2024-04-04T01:59:46Z",
  "published": "2022-05-24T16:56:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-12649"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190925-iosxe-digsig-bypass"
    }
  ],
  "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-P72W-R6FV-6G5H

Vulnerability from github – Published: 2024-09-17 21:30 – Updated: 2025-03-14 21:41
VLAI
Summary
druid-pac4j, Apache Druid extension, has Padding Oracle vulnerability
Details

Padding Oracle vulnerability in Apache Druid extension, druid-pac4j. This could allow an attacker to manipulate a pac4j session cookie.

This issue affects Apache Druid versions 0.18.0 through 30.0.0. Since the druid-pac4j extension is optional and disabled by default, Druid installations not using the druid-pac4j extension are not affected by this vulnerability.

While we are not aware of a way to meaningfully exploit this flaw, we nevertheless recommend upgrading to version 30.0.1 or higher which fixes the issue and ensuring you have a strong druid.auth.pac4j.cookiePassphrase as a precaution.

Severity
3.7 (Low)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N
1.7 (Low)
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:U
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.druid.extensions:druid-pac4j"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.18.0"
            },
            {
              "fixed": "30.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-45384"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-09-17T22:14:49Z",
    "nvd_published_at": "2024-09-17T19:15:28Z",
    "severity": "LOW"
  },
  "details": "Padding Oracle vulnerability in Apache Druid extension, druid-pac4j.\nThis could allow an attacker to manipulate a pac4j session cookie.\n\nThis issue affects Apache Druid versions 0.18.0 through 30.0.0.\nSince the druid-pac4j extension is optional and disabled by default, Druid installations not using the druid-pac4j extension are not affected by this vulnerability.\n\nWhile we are not aware of a way to meaningfully exploit this flaw, we nevertheless recommend upgrading to version 30.0.1 or higher which fixes the issue and ensuring you have a strong druid.auth.pac4j.cookiePassphrase as a precaution.",
  "id": "GHSA-p72w-r6fv-6g5h",
  "modified": "2025-03-14T21:41:15Z",
  "published": "2024-09-17T21:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45384"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/druid/commit/74cab7a76c99da457c3a883939cc0b03301b8771"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/druid"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/druid/releases/tag/druid-30.0.1"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/gr94fnp574plb50lsp8jw4smvgv1lbz1"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2024/09/17/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "druid-pac4j, Apache Druid extension, has Padding Oracle vulnerability"
}

GHSA-P7W3-XCQR-PR4R

Vulnerability from github – Published: 2022-05-24 19:11 – Updated: 2022-05-24 19:11
VLAI
Details

A vulnerability in the image verification function of Cisco Expressway Series and Cisco TelePresence Video Communication Server (VCS) could allow an authenticated, remote attacker to execute code with internal user privileges on the underlying operating system. The vulnerability is due to insufficient validation of the content of upgrade packages. An attacker could exploit this vulnerability by uploading a malicious archive to the Upgrade page of the administrative web interface. A successful exploit could allow the attacker to execute code with user-level privileges (the _nobody account) on the underlying operating system.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-34715"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-08-18T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the image verification function of Cisco Expressway Series and Cisco TelePresence Video Communication Server (VCS) could allow an authenticated, remote attacker to execute code with internal user privileges on the underlying operating system. The vulnerability is due to insufficient validation of the content of upgrade packages. An attacker could exploit this vulnerability by uploading a malicious archive to the Upgrade page of the administrative web interface. A successful exploit could allow the attacker to execute code with user-level privileges (the _nobody account) on the underlying operating system.",
  "id": "GHSA-p7w3-xcqr-pr4r",
  "modified": "2022-05-24T19:11:29Z",
  "published": "2022-05-24T19:11:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34715"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ewver-c6WZPXRx"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-P88H-9FMR-WJ9Q

Vulnerability from github – Published: 2026-03-16 15:30 – Updated: 2026-03-31 03:31
VLAI
Details

Improper verification of cryptographic signature in Smart Switch prior to version 3.7.69.15 allows remote attackers to potentially bypass authentication.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
5.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-20997"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-16T14:18:10Z",
    "severity": "MODERATE"
  },
  "details": "Improper verification of cryptographic signature in Smart Switch prior to version 3.7.69.15 allows remote attackers to potentially bypass authentication.",
  "id": "GHSA-p88h-9fmr-wj9q",
  "modified": "2026-03-31T03:31:25Z",
  "published": "2026-03-16T15:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20997"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/serviceWeb.smsb?year=2026\u0026month=03"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-P8C3-7RJ8-Q963

Vulnerability from github – Published: 2020-06-26 16:54 – Updated: 2023-01-31 01:29
VLAI
Summary
ECDSA signature validation vulnerability by accepting wrong ASN.1 encoding in jsrsasign
Details

Impact

Jsrsasign supports ECDSA signature validation which signature value is represented by ASN.1 DER encoding. This vulnerablity may accept a wrong ASN.1 DER encoded ECDSA signature such as:

  • wrong multi-byte ASN.1 length of TLV (ex. 0x820045 even though 0x45 is correct)
  • prepending zeros with ASN.1 INTEGER value (ex. 0x00000123 even though 0x0123 is correct)
  • appending zeros to signature of ASN.1 TLV (ex. 0x3082....1fbc000000 even though 0x3082....1fbc, appending zeros are ignored.)

This vulnerability was fixed by strict ASN.1 DER checking.

Here is an assessment of this vulnerability:

  • If you are not use ECDSA signature validation, this vulnerability is not affected.
  • Not ASN.1 format signature like just concatenation of R and S value is not affected such as Bitcoin.
  • This vulnerability is affected to all ECC curve parameters.
  • Risk to accept a forged or crafted message to be signed is low.
  • Risk to raise memory corruption is low since jsrsasign uses BigInteger class.
  • ECDSA signatures semantically the same to valid one may be accepted as valid. There are many malleable variants.

As discussed here, there is no standards like X9.62 which requires ASN.1 DER. So ASN.1 BER can be applied to ECDSA however most of implementations like OpenSSL do strict ASN.1 DER checking.

Patches

Users using ECDSA signature validation should upgrade to 8.0.19.

Workarounds

Do strict ASN.1 DER checking for ASN.1 encoded ECDSA signature value.

References

https://nvd.nist.gov/vuln/detail/CVE-2020-14966 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14966 https://vuldb.com/?id.157123 https://github.com/kjur/jsrsasign/issues/437 https://kjur.github.io/jsrsasign/api/symbols/KJUR.crypto.ECDSA.html https://kjur.github.io/jsrsasign/api/symbols/ASN1HEX.html#.checkStrictDER https://www.itu.int/rec/T-REC-X.690

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": "jsrsasign"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "8.0.19"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-14966"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-26T16:54:00Z",
    "nvd_published_at": "2020-06-22T12:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nJsrsasign supports ECDSA signature validation which signature value is represented by ASN.1 DER encoding. This vulnerablity may accept a wrong ASN.1 DER encoded ECDSA signature such as:\n\n- wrong multi-byte ASN.1 length of TLV (ex. 0x820045 even though 0x45 is correct)\n- prepending zeros with ASN.1 INTEGER value (ex. 0x00000123 even though 0x0123 is correct)\n- appending zeros to signature of ASN.1 TLV (ex. 0x3082....1fbc000000 even though 0x3082....1fbc, appending zeros are ignored.)\n\nThis vulnerability was fixed by strict ASN.1 DER checking. \n\nHere is an assessment of this vulnerability:\n\n- If you are not use ECDSA signature validation, this vulnerability is not affected.\n- Not ASN.1 format signature like just concatenation of R and S value is not affected such as Bitcoin.\n- This vulnerability is affected to all ECC curve parameters.\n- Risk to accept a forged or crafted message to be signed is low.\n- Risk to raise memory corruption is low since jsrsasign uses BigInteger class.\n- ECDSA signatures semantically the same to valid one may be accepted as valid. There are many malleable variants.\n\nAs discussed [here](https://crypto.stackexchange.com/questions/24862/ber-or-der-x9-62-for-ecdsa-signature), there is no standards like X9.62 which requires ASN.1 DER. So ASN.1 BER can be applied to ECDSA however most of implementations like OpenSSL do strict ASN.1 DER checking.\n\n### Patches\nUsers using ECDSA signature validation should upgrade to 8.0.19.\n\n### Workarounds\nDo strict ASN.1 DER checking for ASN.1 encoded ECDSA signature value.\n\n### References\nhttps://nvd.nist.gov/vuln/detail/CVE-2020-14966\nhttps://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14966\nhttps://vuldb.com/?id.157123\nhttps://github.com/kjur/jsrsasign/issues/437\nhttps://kjur.github.io/jsrsasign/api/symbols/KJUR.crypto.ECDSA.html\nhttps://kjur.github.io/jsrsasign/api/symbols/ASN1HEX.html#.checkStrictDER\nhttps://www.itu.int/rec/T-REC-X.690\n\n",
  "id": "GHSA-p8c3-7rj8-q963",
  "modified": "2023-01-31T01:29:53Z",
  "published": "2020-06-26T16:54:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kjur/jsrsasign/security/advisories/GHSA-p8c3-7rj8-q963"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-14966"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kjur/jsrsasign/issues/437"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kjur/jsrsasign/commit/6087412d072a57074d3c4c1b40bdde0460d53a7f"
    },
    {
      "type": "WEB",
      "url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14966"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kjur/jsrsasign"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kjur/jsrsasign/releases/tag/8.0.17"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kjur/jsrsasign/releases/tag/8.0.18"
    },
    {
      "type": "WEB",
      "url": "https://kjur.github.io/jsrsasign"
    },
    {
      "type": "WEB",
      "url": "https://kjur.github.io/jsrsasign/api/symbols/ASN1HEX.html#.checkStrictDER"
    },
    {
      "type": "WEB",
      "url": "https://kjur.github.io/jsrsasign/api/symbols/KJUR.crypto.ECDSA.html"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20200724-0001"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.157123"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/package/jsrsasign"
    }
  ],
  "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": "ECDSA signature validation vulnerability by accepting wrong ASN.1 encoding in jsrsasign"
}

GHSA-P8P9-354J-7MHR

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

An issue was discovered in Foxit Reader and PhantomPDF before 4.1 on macOS. Because the Hardened Runtime protection mechanism is not applied to code signing, code injection (or an information leak) can occur.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-26540"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347",
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-10-02T08:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in Foxit Reader and PhantomPDF before 4.1 on macOS. Because the Hardened Runtime protection mechanism is not applied to code signing, code injection (or an information leak) can occur.",
  "id": "GHSA-p8p9-354j-7mhr",
  "modified": "2022-05-24T17:30:02Z",
  "published": "2022-05-24T17:30:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26540"
    },
    {
      "type": "WEB",
      "url": "https://www.foxitsoftware.com/support/security-bulletins.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-P97V-RWHV-427H

Vulnerability from github – Published: 2025-12-09 18:30 – Updated: 2025-12-09 18:30
VLAI
Details

Improper verification of cryptographic signatures in the patch management component of Ivanti Endpoint Manager prior to version 2024 SU4 SR1 allows a remote unauthenticated attacker to execute arbitrary code. User Interaction is required.

Severity
7.8 (High)
CVSS:3.1/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-2025-13662"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-09T16:17:36Z",
    "severity": "HIGH"
  },
  "details": "Improper verification of cryptographic signatures in the patch management component of Ivanti Endpoint Manager prior to version 2024 SU4 SR1 allows a remote unauthenticated attacker to execute arbitrary code. User Interaction is required.",
  "id": "GHSA-p97v-rwhv-427h",
  "modified": "2025-12-09T18:30:35Z",
  "published": "2025-12-09T18:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13662"
    },
    {
      "type": "WEB",
      "url": "https://forums.ivanti.com/s/article/Security-Advisory-EPM-December-2025-for-EPM-2024"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/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