CWE-347
AllowedImproper Verification of Cryptographic Signature
Abstraction: Base · Status: Draft
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
1128 vulnerabilities reference this CWE, most recent first.
GHSA-5684-G483-2249
Vulnerability from github – Published: 2021-05-24 16:59 – Updated: 2021-10-05 17:07Impact
Given a valid SAML Response, an attacker can potentially modify the document, bypassing signature validation in order to pass off the altered document as a signed one.
This enables a variety of attacks, including users accessing accounts other than the one to which they authenticated in the identity provider, or full authentication bypass if an external attacker can obtain an expired, signed SAML Response.
Patches
A patch is available, users of gosaml2 should upgrade to v0.5.0 or higher.
References
See the underlying advisory on goxmldsig for more details.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/russellhaering/gosaml2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.5.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-21T22:17:56Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Impact\nGiven a valid SAML Response, an attacker can potentially modify the document, bypassing signature validation in order to pass off the altered document as a signed one.\n\nThis enables a variety of attacks, including users accessing accounts other than the one to which they authenticated in the identity provider, or full authentication bypass if an external attacker can obtain an expired, signed SAML Response.\n\n### Patches\nA patch is available, users of gosaml2 should upgrade to v0.5.0 or higher.\n\n### References\nSee the [underlying advisory on goxmldsig](https://github.com/russellhaering/goxmldsig/security/advisories/GHSA-q547-gmf8-8jr7) for more details.",
"id": "GHSA-5684-g483-2249",
"modified": "2021-10-05T17:07:09Z",
"published": "2021-05-24T16:59:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/russellhaering/gosaml2/security/advisories/GHSA-5684-g483-2249"
},
{
"type": "PACKAGE",
"url": "https://github.com/russellhaering/gosaml2"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Signature Validation Bypass"
}
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-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-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-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"
}
GHSA-5P8W-2MVW-38PV
Vulnerability from github – Published: 2022-10-12 22:05 – Updated: 2022-10-14 19:48Impact
A remote attacker may be able to bypass SAML authentication on a website using passport-saml. A successful attack requires that the attacker is in possession of an arbitrary IDP signed XML element. Depending on the IDP used, fully unauthenticated attacks (e.g without access to a valid user) might also be feasible if generation of a signed message can be triggered.
Patches
Users should upgrade to node-saml v4.0.0-beta5 or newer.
Workarounds
Disable SAML authentication.
References
Are there any links users can visit to find out more?
For more information
If you have any questions or comments about this advisory: * Open a discussion in the node-saml repo
Credits
- Felix Wilhelm of Google Project Zero
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "node-saml"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.0.0-beta.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-39300"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2022-10-12T22:05:44Z",
"nvd_published_at": "2022-10-13T22:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\n\nA remote attacker may be able to bypass SAML authentication on a website using passport-saml. A successful attack requires that the attacker is in possession of an arbitrary IDP signed XML element. Depending on the IDP used, fully unauthenticated attacks (e.g without access to a valid user) might also be feasible if generation of a signed message can be triggered.\n\n### Patches\n\nUsers should upgrade to node-saml v4.0.0-beta5 or newer. \n\n### Workarounds\n\nDisable SAML authentication.\n\n### References\n_Are there any links users can visit to find out more?_\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open a discussion in the [node-saml repo](https://github.com/node-saml/node-saml/discussions)\n\n### Credits\n\n* Felix Wilhelm of Google Project Zero\n\n",
"id": "GHSA-5p8w-2mvw-38pv",
"modified": "2022-10-14T19:48:04Z",
"published": "2022-10-12T22:05:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/node-saml/node-saml/security/advisories/GHSA-5p8w-2mvw-38pv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39300"
},
{
"type": "WEB",
"url": "https://github.com/node-saml/node-saml/commit/c1f275c289c01921e58f5c70ce0fdbc5287e5fbe"
},
{
"type": "PACKAGE",
"url": "https://github.com/node-saml/node-saml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Signature bypass via multiple root elements"
}
GHSA-5PJ9-G7QW-3QWV
Vulnerability from github – Published: 2024-01-04 12:30 – Updated: 2024-01-04 12:30A vulnerability exists in the Relion update package signature validation. A tampered update package could cause the IED to restart. After restart the device is back to normal operation. An attacker could exploit the vulnerability by first gaining access to the system with security privileges and attempt to update the IED with a malicious update package. Successful exploitation of this vulnerability will cause the IED to restart, causing a temporary Denial of Service.
{
"affected": [],
"aliases": [
"CVE-2022-3864"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-04T10:15:11Z",
"severity": "MODERATE"
},
"details": "\nA vulnerability exists in the Relion update package signature validation. A tampered update package could cause the IED to restart. After restart the device is back to normal operation.\nAn attacker could exploit the vulnerability by first gaining access to\nthe system with security privileges and attempt to update the IED\nwith a malicious update package. Successful exploitation of this\nvulnerability will cause the IED to restart, causing a temporary Denial of Service.\n\n",
"id": "GHSA-5pj9-g7qw-3qwv",
"modified": "2024-01-04T12:30:20Z",
"published": "2024-01-04T12:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3864"
},
{
"type": "WEB",
"url": "https://publisher.hitachienergy.com/preview?DocumentID=8DBD000146\u0026LanguageCode=en\u0026DocumentPartId=\u0026Action=Launch"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-5PQ9-5MPR-JJ85
Vulnerability from github – Published: 2026-01-13 14:56 – Updated: 2026-01-21 16:23Vulnerability
https://github.com/samrocketman/jervis/blob/157d2b63ffa5c4bb1d8ee2254950fd2231de2b05/src/main/groovy/net/gleske/jervis/tools/SecurityIO.groovy#L244-L249
The code doesn't validate that the JWT header specifies "alg":"RS256".
Impact
Depending on the broader system, this could allow JWT forgery.
Internally this severity is low since JWT is only intended to interface with GitHub. External users should consider severity moderate.
Patches
Jervis patch will explicitly verify the algorithm in the header matches expectations and further verify the JWT structure.
Upgrade to Jervis 2.2.
Workarounds
External users should consider using an alternate JWT library or upgrade.
References
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "net.gleske:jervis"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-68925"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-13T14:56:04Z",
"nvd_published_at": "2026-01-13T20:16:07Z",
"severity": "MODERATE"
},
"details": "### Vulnerability\n\nhttps://github.com/samrocketman/jervis/blob/157d2b63ffa5c4bb1d8ee2254950fd2231de2b05/src/main/groovy/net/gleske/jervis/tools/SecurityIO.groovy#L244-L249\n\nThe code doesn\u0027t validate that the JWT header specifies `\"alg\":\"RS256\"`.\n\n### Impact\n\nDepending on the broader system, this could allow JWT forgery.\n\nInternally this severity is low since JWT is only intended to interface with GitHub. External users should consider severity moderate.\n\n### Patches\n\nJervis patch will explicitly verify the algorithm in the header matches expectations and further verify the JWT structure.\n\nUpgrade to Jervis 2.2.\n\n### Workarounds\n\nExternal users should consider using an alternate JWT library or upgrade.\n\n### References\n\n- [RFC 7518: JSON Web Algorithms](https://datatracker.ietf.org/doc/html/rfc7518)",
"id": "GHSA-5pq9-5mpr-jj85",
"modified": "2026-01-21T16:23:33Z",
"published": "2026-01-13T14:56:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/samrocketman/jervis/security/advisories/GHSA-5pq9-5mpr-jj85"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68925"
},
{
"type": "WEB",
"url": "https://github.com/samrocketman/jervis/commit/c3981ff71de7b0f767dfe7b37a2372cb2a51974a"
},
{
"type": "PACKAGE",
"url": "https://github.com/samrocketman/jervis"
},
{
"type": "WEB",
"url": "https://github.com/samrocketman/jervis/blob/157d2b63ffa5c4bb1d8ee2254950fd2231de2b05/src/main/groovy/net/gleske/jervis/tools/SecurityIO.groovy#L244-L249"
},
{
"type": "WEB",
"url": "http://github.com/samrocketman/jervis/commit/c3981ff71de7b0f767dfe7b37a2372cb2a51974a"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/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:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Jervis Has a JWT Algorithm Confusion Vulnerability"
}
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.