GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
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.

1336 vulnerabilities reference this CWE, most recent first.

GHSA-9RFG-V8G9-9367

Vulnerability from github – Published: 2026-05-26 23:38 – Updated: 2026-06-11 13:30
VLAI
Summary
Fedify has an LD-Signature Bypass via JSON-LD Named-Graph Restructuring
Details

As told on Discord earlier, multiple projects are affected, and we would like to coordinate. For now, we are aiming at a May 6th release date, but this is not set in stone yet.

Summary

An attacker can make use of JSON-LD features to restructure a JSON-LD document that would change how Fedify interprets it without changing its Linked Data Signature, allowing them to alter a third-party signed activity they have received.

Details

The vulnerability essentially boils down to the signature being on the canonical RDF graph representation of the JSON-LD document, and JSON-LD offering many ways to represent the same graph.

One of the issues is that by taking a signed Activity with an embedded object, an attacker can move the top-level Activity to a @graph property and move the activity's object to the top-level. Such a transformation preserves the signature and changes how the payload is interpreted by pretty much all ActivityPub implementations, making them process the object and ignore the formely-top-level activity. This can be used when the graph contains an embedded activity. In Mastodon, that is the case of { "type": "Undo", "object": { "type": "Announce" } }, but other implementations may sign other activities that can be exploited in the same way.

The @reverse keyword can also be used to change the shape of a JSON-LD document without changing the underlying graph, and could be used in a similar way to reverse an Activity and its object.

Another problematic feature is @included, which can be used to “move” properties outside of the normal tree, effectively making them invisible to most ActivityPub implementations, while, again, preserving the signature. This allows removing statuses or actor properties once a signed Create or Update activity is received.

Given that we have seen no use of @graph, @included or @reverse in ActivityPub payloads and that they are very complex to handle correctly (the only JSON-LD API functions that “normalize” @included and @reverse are flattening and framing, which both lose the root node), we have decided to reject them, and recommend you do so as well.

Detection of @graph, @included and @reverse should happen after compacting the incoming activity to your context, as aliases can be used for those keywords.

Additionally, after a quick scan of Fedify's source code, I could not verify that JSON-LD documents with a verified Linked Data Signature were compacted against your local JSON-LD context. Not doing that allows an attacker to rename aliases to non-standard names and use non-mapped aliases to replace existing values, while still leaving the signature intact. This allows an attacker to essentially replace arbitrary portions of any signed JSON-LD document and completely forge any activity while still passing verification. A similar issue was fixed in Mastodon a few years ago: https://github.com/mastodon/mastodon/pull/17426.

Impact

The impact is difficult to assess as this depends on the types of activities that are actually signed and processed in the wild.

The @included keyword allows “removing” arbitrary attributes, thus allowing replaying Create and Update activities while stripping away any attribute, such as content or metadata, which can lead to integrity and availability issues, although confidentiality issues are unlikely.

The @graph and @reverse keywords allow changing the root activity, which in the case of Mastodon allows sending an Announce from a Undo { Announce }, but might have wider consequences depending on what various servers sign.

