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.

1123 vulnerabilities reference this CWE, most recent first.

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

GHSA-PCGW-QCV5-H8CH

Vulnerability from github – Published: 2026-03-18 20:19 – Updated: 2026-03-18 20:19
VLAI
Summary
Unsigned SAML LogoutRequest Acceptance in gosaml2
Details

Summary

The ValidateEncodedLogoutRequestPOST function in gosaml2 accepts completely unsigned SAML LogoutRequest messages even when SkipSignatureValidation is set to false. When validateElementSignature returns dsig.ErrMissingSignature, the code in decode_logout_request.go:60-62 silently falls through to process the unverified XML element instead of rejecting it. An attacker who can reach the SP's Single Logout endpoint can forge a LogoutRequest for any user, terminating their session without possessing the IdP's signing key.

Affected Version

  • Library: github.com/russellhaering/gosaml2
  • Version: All versions up to and including the latest commit on main (as of 2026-03-16)
  • File: decode_logout_request.go, lines 58-69

Vulnerable Code

// decode_logout_request.go:57-69
var requestSignatureValidated bool
if !sp.SkipSignatureValidation {
    el, err = sp.validateElementSignature(el)
    if err == dsig.ErrMissingSignature {
        // Unfortunately we just blew away our Response
        el = doc.Root()                    // <-- BUG: falls through with unsigned element
    } else if err != nil {
        return nil, err
    } else if el == nil {
        return nil, fmt.Errorf("missing transformed logout request")
    } else {
        requestSignatureValidated = true
    }
}

When ErrMissingSignature is returned, the code resets el to the raw document root and continues. The requestSignatureValidated variable remains false, but no error is returned. The unsigned LogoutRequest is unmarshalled and passed to ValidateDecodedLogoutRequest, which performs attribute/issuer checks but does not verify that a signature was present.

Attack Details

Property Value
Attack vector Network (HTTP POST to SLO endpoint)
Authentication required None
Payload size ~450 bytes (unsigned XML)
User interaction None
Complexity Low -- only requires knowledge of the SP's SLO URL and IdP issuer
CVSS estimate 7.5 (High) -- Network/Low/None/None, Availability impact

Impact

  • Arbitrary session termination: An attacker can force-logout any user by forging a LogoutRequest with the victim's NameID. This is a targeted denial-of-service.
  • Business disruption: Critical users (executives, admins, operators) can be repeatedly logged out, disrupting access to the application during incidents or time-sensitive operations.
  • Security control bypass: If session termination triggers downstream effects (e.g., revoking tokens, clearing caches), an attacker can weaponize this to force re-authentication flows and potentially intercept them.
  • No cryptographic material needed: The attacker does not need the IdP's private key. The forged request contains zero cryptographic elements.

Suggested Fix

When ErrMissingSignature is returned and SkipSignatureValidation is false, the function should return an error instead of falling through:

// decode_logout_request.go -- fixed version
var requestSignatureValidated bool
if !sp.SkipSignatureValidation {
    el, err = sp.validateElementSignature(el)
    if err == dsig.ErrMissingSignature {
        // FIXED: reject unsigned requests when signature validation is required
        return nil, fmt.Errorf("logout request is not signed: %w", dsig.ErrMissingSignature)
    } else if err != nil {
        return nil, err
    } else if el == nil {
        return nil, fmt.Errorf("missing transformed logout request")
    } else {
        requestSignatureValidated = true
    }
}

This ensures that unsigned LogoutRequest messages are rejected when SkipSignatureValidation is false, matching the behavior that operators expect when they configure signature enforcement.

