CWE-347
AllowedImproper Verification of Cryptographic Signature
Abstraction: Base · Status: Draft
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
1336 vulnerabilities reference this CWE, most recent first.
GHSA-55RJ-X2VC-4WHQ
Vulnerability from github – Published: 2026-05-29 21:32 – Updated: 2026-05-29 21:32Description
The Twilio SMS notifier bridge ships a webhook request parser used to authenticate and decode the status callbacks Twilio 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-Twilio-Signature HMAC header Twilio sends with each request.
As a result, an application that wires up the Twilio 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 status payloads, fake delivered / failed / undelivered events, leading to delivery-metrics fraud, downstream automation triggers, etc.
Resolution
TwilioRequestParser::doParse() now requires and verifies the X-Twilio-Signature header (HMAC-SHA1 over the full request URL concatenated with the alphabetically-sorted POST parameters, base64-encoded, keyed with the Twilio account auth token) before further processing, 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.
Applications behind a TLS-terminating reverse proxy must configure framework.trusted_proxies and framework.trusted_headers so that Request::getUri() returns the public URL Twilio signed.
The patch for this issue is available here for branch 6.4.
Credits
Symfony would like to thank Himanshu Anand for reporting the issue and Nicolas Grekas for providing the fix.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "6.4.0"
},
{
"fixed": "6.4.40"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/symfony"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.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"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/twilio-notifier"
},
"ranges": [
{
"events": [
{
"introduced": "6.4.0"
},
{
"fixed": "6.4.40"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/twilio-notifier"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.4.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "symfony/twilio-notifier"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47212"
],
"database_specific": {
"cwe_ids": [
"CWE-306",
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-29T21:32:23Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Description\n\nThe Twilio SMS notifier bridge ships a webhook request parser used to authenticate and decode the status callbacks Twilio 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-Twilio-Signature` HMAC header Twilio sends with each request.\n\nAs a result, an application that wires up the Twilio 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 status payloads, fake delivered / failed / undelivered events, leading to delivery-metrics fraud, downstream automation triggers, etc.\n\n### Resolution\n\n`TwilioRequestParser::doParse()` now requires and verifies the `X-Twilio-Signature` header (HMAC-SHA1 over the full request URL concatenated with the alphabetically-sorted POST parameters, base64-encoded, keyed with the Twilio account auth token) before further processing, 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\nApplications behind a TLS-terminating reverse proxy must configure `framework.trusted_proxies` and `framework.trusted_headers` so that `Request::getUri()` returns the public URL Twilio signed.\n\nThe patch for this issue is available [here](https://github.com/symfony/symfony/commit/8545fb2af6c07dfb5ef0fc8d9bccf86db2c94356) for branch 6.4.\n\n### Credits\n\nSymfony would like to thank Himanshu Anand for reporting the issue and Nicolas Grekas for providing the fix.",
"id": "GHSA-55rj-x2vc-4whq",
"modified": "2026-05-29T21:32:23Z",
"published": "2026-05-29T21:32:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/symfony/symfony/security/advisories/GHSA-55rj-x2vc-4whq"
},
{
"type": "WEB",
"url": "https://github.com/symfony/symfony/commit/8545fb2af6c07dfb5ef0fc8d9bccf86db2c94356"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-47212.yaml"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/twilio-notifier/CVE-2026-47212.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/symfony/symfony"
},
{
"type": "WEB",
"url": "https://symfony.com/cve-2026-47212"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "Symfony: Twilio SMS Notifier allows unauthenticated webhook injection due to missing X-Twilio-Signature verification"
}
GHSA-55XH-53M6-936R
Vulnerability from github – Published: 2021-06-01 21:17 – Updated: 2026-01-22 20:52Impact
This advisory addresses several LOW severity issues with streaming signed messages and restricting processing of certain types of invalid messages.
This update addresses an issue where certain invalid ECDSA signatures incorrectly passed validation. These signatures provide defense in depth and there is no impact on the integrity of decrypted plaintext.
This ESDK supports a streaming mode where callers may stream the plaintext of signed messages before the ECDSA signature is validated. In addition to these signatures, the ESDK uses AES-GCM encryption and all plaintext is verified before being released to a caller. There is no impact on the integrity of the ciphertext or decrypted plaintext, however some callers may rely on the the ECDSA signature for non-repudiation. Without validating the ECDSA signature, an actor with trusted KMS permissions to decrypt a message may also be able to encrypt messages. This update introduces a new API for callers who wish to stream only unsigned messages.
For customers who process ESDK messages from untrusted sources, this update also introduces a new configuration to limit the number of Encrypted Data Keys (EDKs) that the ESDK will attempt to process per message. This configuration provides customers with a way to limit the number of AWS KMS Decrypt API calls that the ESDK will make per message. This setting will reject messages with more EDKs than the configured limit.
Finally, this update adds early rejection of invalid messages with certain invalid combinations of algorithm suite and header data.
Patches
Fixed in versions 1.9 and 2.2. We recommend that all users upgrade to address these issues.
Customers leveraging the ESDK’s streaming features have several options to protect signature validation. One is to ensure that client code reads to the end of the stream before using released plaintext. With this release, using the new API for streaming and falling back to the non-streaming decrypt API for signed messages prevents using any plaintext from signed data before the signature is validated. See https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/about-versions.html#version2.2.x
Users processing ESDK messages from untrusted sources should use the new maximum encrypted data keys parameter. See https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/about-versions.html#version2.2.x
Workarounds
None
For more information
https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/concepts.html#digital-sigs
https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/about-versions.html#version2.2.x
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.amazonaws:aws-encryption-sdk-java"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.9.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.amazonaws:aws-encryption-sdk-java"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-23680"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2021-06-01T19:14:06Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\nThis advisory addresses several LOW severity issues with streaming signed messages and restricting processing of certain types of invalid messages. \n\nThis update addresses an issue where certain invalid ECDSA signatures incorrectly passed validation. These signatures provide defense in depth and there is no impact on the integrity of decrypted plaintext.\n\nThis ESDK supports a streaming mode where callers may stream the plaintext of signed messages before the ECDSA signature is validated. In addition to these signatures, the ESDK uses AES-GCM encryption and all plaintext is verified before being released to a caller. There is no impact on the integrity of the ciphertext or decrypted plaintext, however some callers may rely on the the ECDSA signature for non-repudiation. Without validating the ECDSA signature, an actor with trusted KMS permissions to decrypt a message may also be able to encrypt messages. This update introduces a new API for callers who wish to stream only unsigned messages. \n\nFor customers who process ESDK messages from untrusted sources, this update also introduces a new configuration to limit the number of Encrypted Data Keys (EDKs) that the ESDK will attempt to process per message. This configuration provides customers with a way to limit the number of AWS KMS Decrypt API calls that the ESDK will make per message. This setting will reject messages with more EDKs than the configured limit.\n\nFinally, this update adds early rejection of invalid messages with certain invalid combinations of algorithm suite and header data.\n\n### Patches\n\nFixed in versions 1.9 and 2.2. We recommend that all users upgrade to address these issues.\n\nCustomers leveraging the ESDK\u2019s streaming features have several options to protect signature validation. One is to ensure that client code reads to the end of the stream before using released plaintext. With this release, using the new API for streaming and falling back to the non-streaming decrypt API for signed messages prevents using any plaintext from signed data before the signature is validated. See https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/about-versions.html#version2.2.x\n\nUsers processing ESDK messages from untrusted sources should use the new maximum encrypted data keys parameter. See https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/about-versions.html#version2.2.x\n\n### Workarounds\n\nNone\n\n### For more information\n\nhttps://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/concepts.html#digital-sigs\n\nhttps://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/about-versions.html#version2.2.x",
"id": "GHSA-55xh-53m6-936r",
"modified": "2026-01-22T20:52:23Z",
"published": "2021-06-01T21:17:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/aws/aws-encryption-sdk-java/security/advisories/GHSA-55xh-53m6-936r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23680"
},
{
"type": "PACKAGE",
"url": "https://github.com/aws/aws-encryption-sdk-java"
},
{
"type": "WEB",
"url": "https://vulncheck.com/advisories/vc-advisory-GHSA-55xh-53m6-936r"
}
],
"schema_version": "1.4.0",
"severity": [
{
"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": "Improper Verification of Cryptographic Signature in aws-encryption-sdk-java"
}
GHSA-567V-8X5M-WXXW
Vulnerability from github – Published: 2022-05-13 00:00 – Updated: 2022-05-24 00:01A firmware update vulnerability exists in the iburn firmware checks functionality of InHand Networks InRouter302 V3.5.37. A specially-crafted HTTP request can lead to firmware update. An attacker can send a sequence of requests to trigger this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2022-26510"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-12T17:15:00Z",
"severity": "MODERATE"
},
"details": "A firmware update vulnerability exists in the iburn firmware checks functionality of InHand Networks InRouter302 V3.5.37. A specially-crafted HTTP request can lead to firmware update. An attacker can send a sequence of requests to trigger this vulnerability.",
"id": "GHSA-567v-8x5m-wxxw",
"modified": "2022-05-24T00:01:32Z",
"published": "2022-05-13T00:00:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26510"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2022-1495"
},
{
"type": "WEB",
"url": "https://www.inhandnetworks.com/upload/attachment/202205/10/InHand-PSA-2022-01.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
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-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-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"
}
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.