Common Weakness Enumeration

CWE-347

Allowed

Improper Verification of Cryptographic Signature

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product does not verify, or incorrectly verifies, the cryptographic signature for data.

1121 vulnerabilities reference this CWE, most recent first.

GHSA-RRFW-HG9M-J47H

Vulnerability from github – Published: 2021-05-24 16:59 – Updated: 2021-10-08 21:25
VLAI
Summary
Signature Validation Bypass
Details

Impact

An authentication bypass exists in the goxmldsig this library uses to determine if SAML assertions are genuine. An attacker could craft a SAML response that would appear to be valid but would not have been genuinely issued by the IDP.

Patches

Version 0.4.2 bumps the dependency which should fix the issue.

For more information

Please see the advisory in goxmldsig

Credits

The original vulnerability was discovered by @jupenur. Thanks to @russellhaering for the heads up.

Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.4.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/russellhaering/goxmldsig"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-21T22:23:03Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Impact\n\nAn authentication bypass exists in the [goxmldsig](https://github.com/russellhaering/goxmldsig/security/advisories/GHSA-q547-gmf8-8jr7) this library uses to determine if SAML assertions are genuine. An attacker could craft a SAML response that would appear to be valid but would not have been genuinely issued by the IDP.\n\n### Patches\n\nVersion 0.4.2 bumps the dependency which should fix the issue.\n\n### For more information\n\nPlease see [the advisory in goxmldsig](https://github.com/russellhaering/goxmldsig/security/advisories/GHSA-q547-gmf8-8jr7)\n\n## Credits\n\nThe original vulnerability was discovered by @jupenur. Thanks to @russellhaering for the heads up.",
  "id": "GHSA-rrfw-hg9m-j47h",
  "modified": "2021-10-08T21:25:26Z",
  "published": "2021-05-24T16:59:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/crewjam/saml/security/advisories/GHSA-rrfw-hg9m-j47h"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/russellhaering/goxmldsig"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Signature Validation Bypass"
}

GHSA-RRJ9-5Q2J-4GVR

Vulnerability from github – Published: 2026-06-15 17:32 – Updated: 2026-06-15 17:32
VLAI
Summary
Symfony: Mailomat Mailer Webhook Parser Reads the HMAC Algorithm from the Request: Signature Algorithm Downgrade
Details

Description

Symfony\Component\Mailer\Bridge\Mailomat\Webhook\MailomatRequestParser::validateSignature() parses the X-MOM-Webhook-Signature request header as algo=signature and passes the wire-supplied $algo directly to hash_hmac() when verifying the request against the configured webhook secret. The request therefore selects the HMAC primitive used to authenticate it.

PHP's hash_hmac() enforces only that the chosen algorithm is HMAC-compatible. That set still includes primitives with known cryptanalysis (md4, md5, ripemd128, tiger128,3, … — e.g. existential forgery of HMAC-MD4, Contini & Yin, ASIACRYPT 2006). This is the canonical algorithm-confusion shape, analogous to JWT alg=none / alg=HS256 downgrades: any future cryptographic weakness in any HMAC primitive PHP exposes becomes immediately exploitable against a Mailomat webhook receiver, the moment an attacker is in a position to compute a signature for that primitive, without a code change on the Symfony side.

Mailomat's documented webhook security pins SHA-256; the parser did not.

Resolution

MailomatRequestParser::validateSignature() now requires the signature header to be of the form sha256=<hex> and verifies the signature with HMAC-SHA256 keyed by the configured secret using a constant-time comparison. Any other algorithm declared on the wire (including the HMAC primitives PHP would otherwise accept) is rejected.

The patch for this issue is available here for branch 7.4 (and forward-ported to 8.0 and 8.1).

Credits