Attached lab f1_unsigned_logout.zip

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.10.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/russellhaering/gosaml2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.11.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-18T20:19:24Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe `ValidateEncodedLogoutRequestPOST` function in gosaml2 accepts completely unsigned SAML `LogoutRequest` messages even when `SkipSignatureValidation` is set to `false`. When `validateElementSignature` returns `dsig.ErrMissingSignature`, the code in `decode_logout_request.go:60-62` silently falls through to process the unverified XML element instead of rejecting it. An attacker who can reach the SP\u0027s Single Logout endpoint can forge a `LogoutRequest` for any user, terminating their session without possessing the IdP\u0027s signing key.\n\n## Affected Version\n\n- **Library**: `github.com/russellhaering/gosaml2`\n- **Version**: All versions up to and including the latest commit on `main` (as of 2026-03-16)\n- **File**: `decode_logout_request.go`, lines 58-69\n\n## Vulnerable Code\n\n```go\n// decode_logout_request.go:57-69\nvar requestSignatureValidated bool\nif !sp.SkipSignatureValidation {\n    el, err = sp.validateElementSignature(el)\n    if err == dsig.ErrMissingSignature {\n        // Unfortunately we just blew away our Response\n        el = doc.Root()                    // \u003c-- BUG: falls through with unsigned element\n    } else if err != nil {\n        return nil, err\n    } else if el == nil {\n        return nil, fmt.Errorf(\"missing transformed logout request\")\n    } else {\n        requestSignatureValidated = true\n    }\n}\n```\n\nWhen `ErrMissingSignature` is returned, the code resets `el` to the raw document root and continues. The `requestSignatureValidated` variable remains `false`, but no error is returned. The unsigned `LogoutRequest` is unmarshalled and passed to `ValidateDecodedLogoutRequest`, which performs attribute/issuer checks but does **not** verify that a signature was present.\n\n## Attack Details\n\n| Property | Value |\n|---|---|\n| **Attack vector** | Network (HTTP POST to SLO endpoint) |\n| **Authentication required** | None |\n| **Payload size** | ~450 bytes (unsigned XML) |\n| **User interaction** | None |\n| **Complexity** | Low -- only requires knowledge of the SP\u0027s SLO URL and IdP issuer |\n| **CVSS estimate** | 7.5 (High) -- Network/Low/None/None, Availability impact |\n\n## Impact\n\n- **Arbitrary session termination**: An attacker can force-logout any user by forging a `LogoutRequest` with the victim\u0027s `NameID`. This is a targeted denial-of-service.\n- **Business disruption**: Critical users (executives, admins, operators) can be repeatedly logged out, disrupting access to the application during incidents or time-sensitive operations.\n- **Security control bypass**: If session termination triggers downstream effects (e.g., revoking tokens, clearing caches), an attacker can weaponize this to force re-authentication flows and potentially intercept them.\n- **No cryptographic material needed**: The attacker does not need the IdP\u0027s private key. The forged request contains zero cryptographic elements.\n\n## Suggested Fix\n\nWhen `ErrMissingSignature` is returned and `SkipSignatureValidation` is `false`, the function should return an error instead of falling through:\n\n```go\n// decode_logout_request.go -- fixed version\nvar requestSignatureValidated bool\nif !sp.SkipSignatureValidation {\n    el, err = sp.validateElementSignature(el)\n    if err == dsig.ErrMissingSignature {\n        // FIXED: reject unsigned requests when signature validation is required\n        return nil, fmt.Errorf(\"logout request is not signed: %w\", dsig.ErrMissingSignature)\n    } else if err != nil {\n        return nil, err\n    } else if el == nil {\n        return nil, fmt.Errorf(\"missing transformed logout request\")\n    } else {\n        requestSignatureValidated = true\n    }\n}\n```\n\nThis ensures that unsigned `LogoutRequest` messages are rejected when `SkipSignatureValidation` is `false`, matching the behavior that operators expect when they configure signature enforcement.\n\nAttached lab \n[f1_unsigned_logout.zip](https://github.com/user-attachments/files/26038319/f1_unsigned_logout.zip)",
  "id": "GHSA-pcgw-qcv5-h8ch",
  "modified": "2026-03-18T20:19:24Z",
  "published": "2026-03-18T20:19:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/russellhaering/gosaml2/security/advisories/GHSA-pcgw-qcv5-h8ch"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/russellhaering/gosaml2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Unsigned SAML LogoutRequest Acceptance in gosaml2"
}

