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

GHSA-PG94-FQWX-CJCV

Vulnerability from github – Published: 2024-12-13 15:30 – Updated: 2024-12-13 15:30
VLAI
Details

Dell RecoverPoint for Virtual Machines 6.0.x contains an OS Command injection vulnerability. A low privileged remote attacker could potentially exploit this vulnerability by running any command as root, leading to gaining of root-level access and compromise of complete system.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-22461"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347",
      "CWE-78"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-13T14:15:21Z",
    "severity": "HIGH"
  },
  "details": "Dell RecoverPoint for Virtual Machines 6.0.x contains an OS Command injection vulnerability. A low privileged remote attacker could potentially exploit this vulnerability by running any command as root, leading to gaining of root-level access and compromise of complete system.",
  "id": "GHSA-pg94-fqwx-cjcv",
  "modified": "2024-12-13T15:30:39Z",
  "published": "2024-12-13T15:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22461"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000259765/dsa-2024-429-security-update-for-dell-recoverpoint-for-virtual-machines-multiple-third-party-component-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PHGV-CMCV-W837

Vulnerability from github – Published: 2023-12-29 03:30 – Updated: 2026-01-27 18:32
VLAI
Details

Some Honor products are affected by signature management vulnerability, successful exploitation could cause the forged system file overwrite the correct system file

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-2023-23435"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-29T02:15:44Z",
    "severity": "MODERATE"
  },
  "details": "Some Honor products are affected by signature management vulnerability, successful exploitation could cause the forged system file overwrite the correct system file",
  "id": "GHSA-phgv-cmcv-w837",
  "modified": "2026-01-27T18:32:04Z",
  "published": "2023-12-29T03:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23435"
    },
    {
      "type": "WEB",
      "url": "https://www.hihonor.com/global/security/cve-2023-23435"
    }
  ],
  "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-PHHJ-VPF5-5666

Vulnerability from github – Published: 2022-05-24 17:28 – Updated: 2023-02-02 21:33
VLAI
Details

A PGP signature bypass flaw was found in fwupd (all versions), which could lead to the installation of unsigned firmware. As per upstream, a signature bypass is theoretically possible, but not practical because the Linux Vendor Firmware Service (LVFS) is either not implemented or enabled in versions of fwupd shipped with Red Hat Enterprise Linux 7 and 8. The highest threat from this vulnerability is to confidentiality and integrity.

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

{
  "affected": [],
  "aliases": [
    "CVE-2020-10759"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-09-15T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A PGP signature bypass flaw was found in fwupd (all versions), which could lead to the installation of unsigned firmware. As per upstream, a signature bypass is theoretically possible, but not practical because the Linux Vendor Firmware Service (LVFS) is either not implemented or enabled in versions of fwupd shipped with Red Hat Enterprise Linux 7 and 8. The highest threat from this vulnerability is to confidentiality and integrity.",
  "id": "GHSA-phhj-vpf5-5666",
  "modified": "2023-02-02T21:33:41Z",
  "published": "2022-05-24T17:28:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-10759"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:4436"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2020-10759"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1844316"
    },
    {
      "type": "WEB",
      "url": "https://github.com/justinsteven/advisories/blob/master/2020_fwupd_dangling_s3_bucket_and_CVE-2020-10759_signature_verification_bypass.md"
    }
  ],
  "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: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