Symfony would like to thank Omar Alshammari, Essam Alanazi and Alwaleed Alshammari for reporting the issue and Nicolas Grekas for providing the fix.

Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/mailomat-mailer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.2.0"
            },
            {
              "fixed": "7.4.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/mailomat-mailer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.0.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/symfony"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.2.0"
            },
            {
              "fixed": "7.4.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/symfony"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.0.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48747"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347",
      "CWE-757"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-15T17:32:28Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Description\n\n`Symfony\\Component\\Mailer\\Bridge\\Mailomat\\Webhook\\MailomatRequestParser::validateSignature()` parses the `X-MOM-Webhook-Signature` request header as `algo=signature` and passes the wire-supplied `$algo` directly to `hash_hmac()` when verifying the request against the configured webhook secret. The request therefore selects the HMAC primitive used to authenticate it.\n\nPHP\u0027s `hash_hmac()` enforces only that the chosen algorithm is HMAC-compatible. That set still includes primitives with known cryptanalysis (`md4`, `md5`, `ripemd128`, `tiger128,3`, \u2026 \u2014 e.g. existential forgery of HMAC-MD4, Contini \u0026 Yin, ASIACRYPT 2006). This is the canonical algorithm-confusion shape, analogous to JWT `alg=none` / `alg=HS256` downgrades: any future cryptographic weakness in any HMAC primitive PHP exposes becomes immediately exploitable against a Mailomat webhook receiver, the moment an attacker is in a position to compute a signature for that primitive, without a code change on the Symfony side.\n\nMailomat\u0027s [documented webhook security](https://api.mailomat.swiss/docs/#tag/webhook-security) pins SHA-256; the parser did not.\n\n### Resolution\n\n`MailomatRequestParser::validateSignature()` now requires the signature header to be of the form `sha256=\u003chex\u003e` and verifies the signature with HMAC-SHA256 keyed by the configured secret using a constant-time comparison. Any other algorithm declared on the wire (including the HMAC primitives PHP would otherwise accept) is rejected.\n\nThe patch for this issue is available [here](https://github.com/symfony/symfony/commit/bdfe9fe0d94d33dfaca0bc2fe0b00b54767b0c88) for branch 7.4 (and forward-ported to 8.0 and 8.1).\n\n### Credits\n\nSymfony would like to thank Omar Alshammari, Essam Alanazi and Alwaleed Alshammari for reporting the issue and Nicolas Grekas for providing the fix.",
  "id": "GHSA-rrj9-5q2j-4gvr",
  "modified": "2026-06-15T17:32:28Z",
  "published": "2026-06-15T17:32:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/symfony/symfony/security/advisories/GHSA-rrj9-5q2j-4gvr"
    },
    {
      "type": "WEB",
      "url": "https://github.com/symfony/symfony/commit/bdfe9fe0d94d33dfaca0bc2fe0b00b54767b0c88"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/mailomat-mailer/CVE-2026-48747.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2026-48747.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/symfony/symfony"
    },
    {
      "type": "WEB",
      "url": "https://symfony.com/cve-2026-48747"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Symfony: Mailomat Mailer Webhook Parser Reads the HMAC Algorithm from the Request: Signature Algorithm Downgrade"
}

GHSA-RV9G-67F7-GRQ7

Vulnerability from github – Published: 2022-05-24 17:10 – Updated: 2023-01-14 05:24
VLAI
Summary
Missing SSH host key validation in Mac Plugin
Details

Mac Plugin 1.1.0 and earlier does not use SSH host key validation when connecting to Mac Cloud host launched by the plugin. This lack of validation could be abused using a man-in-the-middle attack to intercept these connections to build agents.

Mac Plugin 1.2.0 validates SSH host keys when connecting to agents.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "fr.edf.jenkins.plugins:mac"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-2146"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-01-14T05:24:25Z",
    "nvd_published_at": "2020-03-09T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Mac Plugin 1.1.0 and earlier does not use SSH host key validation when connecting to Mac Cloud host launched by the plugin. This lack of validation could be abused using a man-in-the-middle attack to intercept these connections to build agents.\n\nMac Plugin 1.2.0 validates SSH host keys when connecting to agents.",
  "id": "GHSA-rv9g-67f7-grq7",
  "modified": "2023-01-14T05:24:25Z",
  "published": "2022-05-24T17:10:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-2146"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/mac-plugin/commit/ba1a8206c7ef990d37498e5abdf210990ef046b5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/mac-plugin"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2020-03-09/#SECURITY-1692"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2020/03/09/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Missing SSH host key validation in Mac Plugin"
}

GHSA-RW54-6826-C8J5

Vulnerability from github – Published: 2023-12-18 19:34 – Updated: 2023-12-22 22:24
VLAI
Summary
yiisoft/yii2-authclient's Oauth2 PKCE implementation is vulnerable
Details