GHSA-PCWW-JM77-2JG3

Vulnerability from github – Published: 2022-05-14 03:08 – Updated: 2022-05-14 03:08
VLAI
Details

An issue was discovered in Carbon Black Cb Response. A maliciously crafted Universal/fat binary can evade third-party code signing checks. By not completing full inspection of the Universal/fat binary, the user of the third-party tool will believe that the code is signed by Apple, but the malicious unsigned code will execute.

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-10407"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-06-13T22:29:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Carbon Black Cb Response. A maliciously crafted Universal/fat binary can evade third-party code signing checks. By not completing full inspection of the Universal/fat binary, the user of the third-party tool will believe that the code is signed by Apple, but the malicious unsigned code will execute.",
  "id": "GHSA-pcww-jm77-2jg3",
  "modified": "2022-05-14T03:08:35Z",
  "published": "2022-05-14T03:08:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-10407"
    },
    {
      "type": "WEB",
      "url": "https://www.okta.com/security-blog/2018/06/issues-around-third-party-apple-code-signing-checks"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PF4J-PF3W-95F9

Vulnerability from github – Published: 2026-04-22 19:22 – Updated: 2026-04-27 16:22
VLAI
Summary
nimiq-transaction: UpdateValidator transactions allows voting key change without proof-of-knowledge
Details

Impact

The staking contract accepts UpdateValidator transactions that set new_voting_key=Some(...) while omitting new_proof_of_knowledge. this skips the proof-of-knowledge requirement that is needed to prevent BLS rogue-key attacks when public keys are aggregated.

Because tendermint macro block justification verification aggregates validator voting keys and verifies a single aggregated BLS signature against that aggregate public key, a rogue-key voting key in the validator set can allow an attacker to forge a quorum-looking justification while only producing a single signature.

While the impact is critical, the exploitability is low: The voting keys are fixed for the epoch, so the attacker would need to know the next epoch validator set (chosen through VRF), which is unlikely.

Patches

The patch for this vulnerability is included as part of v1.3.0.

Workarounds

No known workarounds.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "nimiq-transaction"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34068"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-22T19:22:53Z",
    "nvd_published_at": "2026-04-22T21:17:08Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nThe staking contract accepts `UpdateValidator` transactions that set `new_voting_key=Some(...)` while omitting `new_proof_of_knowledge`. this skips the proof-of-knowledge requirement that is needed to prevent BLS rogue-key attacks when public keys are aggregated.\n\nBecause tendermint macro block justification verification aggregates validator voting keys and verifies a single aggregated BLS signature against that aggregate public key, a rogue-key voting key in the validator set can allow an attacker to forge a quorum-looking justification while only producing a single signature.\n\nWhile the impact is critical, the exploitability is low: The voting keys are fixed for the epoch, so the attacker would need to know the next epoch validator set (chosen through VRF), which is unlikely.\n\n### Patches\n[The patch for this vulnerability](https://github.com/nimiq/core-rs-albatross/commit/e7f0ab7d2115e17d6e5548ddc60f10df1a5d645f) is included as part of [v1.3.0](https://github.com/nimiq/core-rs-albatross/releases/tag/v1.3.0).\n\n### Workarounds\nNo known workarounds.",
  "id": "GHSA-pf4j-pf3w-95f9",
  "modified": "2026-04-27T16:22:49Z",
  "published": "2026-04-22T19:22:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nimiq/core-rs-albatross/security/advisories/GHSA-pf4j-pf3w-95f9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34068"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nimiq/core-rs-albatross/pull/3654"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nimiq/core-rs-albatross/commit/e7f0ab7d2115e17d6e5548ddc60f10df1a5d645f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nimiq/core-rs-albatross"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nimiq/core-rs-albatross/releases/tag/v1.3.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "nimiq-transaction: UpdateValidator transactions allows voting key change without proof-of-knowledge"
}

GHSA-PFRR-XVRF-PXJX

