Common Weakness Enumeration

CWE-347

Allowed

Improper Verification of Cryptographic Signature

Abstraction: Base · Status: Draft

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

1125 vulnerabilities reference this CWE, most recent first.

GHSA-RPJ7-HR7H-W6P9

Vulnerability from github – Published: 2026-06-19 20:46 – Updated: 2026-06-19 20:46
VLAI
Summary
CoreWCF: SamlSerializer skips SignatureValue verification when SAML signing token is not an X.509 certificate
Details

Impact

When a service is configured to validate SAML tokens using a method other than X.509 certificate signing, the final signature verification is skipped.

Preconditions

The service is configured to authenticate using SAML tokens and an out of band token resolver (commonly the IssuerTokenResolver of IssuedTokenServiceCredential) holds a non-X.509 SecurityToken whose key identifier the attacker can reference in the assertion’s <KeyInfo> - for example a BinarySecretSecurityToken representing the symmetric proof key issued by a WS-Trust symmetric-key holder-of-key STS.

Patches

Fixed in CoreWCF v1.8.1 and v1.9.1

Workarounds

None

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "CoreWCF.Primitives"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "CoreWCF.Primitives"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.9.0"
            },
            {
              "fixed": "1.9.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54774"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T20:46:46Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\nWhen a service is configured to validate SAML tokens using a method other than X.509 certificate signing, the final signature verification is skipped.\n\n#### Preconditions\nThe service is configured to authenticate using SAML tokens and an out of band token resolver (commonly the IssuerTokenResolver of IssuedTokenServiceCredential) holds a non-X.509 SecurityToken whose key identifier the attacker can reference in the assertion\u2019s `\u003cKeyInfo\u003e` - for example a `BinarySecretSecurityToken` representing the symmetric proof key issued by a WS-Trust symmetric-key holder-of-key STS.\n\n### Patches\nFixed in CoreWCF v1.8.1 and v1.9.1\n\n### Workarounds\nNone",
  "id": "GHSA-rpj7-hr7h-w6p9",
  "modified": "2026-06-19T20:46:46Z",
  "published": "2026-06-19T20:46:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/CoreWCF/CoreWCF/security/advisories/GHSA-rpj7-hr7h-w6p9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/CoreWCF/CoreWCF"
    }
  ],
  "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": "CoreWCF: SamlSerializer skips SignatureValue verification when SAML signing token is not an X.509 certificate"
}

GHSA-RQMW-G85W-M87F

Vulnerability from github – Published: 2025-12-11 18:30 – Updated: 2025-12-11 18:30
VLAI
Details

An issue was discovered in Foxit PDF and Editor for Windows and macOS before 13.2 and 2025 before 2025.2. A crafted PDF can use JavaScript to alter annotation content and subsequently clear the file's modification status via JavaScript interfaces. This circumvents digital signature verification by hiding document modifications, allowing an attacker to mislead users about the document's integrity and compromise the trustworthiness of signed PDFs.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-55311"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-11T16:16:25Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Foxit PDF and Editor for Windows and macOS before 13.2 and 2025 before 2025.2. A crafted PDF can use JavaScript to alter annotation content and subsequently clear the file\u0027s modification status via JavaScript interfaces. This circumvents digital signature verification by hiding document modifications, allowing an attacker to mislead users about the document\u0027s integrity and compromise the trustworthiness of signed PDFs.",
  "id": "GHSA-rqmw-g85w-m87f",
  "modified": "2025-12-11T18:30:44Z",
  "published": "2025-12-11T18:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55311"
    },
    {
      "type": "WEB",
      "url": "https://www.foxit.com/support/security-bulletins.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"
    }
  ]
}

GHSA-RQW2-HHRF-7936

Vulnerability from github – Published: 2022-05-24 17:17 – Updated: 2024-09-27 21:21
VLAI
Summary
OpenStack Keystone does not check signature TTL of the EC2 credential auth method
Details

An issue was discovered in OpenStack Keystone before 15.0.1, and 16.0.0. The EC2 API doesn't have a signature TTL check for AWS Signature V4. An attacker can sniff the Authorization header, and then use it to reissue an OpenStack token an unlimited number of times.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "keystone"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "16.0.0.0rc1"
            },
            {
              "fixed": "16.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "keystone"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "15.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-12692"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-311",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-07-13T17:10:16Z",
    "nvd_published_at": "2020-05-07T00:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in OpenStack Keystone before 15.0.1, and 16.0.0. The EC2 API doesn\u0027t have a signature TTL check for AWS Signature V4. An attacker can sniff the Authorization header, and then use it to reissue an OpenStack token an unlimited number of times.",
  "id": "GHSA-rqw2-hhrf-7936",
  "modified": "2024-09-27T21:21:47Z",
  "published": "2022-05-24T17:17:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12692"
    },
    {
      "type": "WEB",
      "url": "https://bugs.launchpad.net/keystone/+bug/1872737"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openstack/keystone"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/keystone/PYSEC-2020-56.yaml"
    },
    {
      "type": "WEB",
      "url": "https://opendev.org/openstack/keystone/commit/ab89ea749013e7f2c46260f68504f5687763e019"
    },
    {
      "type": "WEB",
      "url": "https://security.openstack.org/ossa/OSSA-2020-003.html"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4480-1"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2020/05/06/4"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2020/05/07/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenStack Keystone does not check signature TTL of the EC2 credential auth method"
}

GHSA-RR32-XPF4-HWJ6

Vulnerability from github – Published: 2024-04-09 18:30 – Updated: 2024-04-09 18:30
VLAI
Details

Improper privilege management in the installer for Zoom Desktop Client for Windows before version 5.17.10 may allow an authenticated user to conduct an escalation of privilege via local access.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-24694"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-09T18:15:08Z",
    "severity": "MODERATE"
  },
  "details": "Improper privilege management in the installer for Zoom Desktop Client for Windows before version 5.17.10 may allow an authenticated user to conduct an escalation of privilege via local access.",
  "id": "GHSA-rr32-xpf4-hwj6",
  "modified": "2024-04-09T18:30:28Z",
  "published": "2024-04-09T18:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24694"
    },
    {
      "type": "WEB",
      "url": "https://www.zoom.com/en/trust/security-bulletin/zsb-24011"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

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

{
  "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

{
  "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.

Show details on source website

{
  "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?

Show details on source website

{
  "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.

Show details on source website

{
  "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.

Show details on source website

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

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.