Impact

What kind of vulnerability is it? Who is impacted?

Original Report:

The Oauth2 PKCE implementation is vulnerable in 2 ways: 1. The authCodeVerifier should be removed after usage (similar to 'authState') 2. There is a risk for a "downgrade attack" if PKCE is being relied on for CSRF protection.

Patches

Has the problem been patched? What versions should users upgrade to?

2.2.15

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

not known yet.

References

Are there any links users can visit to find out more?

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "yiisoft/yii2-authclient"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-50714"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-12-18T19:34:20Z",
    "nvd_published_at": "2023-12-22T19:15:09Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nOriginal Report:\n\n\u003e The Oauth2 PKCE implementation is vulnerable in 2 ways:\n\u003e 1. The `authCodeVerifier` should be removed after usage (similar to \u0027authState\u0027)\n\u003e 2. There is a risk for a \"downgrade attack\" if PKCE is being relied on for CSRF protection.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\n2.2.15\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nnot known yet.\n\n### References\n_Are there any links users can visit to find out more?_\n",
  "id": "GHSA-rw54-6826-c8j5",
  "modified": "2023-12-22T22:24:09Z",
  "published": "2023-12-18T19:34:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/yiisoft/yii2-authclient/security/advisories/GHSA-rw54-6826-c8j5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50714"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yiisoft/yii2-authclient/commit/721ed974bc44137437b0cdc8454e137fff8db213"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/yiisoft/yii2-authclient"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yiisoft/yii2-authclient/blob/0d1c3880f4d79e20aa1d77c012650b54e69695ff/src/OAuth1.php#L158"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yiisoft/yii2-authclient/blob/0d1c3880f4d79e20aa1d77c012650b54e69695ff/src/OAuth2.php#L121"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yiisoft/yii2-authclient/blob/0d1c3880f4d79e20aa1d77c012650b54e69695ff/src/OpenIdConnect.php#L420"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "yiisoft/yii2-authclient\u0027s Oauth2 PKCE implementation is vulnerable"
}

GHSA-RXF8-59CM-76J2

Vulnerability from github – Published: 2022-05-24 16:46 – Updated: 2024-04-04 00:42
VLAI
Details