The lack of compacting can allow rewriting any activity arbitrarily, thus leading to major integrity, availability, and possibly confidentiality issues (e.g. by replacing an actor's inbox).

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.0"
            },
            {
              "fixed": "2.1.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.0.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.10.0"
            },
            {
              "fixed": "1.10.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fedify/fedify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42462"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1289",
      "CWE-180",
      "CWE-347",
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-26T23:38:37Z",
    "nvd_published_at": "2026-06-10T22:16:57Z",
    "severity": "HIGH"
  },
  "details": "As told on Discord earlier, multiple projects are affected, and we would like to coordinate. For now, we are aiming at a May 6th release date, but this is not set in stone yet.\n\n### Summary\n\nAn attacker can make use of JSON-LD features to restructure a JSON-LD document that would change how Fedify interprets it without changing its Linked Data Signature, allowing them to alter a third-party signed activity they have received.\n\n### Details\n\nThe vulnerability essentially boils down to the signature being on the canonical RDF graph representation of the JSON-LD document, and JSON-LD offering many ways to represent the same graph.\n\nOne of the issues is that by taking a signed `Activity` with an embedded `object`, an attacker can move the top-level `Activity` to a `@graph` property and move the activity\u0027s `object` to the top-level. Such a transformation preserves the signature and changes how the payload is interpreted by pretty much all ActivityPub implementations, making them process the object and ignore the formely-top-level activity. This can be used when the graph contains an embedded activity. In Mastodon, that is the case of `{ \"type\": \"Undo\", \"object\": { \"type\": \"Announce\" } }`, but other implementations may sign other activities that can be exploited in the same way.\n\nThe `@reverse` keyword can also be used to change the shape of a JSON-LD document without changing the underlying graph, and could be used in a similar way to reverse an `Activity` and its `object`.\n\nAnother problematic feature is `@included`, which can be used to \u201cmove\u201d properties outside of the normal tree, effectively making them invisible to most ActivityPub implementations, while, again, preserving the signature. This allows removing statuses or actor properties once a signed `Create` or `Update` activity is received.\n\nGiven that we have seen no use of `@graph`, `@included` or `@reverse` in ActivityPub payloads and that they are very complex to handle correctly (the only JSON-LD API functions that \u201cnormalize\u201d `@included` and `@reverse` are flattening and framing, which both lose the root node), we have decided to reject them, and recommend you do so as well.\n\nDetection of `@graph`, `@included` and `@reverse` should happen after compacting the incoming activity to your context, as aliases can be used for those keywords.\n\nAdditionally, after a quick scan of Fedify\u0027s source code, I could not verify that JSON-LD documents with a verified Linked Data Signature were compacted against your local JSON-LD context. Not doing that allows an attacker to rename aliases to non-standard names and use non-mapped aliases to replace existing values, while still leaving the signature intact. This allows an attacker to essentially replace arbitrary portions of any signed JSON-LD document and completely forge any activity while still passing verification. A similar issue was fixed in Mastodon a few years ago: https://github.com/mastodon/mastodon/pull/17426.\n\n### Impact\n\nThe impact is difficult to assess as this depends on the types of activities that are actually signed and processed in the wild.\n\nThe `@included` keyword allows \u201cremoving\u201d arbitrary attributes, thus allowing replaying `Create` and `Update` activities while stripping away any attribute, such as content or metadata, which can lead to integrity and availability issues, although confidentiality issues are unlikely.\n\nThe `@graph` and `@reverse` keywords allow changing the root activity, which in the case of Mastodon allows sending an `Announce` from a `Undo { Announce }`, but might have wider consequences depending on what various servers sign.\n\nThe lack of compacting can allow rewriting any activity arbitrarily, thus leading to major integrity, availability, and possibly confidentiality issues (e.g. by replacing an actor\u0027s `inbox`).",
  "id": "GHSA-9rfg-v8g9-9367",
  "modified": "2026-06-11T13:30:30Z",
  "published": "2026-05-26T23:38:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fedify-dev/fedify/security/advisories/GHSA-9rfg-v8g9-9367"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42462"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fedify-dev/fedify"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fedify-dev/fedify/releases/tag/2.2.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Fedify has an LD-Signature Bypass via JSON-LD Named-Graph Restructuring"
}

GHSA-9V6R-G5CX-H6FG

Vulnerability from github – Published: 2023-05-18 12:30 – Updated: 2023-05-18 12:30
VLAI
Details