Vulnerability from github – Published: 2024-10-31 18:03 – Updated: 2024-10-31 19:36
VLAI
Summary
Laravel Reverb Missing API Signature Verification
Details

Impact

A community member disclosed an issue where verification signatures for requests sent to Reverb's Pusher-compatible API were not being verified. This API is used in scenarios such as broadcasting a message from a backend service or for obtaining statistical information (such as number of connections) about a given channel.

The verification signature is a hash comprised of different parts of the request signed by the app's secret key. The signature is sent as part of the request and should be regenerated by Reverb. Only when both the signature in the request and the one generated by Reverb match should the request be allowed. This helps to verify the request came from a known source.

[!NOTE]
This issue only affects the Pusher-compatible API endpoints and not the WebSocket connections themselves. In order to exploit this vulnerability, the application ID which, should never be exposed, would need to be known by an attacker.

The following endpoints were affected:

POST /events
POST /events_batch
GET /connections
GET /channels
GET /channel
GET /channel_users
POST /users_terminate

Patches

The issue was resolved by #252 and the patch released in v1.4.0.

References

Generating Pusher authentication signatures

Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "laravel/reverb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-50347"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-10-31T18:03:11Z",
    "nvd_published_at": "2024-10-31T18:15:05Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nA community member disclosed an issue where verification signatures for requests sent to Reverb\u0027s Pusher-compatible API were not being verified. This API is used in scenarios such as broadcasting a message from a backend service or for obtaining statistical information (such as number of connections) about a given channel.\n\nThe verification signature is a hash comprised of different parts of the request signed by the app\u0027s secret key. The signature is sent as part of the request and should be regenerated by Reverb. Only when both the signature in the request and the one generated by Reverb match should the request be allowed. This helps to verify the request came from a known source.\n\n\u003e [!NOTE]  \n\u003e This issue only affects the Pusher-compatible API endpoints and not the WebSocket connections themselves. In order to exploit this vulnerability, the application ID which, should never be exposed, would need to be known by an attacker. \n\nThe following endpoints were affected:\n\n```\nPOST /events\nPOST /events_batch\nGET /connections\nGET /channels\nGET /channel\nGET /channel_users\nPOST /users_terminate\n```\n\n### Patches\nThe issue was resolved by [#252](https://github.com/laravel/reverb/pull/252) and the patch released in [v1.4.0](https://github.com/laravel/reverb/releases/tag/v1.4.0).\n\n### References\n[Generating Pusher authentication signatures](https://pusher.com/docs/channels/library_auth_reference/rest-api/#generating-authentication-signatures)\n",
  "id": "GHSA-pfrr-xvrf-pxjx",
  "modified": "2024-10-31T19:36:22Z",
  "published": "2024-10-31T18:03:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/laravel/reverb/security/advisories/GHSA-pfrr-xvrf-pxjx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50347"
    },
    {
      "type": "WEB",
      "url": "https://github.com/laravel/reverb/pull/252"
    },
    {
      "type": "WEB",
      "url": "https://github.com/laravel/reverb/commit/73cc140d76e803b151fc2dd2e4eb3eb784a82ee2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/laravel/reverb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/laravel/reverb/releases/tag/v1.4.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Laravel Reverb Missing API Signature Verification"
}

GHSA-PFV2-37F7-9M6W

Vulnerability from github – Published: 2022-05-13 01:30 – Updated: 2022-07-01 20:20
VLAI
Summary
Improper Verification of Cryptographic Signature in Nimbus JOSE+JWT
Details