Enigmail before 2.0.11 allows PGP signature spoofing: for an inline PGP message, an attacker can cause the product to display a "correctly signed" message indication, but display different unauthenticated text.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-12269"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-05-21T20:29:00Z",
    "severity": "HIGH"
  },
  "details": "Enigmail before 2.0.11 allows PGP signature spoofing: for an inline PGP message, an attacker can cause the product to display a \"correctly signed\" message indication, but display different unauthenticated text.",
  "id": "GHSA-rxf8-59cm-76j2",
  "modified": "2024-04-04T00:42:57Z",
  "published": "2022-05-24T16:46:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-12269"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/AVNTEF3WSOOQYKMIPEH7F77UPXES5BU5"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/CYWBJHSBBLAHKMRWDWH2XXQDYAGDHB5I"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GHC5WDQ47FQSL5CTGQUYIHVC3RNZ7UH5"
    },
    {
      "type": "WEB",
      "url": "https://sourceforge.net/p/enigmail/bugs/983"
    },
    {
      "type": "WEB",
      "url": "https://www.enigmail.net/index.php/en/download/changelog"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-06/msg00061.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V2VR-926Q-29FR

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

Issue summary: The 'openssl dgst' command-line tool silently truncates input data to 16MB when using one-shot signing algorithms and reports success instead of an error.

Impact summary: A user signing or verifying files larger than 16MB with one-shot algorithms (such as Ed25519, Ed448, or ML-DSA) may believe the entire file is authenticated while trailing data beyond 16MB remains unauthenticated.

When the 'openssl dgst' command is used with algorithms that only support one-shot signing (Ed25519, Ed448, ML-DSA-44, ML-DSA-65, ML-DSA-87), the input is buffered with a 16MB limit. If the input exceeds this limit, the tool silently truncates to the first 16MB and continues without signaling an error, contrary to what the documentation states. This creates an integrity gap where trailing bytes can be modified without detection if both signing and verification are performed using the same affected codepath.

The issue affects only the command-line tool behavior. Verifiers that process the full message using library APIs will reject the signature, so the risk primarily affects workflows that both sign and verify with the affected 'openssl dgst' command. Streaming digest algorithms for 'openssl dgst' and library users are unaffected.

The FIPS modules in 3.5 and 3.6 are not affected by this issue, as the command-line tools are outside the OpenSSL FIPS module boundary.

OpenSSL 3.5 and 3.6 are vulnerable to this issue.

OpenSSL 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are not affected by this issue.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-15469"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-27T16:16:14Z",
    "severity": "MODERATE"
  },
  "details": "Issue summary: The \u0027openssl dgst\u0027 command-line tool silently truncates input\ndata to 16MB when using one-shot signing algorithms and reports success instead\nof an error.\n\nImpact summary: A user signing or verifying files larger than 16MB with\none-shot algorithms (such as Ed25519, Ed448, or ML-DSA) may believe the entire\nfile is authenticated while trailing data beyond 16MB remains unauthenticated.\n\nWhen the \u0027openssl dgst\u0027 command is used with algorithms that only support\none-shot signing (Ed25519, Ed448, ML-DSA-44, ML-DSA-65, ML-DSA-87), the input\nis buffered with a 16MB limit. If the input exceeds this limit, the tool\nsilently truncates to the first 16MB and continues without signaling an error,\ncontrary to what the documentation states. This creates an integrity gap where\ntrailing bytes can be modified without detection if both signing and\nverification are performed using the same affected codepath.\n\nThe issue affects only the command-line tool behavior. Verifiers that process\nthe full message using library APIs will reject the signature, so the risk\nprimarily affects workflows that both sign and verify with the affected\n\u0027openssl dgst\u0027 command. Streaming digest algorithms for \u0027openssl dgst\u0027 and\nlibrary users are unaffected.\n\nThe FIPS modules in 3.5 and 3.6 are not affected by this issue, as the\ncommand-line tools are outside the OpenSSL FIPS module boundary.\n\nOpenSSL 3.5 and 3.6 are vulnerable to this issue.\n\nOpenSSL 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are not affected by this issue.",
  "id": "GHSA-v2vr-926q-29fr",
  "modified": "2026-01-29T15:30:27Z",
  "published": "2026-01-27T18:32:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-15469"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/310f305eb92ea8040d6b3cb75a5feeba8e6acf2f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/a7936fa4bd23c906e1955a16a0a0ab39a4953a61"
    },
    {
      "type": "WEB",
      "url": "https://openssl-library.org/news/secadv/20260127.txt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V4MQ-X674-FF73

Vulnerability from github – Published: 2025-01-17 21:22 – Updated: 2025-01-29 18:22
VLAI
Summary
AWS Cloud Development Kit (AWS CDK) IAM OIDC custom resource allows connection to unauthorized OIDC provider
Details

Impact

Users who use IAM OIDC custom resource provider package will download CA Thumbprints as part of the custom resource workflow, https://github.com/aws/aws-cdk/blob/d16482fc8a4a3e1f62751f481b770c09034df7d2/packages/%40aws-cdk/custom-resource-handlers/lib/aws-iam/oidc-handler/external.ts#L34.

However, the current tls.connect method will always set rejectUnauthorized: false which is a potential security concern. CDK should follow the best practice and set rejectUnauthorized: true. However, this could be a breaking change for existing CDK applications and we should fix this with a feature flag.

Note that this is marked as low severity Security advisory because the issuer url is provided by CDK users who define the CDK application. If they insist on connecting to a unauthorized OIDC provider, CDK should not disallow this. Additionally, the code block is run in a Lambda environment which mitigate the MITM attack.

As a best practice, CDK should still fix this issue under a feature flag to avoid regression.

packages/@aws-cdk/custom-resource-handlers/lib/aws-iam/oidc-handler/external.ts
❯❱ problem-based-packs.insecure-transport.js-node.bypass-tls-verification.bypass-tls-verification
Checks for setting the environment variable NODE_TLS_REJECT_UNAUTHORIZED to 0, which disables TLS
verification. This should only be used for debugging purposes. Setting the option rejectUnauthorized
to false bypasses verification against the list of trusted CAs, which also leads to insecure
transport.

Patches

The patch is in progress. To mitigate, upgrade to CDK v2.177.0 (Expected release date 2025-02-22). Once upgraded, please make sure the feature flag '@aws-cdk/aws-iam:oidcRejectUnauthorizedConnections' is set to true in cdk.context.json or cdk.json. More details on feature flag setting is here.

Workarounds

N/A

References

https://github.com/aws/aws-cdk/issues/32920

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "aws-cdk-lib"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.177.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-23206"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-17T21:22:25Z",
    "nvd_published_at": "2025-01-17T21:15:12Z",
    "severity": "LOW"
  },
  "details": "### Impact\nUsers who use IAM OIDC custom resource provider package will download CA Thumbprints as part of the custom resource workflow, https://github.com/aws/aws-cdk/blob/d16482fc8a4a3e1f62751f481b770c09034df7d2/packages/%40aws-cdk/custom-resource-handlers/lib/aws-iam/oidc-handler/external.ts#L34. \n\nHowever, the current `tls.connect` method will always set `rejectUnauthorized: false` which is a potential security concern. CDK should follow the best practice and set `rejectUnauthorized: true`. However, this could be a breaking change for existing CDK applications and we should fix this with a feature flag. \n\nNote that this is marked as low severity Security advisory because the issuer url is provided by CDK users who define the CDK application. If they insist on connecting to a unauthorized OIDC provider, CDK should not disallow this. Additionally, the code block is run in a Lambda environment which mitigate the MITM attack.\n\nAs a best practice, CDK should still fix this issue under a feature flag to avoid regression.\n\n```\npackages/@aws-cdk/custom-resource-handlers/lib/aws-iam/oidc-handler/external.ts\n\u276f\u2771 problem-based-packs.insecure-transport.js-node.bypass-tls-verification.bypass-tls-verification\nChecks for setting the environment variable NODE_TLS_REJECT_UNAUTHORIZED to 0, which disables TLS\nverification. This should only be used for debugging purposes. Setting the option rejectUnauthorized\nto false bypasses verification against the list of trusted CAs, which also leads to insecure\ntransport.\n```\n\n### Patches\nThe patch is in progress. To mitigate, upgrade to CDK v2.177.0 (Expected release date 2025-02-22). \nOnce upgraded, please make sure the feature flag \u0027@aws-cdk/aws-iam:oidcRejectUnauthorizedConnections\u0027 is set to true in `cdk.context.json` or `cdk.json`. More details on feature flag setting is [here](https://docs.aws.amazon.com/cdk/v2/guide/featureflags.html).\n\n### Workarounds\nN/A\n\n### References\nhttps://github.com/aws/aws-cdk/issues/32920\n",
  "id": "GHSA-v4mq-x674-ff73",
  "modified": "2025-01-29T18:22:28Z",
  "published": "2025-01-17T21:22:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/aws/aws-cdk/security/advisories/GHSA-v4mq-x674-ff73"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23206"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aws/aws-cdk/issues/32920"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aws/aws-cdk/pull/32921"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aws/aws-cdk/commit/3e4f3773bfa48b75bf0adc7d53d46bbec7714a9e#diff-38a03353f201fd2e520df67fb43f9f000257bffd6e9acaa5569cce7005a77560"
    },
    {
      "type": "WEB",
      "url": "https://docs.aws.amazon.com/cdk/v2/guide/featureflags.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/aws/aws-cdk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aws/aws-cdk/blob/d16482fc8a4a3e1f62751f481b770c09034df7d2/packages/%40aws-cdk/custom-resource-handlers/lib/aws-iam/oidc-handler/external.ts#L34"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aws/aws-cdk/releases/tag/v2.177.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:A/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "AWS Cloud Development Kit (AWS CDK) IAM OIDC custom resource allows connection to unauthorized OIDC provider"
}