Local privilege escalation due to unrestricted loading of unsigned libraries. The following products are affected: Acronis Cyber Protect Home Office (Windows) before build 40208.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-4418"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-18T10:15:09Z",
    "severity": "HIGH"
  },
  "details": "Local privilege escalation due to unrestricted loading of unsigned libraries. The following products are affected: Acronis Cyber Protect Home Office (Windows) before build 40208.",
  "id": "GHSA-9v6r-g5cx-h6fg",
  "modified": "2023-05-18T12:30:15Z",
  "published": "2023-05-18T12:30:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4418"
    },
    {
      "type": "WEB",
      "url": "https://security-advisory.acronis.com/advisories/SEC-4729"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9V8J-X534-2FX3

Vulnerability from github – Published: 2025-12-08 21:30 – Updated: 2025-12-12 21:52
VLAI
Summary
Ruby-saml has a SAML authentication bypass due to namespace handling (parser differential)
Details

Summary

Ruby-saml up to and including 1.12.4, there is an authentication bypass vulnerability because of an incomplete fix for CVE-2025-25292. ReXML and Nokogiri parse XML differently, the parsers can generate entirely different document structures from the same XML input. That allows an attacker to be able to execute a Signature Wrapping attack. The vulnerability does not affect the version 1.18.0.

Impact

That allows an attacker to be able to execute a Signature Wrapping attack and bypass the authentication

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "ruby-saml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.18.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-66567"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-08T21:30:56Z",
    "nvd_published_at": "2025-12-09T16:18:21Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\nRuby-saml up to and including 1.12.4, there is an authentication bypass vulnerability because of an incomplete fix for CVE-2025-25292. ReXML and Nokogiri parse XML differently, the parsers can generate entirely different document structures from the same XML input. That allows an attacker to be able to execute a Signature Wrapping attack. The vulnerability does not affect the version 1.18.0.\n\n### Impact\nThat allows an attacker to be able to execute a Signature Wrapping attack and bypass the authentication",
  "id": "GHSA-9v8j-x534-2fx3",
  "modified": "2025-12-12T21:52:23Z",
  "published": "2025-12-08T21:30:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/SAML-Toolkits/ruby-saml/security/advisories/GHSA-9v8j-x534-2fx3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66567"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SAML-Toolkits/ruby-saml/commit/e9c1cdbd0f9afa467b585de279db0cbd0fb8ae97"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/SAML-Toolkits/ruby-saml"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-754f-8gm6-c4r2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/ruby-saml/CVE-2025-66567.yml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Ruby-saml has a SAML authentication bypass due to namespace handling (parser differential)"
}

GHSA-9VCR-P3RJ-Q5Q6

Vulnerability from github – Published: 2026-07-09 23:20 – Updated: 2026-07-31 20:17
VLAI
Summary
sigstore-go has a multi-log threshold bypass via single compromised log
Details

Impact

What kind of vulnerability is it? Who is impacted?

A verifier configured with WithTransparencyLog(N>1) or WithSignedCertificateTimestamps(N>1) expected defense-in-depth against the compromise of a single log instance. However, threshold counting counted verified witnesses per-entry or per-validation-path rather than per-log-authority.

As a result, a single compromised transparency log could forge multiple entries with different indices, and a single compromised CT log could verify multiple times (either across multiple certificate chains or via multiple embedded SCTs), fully satisfying the multi-log threshold requirements and defeating the multi-log policy.

Note that this does not affect Cosign, as Cosign sets a threshold of 1.

Patches

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

Upgrade to v1.1.5.

Workarounds

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

There is no workaround, beyond relying on trusted logs.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.1.4"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/sigstore-go"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49834"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-09T23:20:30Z",
    "nvd_published_at": "2026-07-17T20:17:21Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nA verifier configured with WithTransparencyLog(N\u003e1) or WithSignedCertificateTimestamps(N\u003e1) expected defense-in-depth against the compromise of a single log instance. However, threshold counting counted verified witnesses per-entry or per-validation-path rather than per-log-authority.\n\nAs a result, a single compromised transparency log could forge multiple entries with different indices, and a single compromised CT log could verify multiple times (either across multiple certificate chains or via multiple embedded SCTs), fully satisfying the multi-log threshold requirements and defeating the multi-log policy.\n\nNote that this does not affect Cosign, as Cosign sets a threshold of 1.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nUpgrade to v1.1.5.\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nThere is no workaround, beyond relying on trusted logs.",
  "id": "GHSA-9vcr-p3rj-q5q6",
  "modified": "2026-07-31T20:17:30Z",
  "published": "2026-07-09T23:20:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore-go/security/advisories/GHSA-9vcr-p3rj-q5q6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49834"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore-go/pull/633"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore-go/commit/dbb07e62623edd5b175fb9dd5a41dcb85a159207"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/sigstore-go"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore-go/releases/tag/v1.2.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "sigstore-go has a multi-log threshold bypass via single compromised log"
}

