CWE-347

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.4.13"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "lightrag-hku"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-39413"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-08T00:17:50Z",
    "nvd_published_at": "2026-04-08T20:16:25Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\nThe LightRAG API is vulnerable to a JWT algorithm confusion attack where an attacker can forge tokens by specifying \u0027alg\u0027: \u0027none\u0027 in the JWT header. Since the `jwt.decode()` call does not explicitly deny the \u0027none\u0027 algorithm, a crafted token without a signature will be accepted as valid, leading to unauthorized access.\n\n## Details\nIn `lightrag/api/auth.py` at line 128, the `validate_token` method calls:\n\n```python\npayload = jwt.decode(token, self.secret, algorithms=[self.algorithm])\n```\n\nThis allows any algorithm listed in the token\u0027s header to be processed, including \u0027none\u0027. The code does not explicitly specify that \u0027none\u0027 is not allowed, making it possible for an attacker to bypass authentication.\n\n## PoC\nAn attacker can generate a JWT with the following structure:\n\n```json\n{\n  \"header\": {\n    \"alg\": \"none\",\n    \"typ\": \"JWT\"\n  },\n  \"payload\": {\n    \"sub\": \"admin\",\n    \"exp\": 1700000000,\n    \"role\": \"admin\"\n  }\n}\n```\n\nThen send a request like:\n\n```bash\ncurl -H \"Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMCwicm9sZSI6ImFkbWluIn0.\" http://localhost:8000/api/protected-endpoint\n```\n\n## Impact\nAn attacker can impersonate any user, including administrators, by forging a JWT with \u0027alg\u0027: \u0027none\u0027, gaining full access to protected resources without needing valid credentials.\n\n## Recommended Fix\nExplicitly specify allowed algorithms and exclude \u0027none\u0027. Modify the `validate_token` method to:\n\n```python\nallowed_algorithms = [self.algorithm] if self.algorithm != \u0027none\u0027 else [\u0027HS256\u0027, \u0027HS384\u0027, \u0027HS512\u0027]\npayload = jwt.decode(token, self.secret, algorithms=allowed_algorithms)\n```\n\nOr better yet, hardcode the expected algorithm(s):\n\n```python\npayload = jwt.decode(token, self.secret, algorithms=[\u0027HS256\u0027])\n```",
  "id": "GHSA-8ffj-4hx4-9pgf",
  "modified": "2026-04-27T16:13:13Z",
  "published": "2026-04-08T00:17:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/HKUDS/LightRAG/security/advisories/GHSA-8ffj-4hx4-9pgf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39413"
    },
    {
      "type": "WEB",
      "url": "https://github.com/HKUDS/LightRAG/commit/728f2e54509d93e0a44f929c7f83f2c88d6d291b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/HKUDS/LightRAG"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "lightrag-hku: JWT Algorithm Confusion Vulnerability "
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "borgbackup"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-36811"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-08-30T20:09:33Z",
    "nvd_published_at": "2023-08-30T18:15:09Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nA flaw in the cryptographic authentication scheme in borgbackup allowed an attacker to fake archives and potentially indirectly cause backup data loss in the repository.\n\nThe attack requires an attacker to be able to\n\n1. insert files (with no additional headers) into backups\n2. gain write access to the repository\n\nThis vulnerability does not disclose plaintext to the attacker, nor does it affect the authenticity of existing archives.\n\nCreating plausible fake archives may be feasible for empty or small archives, but is unlikely for large archives.\n\nAffected are all borgbackup releases prior to 1.2.5.\n\nNote: CVSS scoring model seemed to badly fit for this case, thus I manually set score to \"moderate\".\n\n### Patches\nThe issue has been fixed in borgbackup 1.2.5.\nBut there was a bug in 1.2.5 upgrade instructions, thus 1.2.6 with an important fix in docs and code was released a day afterwards.\n\nAdditionally to installing the fixed code, users must follow the upgrade procedure as documented in the latest version of the change log.\n\n### Workarounds\nData loss after being attacked can be avoided by reviewing the archives (timestamp and contents valid and as expected) after any \"borg check --repair\" and before \"borg prune\".\n\n### References\n\nhttps://github.com/borgbackup/borg/blob/1.2.6/docs/changes.rst#pre-125-archives-spoofing-vulnerability-cve-2023-36811\n",
  "id": "GHSA-8fjr-hghr-4m99",
  "modified": "2024-09-13T14:35:53Z",
  "published": "2023-08-30T20:09:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/borgbackup/borg/security/advisories/GHSA-8fjr-hghr-4m99"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36811"
    },
    {
      "type": "WEB",
      "url": "https://github.com/borgbackup/borg/commit/3eb070191da10c2d3f7bc6484cf3d51c3045f884"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/borgbackup/borg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/borgbackup/borg/blob/1.2.5-cvedocs/docs/changes.rst#pre-125-archives-spoofing-vulnerability-cve-2023-36811"
    },
    {
      "type": "WEB",
      "url": "https://github.com/borgbackup/borg/blob/1.2.6/docs/changes.rst#pre-125-archives-spoofing-vulnerability-cve-2023-36811"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/borgbackup/PYSEC-2023-164.yaml"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/5Q3OHXERTU547SEQ3YREZXHOCYNLVD63"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XOZDFIYEBIOKSIEAXUJJJFUJTAJ7TF3C"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZUCQSMAWOJBCRGF6XPKEZ2TPGAPNKIWV"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Archive spoofing vulnerability in borgbackup"
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-55278"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-05T23:16:05Z",
    "severity": "HIGH"
  },
  "details": "Improper authentication in the API authentication middleware of HCL DevOps Loop allows authentication tokens to be accepted without proper validation of their expiration and cryptographic signature.  As a result, an attacker could potentially use expired or tampered tokens to gain unauthorized access to sensitive resources and perform actions with elevated privileges.",
  "id": "GHSA-8gg4-hx7q-h82p",
  "modified": "2025-11-06T00:30:26Z",
  "published": "2025-11-06T00:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55278"
    },
    {
      "type": "WEB",
      "url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0124203"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.11.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/cosign"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.12.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-36056"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-09-16T19:13:13Z",
    "nvd_published_at": "2022-09-14T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nA number of vulnerabilities have been found in `cosign verify-blob`, where Cosign would successfully verify an artifact when verification should have failed.\n\n## Vulnerability 1: Bundle mismatch causes invalid verification.\n\n### Summary\nA cosign bundle can be crafted to successfully verify a blob even if the embedded rekorBundle does not reference the given signature.\n\n### Details\nCosign supports \"bundles\" which intend to allow offline verification of the signature and rekor inclusion. By using the --bundle flag in cosign sign-blob, cosign will create a JSON file called a \"bundle\". These bundles include three fields: base64Signature, cert, and rekorBundle. The desired behavior is that the verification of these bundles would:\n\n- verify the provided blob using the included signature and certificate\n- verify the rekorBundle SET\n- verify the rekorBundle payload references the given artifact.\n\nIt appears that step three is not being performed, allowing \"any old rekorBundle\" to pass validation, even if the rekorBundle payload does not reference the provided blob or the certificate and signature in the rekorBundle do not match those at the top level.\n\n### Steps to reproduce\nEnable keyless signing:\n\n```\nexport COSIGN_EXPERIMENTAL=1\n```\nCreate two random blobs:\n```\ndd bs=1 count=50 \u003c/dev/urandom \u003eblob1\ndd bs=1 count=50 \u003c/dev/urandom \u003eblob2\n```\nSign each blob:\n```\ncosign sign-blob blob1 --bundle bundle1\ncosign sign-blob blob2 --bundle bundle2\n```\nCreate a falsified bundle including the base64Signature and cert fields from bundle1 and the rekorBundle from bundle2:\n```\njq --slurpfile bundle2 bundle2 \u0027.rekorBundle = $bundle2[0].rekorBundle\u0027 bundle1 \u003e invalidBundle\n```\nNow, the falsified bundle can be used to verify blob1:\n```\n$ cosign verify-blob blob1 --bundle invalidBundle\ntlog entry verified offline\nVerified OK\n```\n\n### Patches\n\nUsers should update to the latest version of Cosign, `1.12.0`.\n\n### Workaround\n\nIf you extract the signature and certificate from the `bundle`, you may use it for verification as follows and avoid using an invalid bundle:\n```\n$ cosign verify-blob blob1 --signature $(jq -r \u0027.base64Signature\u0027 bundle1) --certificate $(jq -r \u0027.cert\u0027 bundle1)\n```\n\nNote that this will make a network call to Rekor to fetch the Rekor entry. However, you may then be subject to Vulnerability 4.\n\n##  Vulnerability 2: Certificate Identities are not checked in some cases\n\n### Summary \n\nWhen providing identity flags, the email and issuer of a certificate is not checked when verifying a Rekor bundle, and the GitHub Actions identity is never checked.\n\n### Details\n\nUsers who provide an offline Rekor bundle (`--bundle`) when verifying a blob using `cosign verify-blob` and include flags that check identity such as `--certificate-email` and `--certificate-oidc-issuer` are impacted. Additionally, users who provide the GitHub Actions verification flags such as `--certificate-github-workflow-name` when running `cosign verify-blob` without a bundle, key reference, or certificate are impacted. \n\nWhen providing these flags, Cosign ignored their values. If a certificate\u0027s identity did not match the provided flags, Cosign would still successfully verify the blob.\n\n### Patches\n\nUsers should update to the latest version of Cosign, `1.12.0`.\n\n### Workarounds\n\nThere are no workarounds, users should update.\n\n##  Vulnerability 3: Invalid Rekor bundle without the experimental flag will result in successful verification\n\n### Summary\n\nProviding an invalid Rekor bundle without the experimental flag results in a successful verification.\n\n### Details\n\nUsers who provide an offline Rekor bundle (`--bundle`) that was invalid (invalid signed entry timestamp, expired certificate, or malformed) when verifying a blob with `cosign verify-blob` and do not set the `COSIGN_EXPERIMENTAL=1` flag are impacted.\n\nWhen an invalid bundle was provided, Cosign would fallback to checking Rekor log inclusion by requesting proof of inclusion from the log. However, without the `COSIGN_EXPERIMENTAL` flag, Cosign would exit early and successfully verify the blob. \n\n### Patches\n\nUsers should update to the latest version of Cosign, `1.12.0`.\n\n### Workarounds\n\nThere are no workarounds, users should update.\n\n##  Vulnerability 4: Invalid transparency log entry will result in successful verification\n\n### Summary\n\nAn invalid transparency log entry will result in immediate success for verification.\n\n### Details\n\nUsers who provide a signature and certificate to `verify-blob` will fetch the associated Rekor entry for verification. If the returned entry was invalid (invalid signed entry timestamp, invalid inclusion proof, malformed entry with missing verification), then `cosign` [exits](https://github.com/sigstore/cosign/blob/42c6e2a6dd9d92d19077c8e6b7d66d155a5ea28c/cmd/cosign/cli/verify/verify_blob.go#L357) early and succeeds unconditionally.\n\n### Patches\n\nUsers should update to the latest version of Cosign, `1.12.0`.\n\n### Workarounds\n\nThere are no workarounds, users should update.\n\n\n## For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [cosign](https://github.com/sigstore/cosign)\n* Send us a message on [Slack](https://sigstore.slack.com/).\n",
  "id": "GHSA-8gw7-4j42-w388",
  "modified": "2024-05-20T21:33:21Z",
  "published": "2022-09-16T19:13:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/cosign/security/advisories/GHSA-8gw7-4j42-w388"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36056"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/cosign/commit/80b79ed8b4d28ccbce3d279fd273606b5cddcc25"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/cosign"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/cosign/releases/tag/v1.12.0"
    }
  ],
  "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"
    }
  ],
  "summary": "Cosign bundle can be crafted to successfully verify a blob even if the embedded rekorBundle does not reference the given signature"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "openssl-encrypt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-01T21:11:14Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe `PublicKeyBundle.from_dict()` method in `openssl_encrypt/modules/key_bundle.py` at **lines 329-361** creates bundles from untrusted data without verifying the signature. The docstring warns to call `verify_signature()` after creation, but the `to_identity()` method (line 363-391) can convert an unverified bundle directly to an `Identity` object.\n\n### Affected Code\n\n```python\n@classmethod\ndef from_dict(cls, data: Dict) -\u003e \"PublicKeyBundle\":\n    \"\"\"\n    SECURITY: Does NOT verify signature. Call verify_signature() after creation.\n    \"\"\"\n    # Creates bundle without verification\n```\n\n### Impact\n\nIf `from_dict()` followed by `to_identity()` is called without an intervening `verify_signature()` call, encryption could be performed against an attacker\u0027s public key, leaking secrets. While `key_resolver.py` (lines 146-147) does verify before use, the unguarded API path remains directly callable.\n\n### Recommended Fix\n\n- Add a `verified` flag to `PublicKeyBundle` that must be set before `to_identity()` can be called\n- Or have `to_identity()` automatically call `verify_signature()` and raise on failure\n- Or make `from_dict()` require verification as part of construction\n\n### Fix\n\nFixed in commit `f4a1ba6` on branch `releases/1.4.x` \u2014 from_dict() now verifies self_signature by default (verify=True parameter); raises ValueError on verification failure.",
  "id": "GHSA-8h88-gxp3-j7pg",
  "modified": "2026-04-01T21:11:14Z",
  "published": "2026-04-01T21:11:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jahlives/openssl_encrypt/security/advisories/GHSA-8h88-gxp3-j7pg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jahlives/openssl_encrypt/commit/f4a1ba660063cd9e17883829e5272a248525a16b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jahlives/openssl_encrypt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "openssl-encrypt\u0027s unverified key bundle from_dict() + to_identity() path allows encryption to attacker keys"
}