GHSA-V5RV-HPXG-8X49

Vulnerability from github – Published: 2021-01-13 19:13 – Updated: 2021-01-13 19:12
VLAI
Summary
Signature validation bypass in ServiceStack
Details

ServiceStack before 5.9.2 mishandles JWT signature verification unless an application has a custom ValidateToken function that establishes a valid minimum length for a signature.

Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "ServiceStack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.9.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-28042"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-01-13T19:12:58Z",
    "nvd_published_at": "2020-11-02T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "ServiceStack before 5.9.2 mishandles JWT signature verification unless an application has a custom ValidateToken function that establishes a valid minimum length for a signature.",
  "id": "GHSA-v5rv-hpxg-8x49",
  "modified": "2021-01-13T19:12:58Z",
  "published": "2021-01-13T19:13:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28042"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ServiceStack/ServiceStack/commit/540d4060e877a03ae95343c1a8560a26768585ee"
    },
    {
      "type": "WEB",
      "url": "https://forums.servicestack.net/t/servicestack-v5-9-2-released/8850"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-DOTNET-SERVICESTACK-1035519"
    },
    {
      "type": "WEB",
      "url": "https://www.nuget.org/packages/ServiceStack"
    },
    {
      "type": "WEB",
      "url": "https://www.shielder.it/advisories/servicestack-jwt-signature-verification-bypass"
    },
    {
      "type": "WEB",
      "url": "https://www.shielder.it/blog/2020/11/re-discovering-a-jwt-authentication-bypass-in-servicestack"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Signature validation bypass in ServiceStack"
}