GHSA-9WX7-JRVC-28MM

Vulnerability from github – Published: 2021-11-08 21:51 – Updated: 2021-11-08 21:34
VLAI
Summary
Signature verification vulnerability in Stark Bank ecdsa libraries
Details

An attacker can forge signatures on arbitrary messages that will verify for any public key. This may allow attackers to authenticate as any user within the Stark Bank platform, and bypass signature verification needed to perform operations on the platform, such as send payments and transfer funds. Additionally, the ability for attackers to forge signatures may impact other users and projects using these libraries in different and unforeseen ways.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "starkbank-ecdsa"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.starkbank:ecdsa-java"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.0.0"
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "starkbank-ecdsa"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3.1"
            },
            {
              "fixed": "1.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.3.1"
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "starkbank-ecdsa"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.1.2"
            },
            {
              "fixed": "1.1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.1.2"
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-11-08T21:34:42Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "An attacker can forge signatures on arbitrary messages that will verify for any public key. This may allow attackers to authenticate as any user within the Stark Bank platform, and bypass signature verification needed to perform operations on the platform, such as send payments and transfer funds. Additionally, the ability for attackers to forge signatures may impact other users and projects using these libraries in different and unforeseen ways.",
  "id": "GHSA-9wx7-jrvc-28mm",
  "modified": "2021-11-08T21:34:42Z",
  "published": "2021-11-08T21:51:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/starkbank/ecdsa-python/commit/d136170666e9510eb63c2572551805807bd4c17f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/starkbank/ecdsa-dotnet"
    },
    {
      "type": "WEB",
      "url": "https://github.com/starkbank/ecdsa-java"
    },
    {
      "type": "WEB",
      "url": "https://github.com/starkbank/ecdsa-node"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/starkbank/ecdsa-python"
    },
    {
      "type": "WEB",
      "url": "https://github.com/starkbank/ecdsa-python/compare/v2.0.0...v2.0.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/starkbank/ecdsa-python/releases/tag/v2.0.1"
    },
    {
      "type": "WEB",
      "url": "https://research.nccgroup.com/2021/11/08/technical-advisory-arbitrary-signature-forgery-in-stark-bank-ecdsa-libraries"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Signature verification vulnerability in Stark Bank ecdsa libraries"
}

GHSA-9X5Q-PWR2-HWVP

Vulnerability from github – Published: 2024-06-15 00:31 – Updated: 2024-06-15 00:31
VLAI
Details

StorageGRID (formerly StorageGRID Webscale) versions prior to 11.7.0.9 and 11.8.0.5 are susceptible to disclosure of sensitive information via complex MiTM attacks due to a vulnerability in the SSH cryptographic implementation.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-21988"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-14T22:15:10Z",
    "severity": "MODERATE"
  },
  "details": "StorageGRID (formerly StorageGRID Webscale) versions prior to \n11.7.0.9 and 11.8.0.5 are susceptible to disclosure of sensitive \ninformation via complex MiTM attacks due to a vulnerability in the SSH \ncryptographic implementation.",
  "id": "GHSA-9x5q-pwr2-hwvp",
  "modified": "2024-06-15T00:31:14Z",
  "published": "2024-06-15T00:31:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21988"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240614-0010"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9XJR-M6F3-V5WM

Vulnerability from github – Published: 2021-08-25 20:43 – Updated: 2023-06-13 17:38
VLAI
Summary
HTTPS MitM vulnerability due to lack of hostname verification
Details

When used on Windows platforms, all versions of Hyper prior to 0.9.4 did not perform hostname verification when making HTTPS requests.

This allows an attacker to perform MitM attacks by preventing any valid CA-issued certificate, even if there's a hostname mismatch.