{
  "affected": [],
  "aliases": [
    "CVE-2017-12331"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-11-30T09:29:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in Cisco NX-OS System Software could allow an authenticated, local attacker to bypass signature verification when loading a software patch. The vulnerability is due to insufficient NX-OS signature verification for software patches. An authenticated, local attacker could exploit this vulnerability to bypass signature verification and load a crafted, unsigned software patch on a targeted device. The attacker would need valid administrator credentials to perform this exploit. This vulnerability affects the following products running Cisco NX-OS System Software: Multilayer Director Switches, Nexus 7000 Series Switches, Nexus 7700 Series Switches, Unified Computing System Manager. Cisco Bug IDs: CSCvf16494, CSCvf23655.",
  "id": "GHSA-8hxx-pmwx-5vvq",
  "modified": "2022-05-17T00:15:06Z",
  "published": "2022-05-17T00:15:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12331"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20171129-nxos"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/102159"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1039930"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "samlify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.4.0-rc5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2017-1000452"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347",
      "CWE-91"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T21:25:47Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Versions of `samlify` prior to 2.4.0-rc5 are vulnerable to Authentication Bypass. The package fails to prevent XML Signature Wrapping, allowing tokens to be reused with different usernames. A remote attacker can modify SAML content for a SAML service provider without invalidating the cryptographic signature, which may allow attackers to bypass primary authentication for the affected SAML service provider.\n\n\n## Recommendation\n\nUpgrade to version 2.4.0-rc5 or later",
  "id": "GHSA-8jjf-w7j6-323c",
  "modified": "2023-08-18T21:00:53Z",
  "published": "2018-01-04T21:03:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-1000452"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tngan/samlify/commit/d382bbc7c6b8ea889839ae1f178730c25b09eb42"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/356284"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tngan/samlify"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tngan/samlify/compare/v2.4.0-rc4...v2.4.0-rc5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tngan/samlify/releases/tag/v2.4.0-rc5"
    },
    {
      "type": "WEB",
      "url": "https://www.whitehats.nl/blog/xml-signature-wrapping-samlify"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Samlify vulnerable to Authentication Bypass by allowing tokens to be reused with different usernames"
}

{
  "affected": [],
  "aliases": [
    "CVE-2019-8338"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-05-16T17:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The signature verification routine in the Airmail GPG-PGP Plugin, versions 1.0 (9) and earlier, does not verify the status of the signature at all, which allows remote attackers to spoof arbitrary email signatures by crafting a signed email with an invalid signature. Also, it does not verify the validity of the signing key, which allows remote attackers to spoof arbitrary email signatures by crafting a key with a fake user ID (email address) and injecting it into the user\u0027s keyring.",
  "id": "GHSA-8m6f-q6pm-9pmm",
  "modified": "2024-04-04T00:41:29Z",
  "published": "2022-05-24T16:45:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-8338"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Airmail/AirmailPlugIn-Framework/commits/master"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RUB-NDS/Johnny-You-Are-Fired"
    },
    {
      "type": "WEB",
      "url": "https://github.com/RUB-NDS/Johnny-You-Are-Fired/blob/master/paper/johnny-fired.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2019/04/30/4"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/152703/Johnny-You-Are-Fired.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2019/Apr/38"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "tough"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.22.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "tuftool"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.15.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-6966"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T18:46:09Z",
    "nvd_published_at": "2026-04-24T20:16:28Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nImproper verification of cryptographic signature uniqueness in delegated role validation in awslabs/tough before tough-v0.22.0 allows remote authenticated users to bypass the TUF signature threshold requirement by duplicating a valid signature, causing the client to accept forged delegated role metadata.\n\n### Impact\nThe tough library, prior to 0.22.0, does not properly verify the uniqueness of keys in the signatures provided to meet the threshold of cryptographic signatures in delegated targets. It allows actors with access to a valid signing key to create multiple valid signatures in order to circumvent TUF requiring a minimum threshold of unique keys before the metadata is considered valid.\n\n### Patches\nThis issue has been addressed in tough version 0.22.0 and tuftool version 0.15.0. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes. \n\n### Workarounds\nNo workarounds to this issue are known.\n\n### References\n* CVE-2026-6966\n\nIf there are any questions or comments about this advisory, please contact [AWS/Amazon] Security via the [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.\n\n### Acknowledgement\n\nAmazon Web Services Labs would like to thank Emily Albini of Oxide Computer and Oleh Konko of 1seal for collaborating on this issue through the coordinated vulnerability disclosure process",
  "id": "GHSA-8m7c-8m39-rv4x",
  "modified": "2026-05-05T18:46:09Z",
  "published": "2026-05-05T18:46:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/awslabs/tough/security/advisories/GHSA-8m7c-8m39-rv4x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6966"
    },
    {
      "type": "WEB",
      "url": "https://aws.amazon.com/security/security-bulletins/2026-019-aws"
    },
    {
      "type": "WEB",
      "url": "https://crates.io/crates/tough/0.22.0"
    },
    {
      "type": "WEB",
      "url": "https://crates.io/crates/tuftool/0.15.0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/awslabs/tough"
    },
    {
      "type": "WEB",
      "url": "https://github.com/awslabs/tough/releases/tag/tough-v0.22.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/awslabs/tough/releases/tag/tuftool-v0.15.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "awslabs/tough Delegated Roles have a Signature Threshold Bypass"
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-46774"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-14T16:15:38Z",
    "severity": "HIGH"
  },
  "details": "An Improper Verification of Cryptographic Signature vulnerability [CWE-347] in FortiClient MacOS installer version 7.4.2 and below, version 7.2.9 and below, 7.0 all versions may allow a local user to escalate their privileges via FortiClient related executables.",
  "id": "GHSA-8m8c-g2fv-f6hj",
  "modified": "2025-10-14T18:30:27Z",
  "published": "2025-10-14T18:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46774"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.fortinet.com/psirt/FG-IR-25-126"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}