GHSA-V6JX-GJW3-J6MV

Vulnerability from github – Published: 2022-05-24 16:45 – Updated: 2023-03-24 18:30
VLAI
Details

A vulnerability in the Image Signature Verification feature of Cisco NX-OS Software could allow an authenticated, local attacker with administrator-level credentials to install a malicious software image on an affected device. The vulnerability exists because software digital signatures are not properly verified during CLI command execution. An attacker could exploit this vulnerability to install an unsigned software image on an affected device.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-1813"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-05-15T23:29:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the Image Signature Verification feature of Cisco NX-OS Software could allow an authenticated, local attacker with administrator-level credentials to install a malicious software image on an affected device. The vulnerability exists because software digital signatures are not properly verified during CLI command execution. An attacker could exploit this vulnerability to install an unsigned software image on an affected device.",
  "id": "GHSA-v6jx-gjw3-j6mv",
  "modified": "2023-03-24T18:30:19Z",
  "published": "2022-05-24T16:45:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1813"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190515-nxos-sisv2"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/108425"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V7MH-QPQ8-5G5P

Vulnerability from github – Published: 2024-07-08 21:31 – Updated: 2025-09-26 15:30
VLAI
Details

The /n software IPWorks SSH library SFTPServer component can be induced to make unintended filesystem or network path requests when loading a SSH public key or certificate. To be exploitable, an application calling the SFTPServer component must grant user access without verifying the SSH public key or certificate (which would most likely be a separate vulnerability in the calling application). IPWorks SSH versions 22.0.8945 and 24.0.8945 were released to address this condition by blocking all filesystem and network path requests for SSH public keys or certificates.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
2.3 (Low)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/AU:N/V:D
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-6580"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1390",
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-08T19:15:10Z",
    "severity": "LOW"
  },
  "details": "The /n software IPWorks SSH library SFTPServer component can be induced to make unintended filesystem or network path requests when loading a SSH public key or certificate. To be exploitable, an application calling the SFTPServer component must grant user access without verifying the SSH public key or certificate (which would most likely be a separate vulnerability in the calling application).\u00a0IPWorks SSH versions 22.0.8945 and 24.0.8945 were released to address this condition by blocking all filesystem and network path requests for SSH public keys or certificates.",
  "id": "GHSA-v7mh-qpq8-5g5p",
  "modified": "2025-09-26T15:30:23Z",
  "published": "2024-07-08T21:31:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6580"
    },
    {
      "type": "WEB",
      "url": "https://www.nsoftware.com/kb/articles/cve-2024-5806"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/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:N/R:X/V:D/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-463: Padding Oracle Crypto Attack

An adversary is able to efficiently decrypt data without knowing the decryption key if a target system leaks data on whether or not a padding error happened while decrypting the ciphertext. A target system that leaks this type of information becomes the padding oracle and an adversary is able to make use of that oracle to efficiently decrypt data without knowing the decryption key by issuing on average 128*b calls to the padding oracle (where b is the number of bytes in the ciphertext block). In addition to performing decryption, an adversary is also able to produce valid ciphertexts (i.e., perform encryption) by using the padding oracle, all without knowing the encryption key.

CAPEC-475: Signature Spoofing by Improper Validation

An adversary exploits a cryptographic weakness in the signature verification algorithm implementation to generate a valid signature without knowing the key.

← Back to the CWE list