Nimbus JOSE+JWT before 4.36 proceeds with ECKey construction without ensuring that the public x and y coordinates are on the specified curve, which allows attackers to conduct an Invalid Curve Attack in environments where the JCE provider lacks the applicable curve validation.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.nimbusds:nimbus-jose-jwt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.36"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2017-12974"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-07-01T20:20:30Z",
    "nvd_published_at": "2017-08-20T16:29:00Z",
    "severity": "HIGH"
  },
  "details": "Nimbus JOSE+JWT before 4.36 proceeds with ECKey construction without ensuring that the public x and y coordinates are on the specified curve, which allows attackers to conduct an Invalid Curve Attack in environments where the JCE provider lacks the applicable curve validation.",
  "id": "GHSA-pfv2-37f7-9m6w",
  "modified": "2022-07-01T20:20:30Z",
  "published": "2022-05-13T01:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12974"
    },
    {
      "type": "WEB",
      "url": "https://bitbucket.org/connect2id/nimbus-jose-jwt/commits/f3a7a801f0c6b078899fed9226368eb7b44e2b2f"
    },
    {
      "type": "WEB",
      "url": "https://bitbucket.org/connect2id/nimbus-jose-jwt/issues/217/explicit-check-for-ec-public-key-on-curve"
    },
    {
      "type": "WEB",
      "url": "https://bitbucket.org/connect2id/nimbus-jose-jwt/src/master/CHANGELOG.txt"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/felx/nimbus-jose-jwt"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/9317fd092b257a0815434b116a8af8daea6e920b6673f4fd5583d5fe@%3Ccommits.druid.apache.org%3E"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper Verification of Cryptographic Signature in Nimbus JOSE+JWT"
}

GHSA-PFW4-XJGM-267C

Vulnerability from github – Published: 2022-09-15 03:28 – Updated: 2022-09-15 03:28
VLAI
Summary
Dendrite signature checks not applied to some retrieved missing events
Details

Impact

Events retrieved from a remote homeserver using /get_missing_events did not have their signatures verified correctly. This could potentially allow a remote homeserver to provide invalid/modified events to Dendrite via this endpoint.

Note that this does not apply to events retrieved through other endpoints (e.g. /event, /state) as they have been correctly verified.

Homeservers that have federation disabled are not vulnerable.

Patches

The problem has been fixed in Dendrite 0.9.8.

Workarounds

There are no workarounds.

Special thanks

Tulir Asokan, who spotted the issue originally.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/matrix-org/dendrite"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-39200"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-09-15T03:28:01Z",
    "nvd_published_at": "2022-09-12T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nEvents retrieved from a remote homeserver using `/get_missing_events` did not have their signatures verified correctly. This could potentially allow a remote homeserver to provide invalid/modified events to Dendrite via this endpoint.\n\nNote that this does not apply to events retrieved through other endpoints (e.g. `/event`, `/state`) as they have been correctly verified.\n\nHomeservers that have federation disabled are not vulnerable.\n\n### Patches\n\nThe problem has been fixed in Dendrite 0.9.8.\n\n### Workarounds\n\nThere are no workarounds.\n\n### Special thanks\n\nTulir Asokan, who spotted the issue originally.",
  "id": "GHSA-pfw4-xjgm-267c",
  "modified": "2022-09-15T03:28:01Z",
  "published": "2022-09-15T03:28:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/matrix-org/dendrite/security/advisories/GHSA-pfw4-xjgm-267c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39200"
    },
    {
      "type": "WEB",
      "url": "https://github.com/matrix-org/dendrite/commit/2792d0490f3771488bad346981b8c26479a872c3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/matrix-org/dendrite"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Dendrite signature checks not applied to some retrieved missing events"
}

GHSA-PG62-XHHC-55CC

Vulnerability from github – Published: 2026-05-27 18:31 – Updated: 2026-05-29 18:31
VLAI
Details

Northern.tech Mender Client 5 before 5.0.4 allows a Cryptographic signature verification bypass.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-67903"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-27T18:16:21Z",
    "severity": "MODERATE"
  },
  "details": "Northern.tech Mender Client 5 before 5.0.4 allows a Cryptographic signature verification bypass.",
  "id": "GHSA-pg62-xhhc-55cc",
  "modified": "2026-05-29T18:31:16Z",
  "published": "2026-05-27T18:31:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67903"
    },
    {
      "type": "WEB",
      "url": "https://mender.io/blog/cve-2025-67903-signature-verification-bypass-in-mender-client"
    },
    {
      "type": "WEB",
      "url": "https://northern.tech"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "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