The problem was addressed by leveraging rust-openssl's built-in support for hostname verification.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "hyper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2016-10932"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-08-19T21:25:12Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "When used on Windows platforms, all versions of Hyper prior to 0.9.4 did not perform hostname verification when making HTTPS requests.\n\nThis allows an attacker to perform MitM attacks by preventing any valid CA-issued certificate, even if there\u0027s a hostname mismatch.\n\nThe problem was addressed by leveraging rust-openssl\u0027s built-in support for hostname verification.",
  "id": "GHSA-9xjr-m6f3-v5wm",
  "modified": "2023-06-13T17:38:19Z",
  "published": "2021-08-25T20:43:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-10932"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hyperium/hyper/issues/472"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hyperium/hyper/commit/01160abd92956e5f995cc45790df7a2b86c8989f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hyperium/hyper/blob/master/CHANGELOG.md#v094-2016-05-09"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2016-0002.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "HTTPS MitM vulnerability due to lack of hostname verification"
}

GHSA-C2PQ-PFGC-Q2G7

Vulnerability from github – Published: 2022-05-14 01:09 – Updated: 2022-05-14 01:09
VLAI
Details

In HP LaserJet Enterprise, HP PageWide Enterprise, HP LaserJet Managed, and HP OfficeJet Enterprise Printers, solution application signature checking may allow potential execution of arbitrary code.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-5923"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-03-27T16:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "In HP LaserJet Enterprise, HP PageWide Enterprise, HP LaserJet Managed, and HP OfficeJet Enterprise Printers, solution application signature checking may allow potential execution of arbitrary code.",
  "id": "GHSA-c2pq-pfgc-q2g7",
  "modified": "2022-05-14T01:09:26Z",
  "published": "2022-05-14T01:09:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-5923"
    },
    {
      "type": "WEB",
      "url": "https://support.hp.com/us-en/document/c06169434"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C2V4-JG9M-JGRR

Vulnerability from github – Published: 2026-06-09 03:31 – Updated: 2026-06-09 03:31
VLAI
Details

SAP NetWeaver Application Server ABAP and ABAP Platform allows an authenticated attacker with normal privileges to obtain a valid signed message and send modified signed XML documents to the verifier. This may result in acceptance of tampered identity information leading to unauthorized access to sensitive user data and potential disruption of normal system usage. This causes a high impact on confidentiality, integrity and availability of the application.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-44748"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-09T01:16:46Z",
    "severity": "CRITICAL"
  },
  "details": "SAP NetWeaver Application Server ABAP and ABAP Platform allows an authenticated attacker with normal privileges to obtain a valid signed message and send modified signed XML documents to the verifier. This may result in acceptance of tampered identity information leading to unauthorized access to sensitive user data and potential disruption of normal system usage. This causes a high impact on confidentiality, integrity and availability of the application.",
  "id": "GHSA-c2v4-jg9m-jgrr",
  "modified": "2026-06-09T03:31:40Z",
  "published": "2026-06-09T03:31:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44748"
    },
    {
      "type": "WEB",
      "url": "https://me.sap.com/notes/3746332"
    },
    {
      "type": "WEB",
      "url": "https://url.sap/sapsecuritypatchday"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C39G-93PM-R85M

Vulnerability from github – Published: 2024-03-18 06:30 – Updated: 2024-08-28 18:31
VLAI
Details

In the CryptX module before 0.062 for Perl, gcm_decrypt_verify() and chacha20poly1305_decrypt_verify() do not verify the tag.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-25099"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-18T05:15:06Z",
    "severity": "CRITICAL"
  },
  "details": "In the CryptX module before 0.062 for Perl, gcm_decrypt_verify() and chacha20poly1305_decrypt_verify() do not verify the tag.",
  "id": "GHSA-c39g-93pm-r85m",
  "modified": "2024-08-28T18:31:53Z",
  "published": "2024-03-18T06:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-25099"
    },
    {
      "type": "WEB",
      "url": "https://github.com/DCIT/perl-CryptX/issues/47"
    },
    {
      "type": "WEB",
      "url": "https://github.com/libtom/libtomcrypt/pull/451"
    },
    {
      "type": "WEB",
      "url": "https://metacpan.org/dist/CryptX/changes"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "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.