CWE-347
AllowedImproper Verification of Cryptographic Signature
Abstraction: Base · Status: Draft
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
1481 vulnerabilities reference this CWE, most recent first.
GHSA-56WV-2WR9-3H9R
Vulnerability from github – Published: 2021-10-12 16:30 – Updated: 2025-02-12 18:33An issue was discovered in fastecdsa before 2.1.2. When using the NIST P-256 curve in the ECDSA implementation, the point at infinity is mishandled. This means that for an extreme value in k and s-1, the signature verification fails even if the signature is correct. This behavior is not solely a usability problem. There are some threat models where an attacker can benefit by successfully guessing users for whom signature verification will fail.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "fastecdsa"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-12607"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2021-10-08T22:28:23Z",
"nvd_published_at": "2020-06-02T21:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in fastecdsa before 2.1.2. When using the NIST P-256 curve in the ECDSA implementation, the point at infinity is mishandled. This means that for an extreme value in k and s\u003csup\u003e-1\u003c/sup\u003e, the signature verification fails even if the signature is correct. This behavior is not solely a usability problem. There are some threat models where an attacker can benefit by successfully guessing users for whom signature verification will fail.",
"id": "GHSA-56wv-2wr9-3h9r",
"modified": "2025-02-12T18:33:20Z",
"published": "2021-10-12T16:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12607"
},
{
"type": "WEB",
"url": "https://github.com/AntonKueltz/fastecdsa/issues/52"
},
{
"type": "WEB",
"url": "https://github.com/AntonKueltz/fastecdsa/commit/4a16daeaf139be20654ef58a9fe4c79dc030458c"
},
{
"type": "WEB",
"url": "https://github.com/AntonKueltz/fastecdsa/commit/7b64e3efaa806b4daaf73bb5172af3581812f8de"
},
{
"type": "WEB",
"url": "https://github.com/AntonKueltz/fastecdsa/commit/e592f106edd5acf6dacedfab2ad16fe6c735c9d1"
},
{
"type": "PACKAGE",
"url": "https://github.com/AntonKueltz/fastecdsa"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-56wv-2wr9-3h9r"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/fastecdsa/PYSEC-2020-42.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Improper Verification of Cryptographic Signature in fastecdsa"
}
GHSA-58R4-H6V8-JCVM
Vulnerability from github – Published: 2020-11-03 02:31 – Updated: 2023-05-16 16:04Overview
Versions after and including 2.3.0 are improperly validating the JWT token signature when using the JWTValidator.verify method. Improper validation of the JWT token signature when not using the default Authorization Code Flow can allow an attacker to bypass authentication and authorization.
Am I affected?
You are affected by this vulnerability if all of the following conditions apply:
- You are using
omniauth-auth0. - You are using
JWTValidator.verifymethod directly OR you are not authenticating using the SDK’s default Authorization Code Flow.
How to fix that?
Upgrade to version 2.4.1.
Will this update impact my users?
The fix provided in this version will not affect your users.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "omniauth-auth0"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.4.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-15240"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2020-10-27T19:10:29Z",
"nvd_published_at": "2020-10-21T18:15:00Z",
"severity": "HIGH"
},
"details": "### Overview\nVersions after and including `2.3.0` are improperly validating the JWT token signature when using the `JWTValidator.verify` method. Improper validation of the JWT token signature when not using the default Authorization Code Flow can allow an attacker to bypass authentication and authorization.\n\n### Am I affected?\nYou are affected by this vulnerability if all of the following conditions apply:\n\n- You are using `omniauth-auth0`.\n- You are using `JWTValidator.verify` method directly OR you are not authenticating using the SDK\u2019s default Authorization Code Flow.\n\n### How to fix that?\nUpgrade to version `2.4.1`.\n\n### Will this update impact my users?\nThe fix provided in this version will not affect your users.",
"id": "GHSA-58r4-h6v8-jcvm",
"modified": "2023-05-16T16:04:23Z",
"published": "2020-11-03T02:31:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/auth0/omniauth-auth0/security/advisories/GHSA-58r4-h6v8-jcvm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15240"
},
{
"type": "WEB",
"url": "https://github.com/auth0/omniauth-auth0/commit/fd3a14f4ccdfbc515d1121d6378ff88bf55a7a7a"
},
{
"type": "PACKAGE",
"url": "https://github.com/auth0/omniauth-auth0"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/omniauth-auth0/CVE-2020-15240.yml"
},
{
"type": "WEB",
"url": "https://rubygems.org/gems/omniauth-auth0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Regression in JWT Signature Validation"
}
GHSA-59F3-VP2F-MP9W
Vulnerability from github – Published: 2026-05-28 17:33 – Updated: 2026-05-28 17:33Description
The Mailtrap mailer bridge ships a webhook request parser used to authenticate and decode the event callbacks Mailtrap POSTs to an application's webhook endpoint. Its doParse(Request $request, #[\SensitiveParameter] string $secret) method receives the configured webhook secret but never reads it; it decodes and returns the payload unconditionally, ignoring the X-Mt-Signature HMAC header Mailtrap sends with each request.
As a result, an application that wires up the Mailtrap webhook endpoint accepts any POST to that URL, even when a signing secret is configured (the recommended setup). An attacker who knows the endpoint exists can submit forged event payloads, fake delivery / bounce / open / click / spam events, leading to suppression-list corruption, delivery-metrics fraud, etc.
Resolution
MailtrapRequestParser::doParse() now requires and verifies the X-Mt-Signature header, an HMAC-SHA256 of the raw request body keyed with the configured secret, before decoding the payload, using a constant-time comparison.
When no secret is configured the behaviour is unchanged: signature verification remains opt-in, but it is now actually enforced once opted in.
The patch for this issue is available here for branch 7.4.
Credits
Symfony would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois providing the fix.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/mailtrap-mailer"
},
"ranges": [
{
"events": [
{
"introduced": "7.2.0"
},
{
"fixed": "7.4.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/mailtrap-mailer"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "7.2.0"
},
{
"fixed": "7.4.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45755"
],
"database_specific": {
"cwe_ids": [
"CWE-306",
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-28T17:33:47Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Description\n\nThe Mailtrap mailer bridge ships a webhook request parser used to authenticate and decode the event callbacks Mailtrap POSTs to an application\u0027s webhook endpoint. Its `doParse(Request $request, #[\\SensitiveParameter] string $secret)` method receives the configured webhook secret but never reads it; it decodes and returns the payload unconditionally, ignoring the `X-Mt-Signature` HMAC header Mailtrap sends with each request.\n\nAs a result, an application that wires up the Mailtrap webhook endpoint accepts **any** POST to that URL, even when a signing secret is configured (the recommended setup). An attacker who knows the endpoint exists can submit forged event payloads, fake delivery / bounce / open / click / spam events, leading to suppression-list corruption, delivery-metrics fraud, etc.\n\n### Resolution\n\n`MailtrapRequestParser::doParse()` now requires and verifies the `X-Mt-Signature` header, an HMAC-SHA256 of the raw request body keyed with the configured secret, before decoding the payload, using a constant-time comparison.\n\nWhen no secret is configured the behaviour is unchanged: signature verification remains opt-in, but it is now actually enforced once opted in.\n\nThe patch for this issue is available [here](https://github.com/symfony/symfony/commit/4e0467e4e182cf2e704a3d9e1bc1a6be65d52ab8) for branch 7.4.\n\n### Credits\n\nSymfony would like to thank Himanshu Anand for reporting the issue and Alexandre Daubois providing the fix.",
"id": "GHSA-59f3-vp2f-mp9w",
"modified": "2026-05-28T17:33:47Z",
"published": "2026-05-28T17:33:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/symfony/symfony/security/advisories/GHSA-59f3-vp2f-mp9w"
},
{
"type": "WEB",
"url": "https://github.com/symfony/symfony/commit/4e0467e4e182cf2e704a3d9e1bc1a6be65d52ab8"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/mailtrap-mailer/CVE-2026-45755.yaml"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-45755.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/symfony/symfony"
},
{
"type": "WEB",
"url": "https://symfony.com/cve-2026-45755"
}
],
"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/E:U",
"type": "CVSS_V4"
}
],
"summary": "Symfony\u0027s Mailtrap Mailer Webhook Parser Never Verifies the X-Mt-Signature HMAC \u2014 Unauthenticated Webhook Event Injection"
}
GHSA-59WW-7VHF-HJ2Q
Vulnerability from github – Published: 2026-08-27 18:32 – Updated: 2026-08-27 18:32openssl_encrypt versions before 1.4.9 fail to authenticate recovery-slot presence in envelope-format encrypted files, allowing attackers to remove recovery slots without re-encrypting the payload. Attackers can modify the file header to delete recovery-slot fields and bypass authentication, silently removing recovery paths the owner deliberately added.
{
"affected": [],
"aliases": [
"CVE-2026-81680"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-27T17:20:57Z",
"severity": "CRITICAL"
},
"details": "openssl_encrypt versions before 1.4.9 fail to authenticate recovery-slot presence in envelope-format encrypted files, allowing attackers to remove recovery slots without re-encrypting the payload. Attackers can modify the file header to delete recovery-slot fields and bypass authentication, silently removing recovery paths the owner deliberately added.",
"id": "GHSA-59ww-7vhf-hj2q",
"modified": "2026-08-27T18:32:26Z",
"published": "2026-08-27T18:32:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jahlives/openssl_encrypt/security/advisories/GHSA-grhj-cpmg-f5mx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81680"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openssl-encrypt-before-1.4.9-authentication-bypass-via-recovery-slot-removal"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"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/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-5HPF-PC4X-3JCF
Vulnerability from github – Published: 2026-06-26 00:32 – Updated: 2026-06-27 21:30HMAC zero-length tag forgery in EVP_DigestVerifyFinal, where a zero-length tag could be accepted as valid during HMAC verification. In the OpenSSL-compatibility HMAC verify path the supplied signature length was only checked as not exceeding the MAC length, so a zero-length or otherwise truncated tag could pass verification. The fix requires the supplied tag length to exactly equal the MAC length and rejects a zero-length MAC, so a forged short or empty tag is no longer accepted.
{
"affected": [],
"aliases": [
"CVE-2026-6331"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-25T22:17:03Z",
"severity": "LOW"
},
"details": "HMAC zero-length tag forgery in EVP_DigestVerifyFinal, where a zero-length tag could be accepted as valid during HMAC verification. In the OpenSSL-compatibility HMAC verify path the supplied signature length was only checked as not exceeding the MAC length, so a zero-length or otherwise truncated tag could pass verification. The fix requires the supplied tag length to exactly equal the MAC length and rejects a zero-length MAC, so a forged short or empty tag is no longer accepted.",
"id": "GHSA-5hpf-pc4x-3jcf",
"modified": "2026-06-27T21:30:28Z",
"published": "2026-06-26T00:32:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6331"
},
{
"type": "WEB",
"url": "https://github.com/wolfSSL/wolfssl/pull/10192"
},
{
"type": "WEB",
"url": "https://www.wolfssl.com/docs/security-vulnerabilities"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:N/VC:N/VI:L/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-5J98-2G5X-46V6
Vulnerability from github – Published: 2026-10-05 22:54 – Updated: 2026-10-05 22:54When calling Resolver::lookup() or Resolver::lookup_ip() on a resolver with DNSSEC validation enabled, both methods return Ok(...) if DNSSEC validation fails. It is possible but very inconvenient to check the validation status of individual records. These methods should instead return an error when DNSSEC validation determines a response is bogus.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "hickory-resolver"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.26.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-05T22:54:35Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "When calling `Resolver::lookup()` or `Resolver::lookup_ip()` on a resolver with DNSSEC validation enabled, both methods return `Ok(...)` if DNSSEC validation fails. It is possible but very inconvenient to check the validation status of individual records. These methods should instead return an error when DNSSEC validation determines a response is bogus.",
"id": "GHSA-5j98-2g5x-46v6",
"modified": "2026-10-05T22:54:35Z",
"published": "2026-10-05T22:54:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-5j98-2g5x-46v6"
},
{
"type": "WEB",
"url": "https://github.com/hickory-dns/hickory-dns/pull/3871"
},
{
"type": "WEB",
"url": "https://github.com/hickory-dns/hickory-dns/commit/92f93c0b889f6a292bc943304d88c4c6561fe1b9"
},
{
"type": "PACKAGE",
"url": "https://github.com/hickory-dns/hickory-dns"
},
{
"type": "WEB",
"url": "https://github.com/hickory-dns/hickory-dns/releases/tag/v0.26.2"
}
],
"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": "hickory-resolver: Resolver::lookup() and Resolver::lookup_ip() APIs obscure DNSSEC validation failures"
}
GHSA-5M98-CGCR-XX3Q
Vulnerability from github – Published: 2026-09-10 21:06 – Updated: 2026-09-10 21:06Impact
The GitHub Trigger generated a signing secret when it registered a webhook and verified X-Hub-Signature-256 on each delivery. When GitHub answered the create request with a 422 because a webhook for the URL already existed, the node adopted the remote hook but kept only its id and events, discarding the secret it had generated. Deliveries to that workflow's webhook URL were then accepted from anyone. The patch re-fetches the existing hook by its stored id, re-applies the signing secret, and makes verification fail closed when no secret is stored.
Patches
The issue has been fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2. Users should upgrade to one of these versions or later to remediate the vulnerability.
Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Deactivate and reactivate any GitHub Trigger workflows to force a fresh webhook registration with a new secret, provided the remote GitHub hook has been deleted first so that the 422 reuse path is not taken again.
- Restrict network access to the n8n webhook endpoint to GitHub's published IP ranges only.
- Audit GitHub Trigger workflow static data for entries that contain a webhookId but no webhookSecret, and treat those workflows as unprotected until reactivated successfully.
These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "n8n"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.123.76"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "n8n"
},
"ranges": [
{
"events": [
{
"introduced": "2.38.0"
},
{
"fixed": "2.38.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "n8n"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.37.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-86080"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-10T21:06:37Z",
"nvd_published_at": "2026-09-08T22:19:16Z",
"severity": "MODERATE"
},
"details": "## Impact\n\nThe GitHub Trigger generated a signing secret when it registered a webhook and verified `X-Hub-Signature-256` on each delivery. When GitHub answered the create request with a 422 because a webhook for the URL already existed, the node adopted the remote hook but kept only its id and events, discarding the secret it had generated. Deliveries to that workflow\u0027s webhook URL were then accepted from anyone. The patch re-fetches the existing hook by its stored id, re-applies the signing secret, and makes verification fail closed when no secret is stored.\n\n## Patches\n\nThe issue has been fixed in n8n versions 1.123.76, 2.37.7, and 2.38.2. Users should upgrade to one of these versions or later to remediate the vulnerability.\n\n## Workarounds\n\nIf upgrading is not immediately possible, administrators should consider the following temporary mitigations:\n- Deactivate and reactivate any GitHub Trigger workflows to force a fresh webhook registration with a new secret, provided the remote GitHub hook has been deleted first so that the 422 reuse path is not taken again.\n- Restrict network access to the n8n webhook endpoint to GitHub\u0027s published IP ranges only.\n- Audit GitHub Trigger workflow static data for entries that contain a `webhookId` but no `webhookSecret`, and treat those workflows as unprotected until reactivated successfully.\n\nThese workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.",
"id": "GHSA-5m98-cgcr-xx3q",
"modified": "2026-09-10T21:06:37Z",
"published": "2026-09-10T21:06:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-5m98-cgcr-xx3q"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-86080"
},
{
"type": "PACKAGE",
"url": "https://github.com/n8n-io/n8n"
},
{
"type": "WEB",
"url": "https://github.com/n8n-io/n8n/releases/tag/n8n@1.123.76"
},
{
"type": "WEB",
"url": "https://github.com/n8n-io/n8n/releases/tag/n8n@2.37.7"
},
{
"type": "WEB",
"url": "https://github.com/n8n-io/n8n/releases/tag/n8n@2.38.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "n8n: GitHub Trigger 422 Reuse Path Skips Webhook Secret Storage, Causing Signature Verification to Fail-Open"
}
GHSA-5M9Q-364F-FV6C
Vulnerability from github – Published: 2022-05-24 17:19 – Updated: 2024-04-04 02:51A vulnerability in software image verification in Cisco IOS XE Software could allow an unauthenticated, physical attacker to install and boot a malicious software image or execute unsigned binaries on an affected device. The vulnerability is due to an improper check on the area of code that manages the verification of the digital signatures of system image files during the initial boot process. An attacker could exploit this vulnerability by loading unsigned software on an affected device. A successful exploit could allow the attacker to install and boot a malicious software image or execute unsigned binaries on the targeted device.
{
"affected": [],
"aliases": [
"CVE-2020-3209"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-06-03T18:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in software image verification in Cisco IOS XE Software could allow an unauthenticated, physical attacker to install and boot a malicious software image or execute unsigned binaries on an affected device. The vulnerability is due to an improper check on the area of code that manages the verification of the digital signatures of system image files during the initial boot process. An attacker could exploit this vulnerability by loading unsigned software on an affected device. 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-5m9q-364f-fv6c",
"modified": "2024-04-04T02:51:53Z",
"published": "2022-05-24T17:19:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-3209"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxe-digsig-bypass-FYQ3bmVq"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5MFP-688H-G4R8
Vulnerability from github – Published: 2026-10-06 09:31 – Updated: 2026-10-06 09:31Cryptographic Issue when processing non-ELF partitions, authentication and signature checks are bypassed, allowing unsigned or corrupted images to be mounted and processed.
{
"affected": [],
"aliases": [
"CVE-2026-25302"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-06T07:16:58Z",
"severity": "HIGH"
},
"details": "Cryptographic Issue when processing non-ELF partitions, authentication and signature checks are bypassed, allowing unsigned or corrupted images to be mounted and processed.",
"id": "GHSA-5mfp-688h-g4r8",
"modified": "2026-10-06T09:31:23Z",
"published": "2026-10-06T09:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25302"
},
{
"type": "WEB",
"url": "https://docs.qualcomm.com/product/publicresources/securitybulletin/october-2026-bulletin.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5P3X-R448-PC62
Vulnerability from github – Published: 2021-01-21 14:12 – Updated: 2024-10-14 15:41Impact
All users of pysaml2 that use the default CryptoBackendXmlSec1 backend and need to verify signed SAML documents are impacted. pysaml2 <= 6.4.1 does not ensure that a signed SAML document is correctly signed. The default CryptoBackendXmlSec1 backend is using the xmlsec1 binary to verify the signature of signed SAML documents, but by default, xmlsec1 accepts any type of key found within the given document. xmlsec1 needs to be configured explicitly to only use only x509 certificates for the verification process of the SAML document signature.
Patches
Users should upgrade to pysaml2 v6.5.0.
Workarounds
No workaround provided at this point.
References
This issue has been reported in the past at the xmlsec1 mailing list: https://www.aleksey.com/pipermail/xmlsec/2013/009717.html
Credits
- Brian Wolff
For more information
If you have any questions or comments about this advisory: * Open an issue in pysaml2 * Email us at the incident-response address
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "pysaml2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.5.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-21239"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2021-01-21T14:11:58Z",
"nvd_published_at": "2021-01-21T15:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nAll users of pysaml2 that use the default `CryptoBackendXmlSec1` backend and need to verify signed SAML documents are impacted. `pysaml2 \u003c= 6.4.1` does not ensure that a signed SAML document is correctly signed. The default `CryptoBackendXmlSec1` backend is using the `xmlsec1` binary to verify the signature of signed SAML documents, but by default, `xmlsec1` accepts any type of key found within the given document. `xmlsec1` needs to be configured explicitly to only use only _x509 certificates_ for the verification process of the SAML document signature.\n\n### Patches\n\nUsers should upgrade to pysaml2 `v6.5.0`.\n\n### Workarounds\n\nNo workaround provided at this point.\n\n### References\n\nThis issue has been reported in the past at the xmlsec1 mailing list:\nhttps://www.aleksey.com/pipermail/xmlsec/2013/009717.html\n\n### Credits\n\n- Brian Wolff\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue in [pysaml2](https://github.com/IdentityPython/pysaml2)\n* Email us at [the incident-response address](mailto:incident-response@idpy.org)\n",
"id": "GHSA-5p3x-r448-pc62",
"modified": "2024-10-14T15:41:51Z",
"published": "2021-01-21T14:12:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/IdentityPython/pysaml2/security/advisories/GHSA-5p3x-r448-pc62"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21239"
},
{
"type": "WEB",
"url": "https://github.com/IdentityPython/pysaml2/commit/46578df0695269a16f1c94171f1429873f90ed99"
},
{
"type": "PACKAGE",
"url": "https://github.com/IdentityPython/pysaml2"
},
{
"type": "WEB",
"url": "https://github.com/IdentityPython/pysaml2/releases/tag/v6.5.0"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/pysaml2/PYSEC-2021-49.yaml"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/02/msg00038.html"
},
{
"type": "WEB",
"url": "https://pypi.org/project/pysaml2"
},
{
"type": "WEB",
"url": "https://www.aleksey.com/pipermail/xmlsec/2013/009717.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Improper Verification of Cryptographic Signature in PySAML2"
}
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.