CWE-347

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "portage"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.47"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2016-20021"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-08-30T23:37:34Z",
    "nvd_published_at": "2024-01-12T03:15:08Z",
    "severity": "HIGH"
  },
  "details": "In Gentoo Portage before 3.0.47, there is missing PGP validation of executed code: the standalone emerge-webrsync downloads a .gpgsig file but does not perform signature verification.",
  "id": "GHSA-pw5x-x5jw-ccmh",
  "modified": "2024-08-30T23:37:34Z",
  "published": "2024-01-12T03:30:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-20021"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gentoo/portage/commit/28cd240fb23d880b8641a058831c6762db71c3e2"
    },
    {
      "type": "WEB",
      "url": "https://bugs.gentoo.org/597800"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gentoo/portage"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/portage/PYSEC-2024-10.yaml"
    },
    {
      "type": "WEB",
      "url": "https://gitweb.gentoo.org/proj/portage.git/tree/NEWS"
    },
    {
      "type": "WEB",
      "url": "https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5b3c80502e96406b4b175e2ee79eb65f3f3cd9f6"
    },
    {
      "type": "WEB",
      "url": "https://wiki.gentoo.org/wiki/Portage"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Gentoo Portage missing PGP validation of executed code"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tuf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.12.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-6174"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-08-21T16:25:02Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Impact\nMetadadata signature verification, as used in `tuf.client.updater`, counted each of multiple signatures with identical authorized keyids  separately towards the threshold. Therefore, an attacker with access to a valid signing key could create multiple valid signatures in order to meet the minimum threshold of keys before the metadata was considered valid.\n\nThe tuf maintainers would like to thank Erik MacLean of Analog Devices, Inc. for reporting this issue.\n\n### Patches\nA [fix](https://github.com/theupdateframework/tuf/pull/974) is available in version [0.12.2](https://github.com/theupdateframework/tuf/releases/tag/v0.12.2) or newer.\n\n### Workarounds\nNo workarounds are known for this issue.\n\n### References\n* [CVE-2020-6174](https://nvd.nist.gov/vuln/detail/CVE-2020-6174)\n* Pull request resolving the issue [PR 974](https://github.com/theupdateframework/tuf/pull/974)",
  "id": "GHSA-pwqf-9h7j-7mv8",
  "modified": "2024-11-18T22:40:36Z",
  "published": "2020-08-21T16:25:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/theupdateframework/tuf/security/advisories/GHSA-pwqf-9h7j-7mv8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-6174"
    },
    {
      "type": "WEB",
      "url": "https://github.com/theupdateframework/tuf/pull/974"
    },
    {
      "type": "WEB",
      "url": "https://github.com/theupdateframework/python-tuf/commit/2977188139d065ff3356c3cb4aec60c582b57e0e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tuf/PYSEC-2020-147.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/theupdateframework/tuf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/theupdateframework/tuf/releases/tag/v0.12.2"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Incorrect threshold signature computation in TUF"
}

{
  "affected": [],
  "aliases": [
    "CVE-2019-1736"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-09-23T01:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the firmware of the Cisco UCS C-Series Rack Servers could allow an authenticated, physical attacker to bypass Unified Extensible Firmware Interface (UEFI) Secure Boot validation checks and load a compromised software image on an affected device. The vulnerability is due to improper validation of the server firmware upgrade images. An attacker could exploit this vulnerability by installing a server firmware version that would allow the attacker to disable UEFI Secure Boot. A successful exploit could allow the attacker to bypass the signature validation checks that are done by UEFI Secure Boot technology and load a compromised software image on the affected device. A compromised software image is any software image that has not been digitally signed by Cisco.",
  "id": "GHSA-pwvv-633w-65j9",
  "modified": "2022-05-24T17:29:15Z",
  "published": "2022-05-24T17:29:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1736"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20200219-ucs-boot-bypass"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-47827"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-05T14:15:32Z",
    "severity": "HIGH"
  },
  "details": "In IGEL OS before 11, Secure Boot can be bypassed because the igel-flash-driver module improperly verifies a cryptographic signature. Ultimately, a crafted root filesystem can be mounted from an unverified SquashFS image.",
  "id": "GHSA-pww7-j9v6-xc6j",
  "modified": "2025-10-22T00:33:18Z",
  "published": "2025-06-05T15:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47827"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Zedeldi/CVE-2025-47827"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Zedeldi/igelfs"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2025-47827"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2025-47827"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2017-8177"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-11-22T19:29:00Z",
    "severity": "MODERATE"
  },
  "details": "Huawei APP HiWallet earlier than 5.0.3.100 versions do not support signature verification for APK file. An attacker could exploit this vulnerability to hijack the APK and upload modified APK file. Successful exploit could lead to the APP is hijacking.",
  "id": "GHSA-pxvh-phh5-pgf4",
  "modified": "2022-05-17T00:16:40Z",
  "published": "2022-05-17T00:16:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8177"
    },
    {
      "type": "WEB",
      "url": "http://www.huawei.com/en/psirt/security-advisories/huawei-sa-20170816-01-app-en"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@lionello/secp256k1-js"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-41340"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-09-27T22:34:59Z",
    "nvd_published_at": "2022-09-24T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "The secp256k1-js package before 1.1.0 for Node.js implements ECDSA without required r and s validation, leading to signature forgery.",
  "id": "GHSA-q3f4-9h4p-vgr3",
  "modified": "2022-09-29T10:09:03Z",
  "published": "2022-09-25T00:00:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41340"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lionello/secp256k1-js/issues/11"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lionello/secp256k1-js/commit/302800f0370b42e360a33774bb808274ac729c2e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lionello/secp256k1-js"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lionello/secp256k1-js/compare/1.0.1...1.1.0"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/package/@lionello/secp256k1-js"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "secp256k1-js implements ECDSA without required r and s validation, leading to signature forgery"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "titon/framework"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.1.0-alpha"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-30T13:41:36Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "titon/framework package (which is now abandoned and no longer maintained) is vulnerable to remote code execution via Chosen-Ciphertext Attack.",
  "id": "GHSA-q3jm-v27q-jfww",
  "modified": "2024-05-30T13:41:36Z",
  "published": "2024-05-30T13:41:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/titon/framework/issues/93"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/titon/framework/2017-11-20.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/titon/framework"
    }
  ],
  "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"
    }
  ],
  "summary": "titon/framework vulnerable to Remote Code Execution via Chosen-Ciphertext Attack"
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-28751"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-17T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "The Zoom Client for Meetings for MacOS (Standard and for IT Admin) before version 5.11.3 contains a vulnerability in the package signature validation during the update process. A local low-privileged user could exploit this vulnerability to escalate their privileges to root.",
  "id": "GHSA-q3r7-w45x-phvh",
  "modified": "2022-08-20T00:00:58Z",
  "published": "2022-08-18T00:00:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28751"
    },
    {
      "type": "WEB",
      "url": "https://explore.zoom.us/en/trust/security/security-bulletin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-94418"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-27T09:16:36Z",
    "severity": "LOW"
  },
  "details": "Under WOLFSSL_SMALL_CERT_VERIFY, ProcessPeerCertParse() runs the certificate signature check separately from the parse to keep peak memory down, then merges the two results, but it merged the signature result back only when the parse returned 0, so any parse error hid it. ParseCertRelative() reaches its validity-date, name-constraint and critical-extension checks only after ConfirmSignature() has passed, so splitting the signature check out inverts the precedence that makes \"override date errors\" a sound policy, and ASN_SIG_CONFIRM_E is never surfaced anywhere. The attacker needs no key material from the real PKI and no CA compromise: a self-made certificate carrying the expected subject name, the trusted CA\u0027s subject as its issuer, arbitrary bytes where the signature goes, a validity window in the past and the attacker\u0027s own key pair is sufficient. Affected builds define WOLFSSL_SMALL_CERT_VERIFY, which is off by default, is not set implicitly by any platform or preset header, and is not reachable from any CMake option; the autotools routes are --enable-lowresource, --enable-leantls, --enable-tinytls13=cert and --enable-tinytls13=mutualauth, and examples/configs/user_settings_embedded.h reaches it through WC_CFG_SMALL_CERT_VERIFY, which ships as 0, while neither --enable-all nor --enable-distro enables it at all. The application must additionally install a verify callback through wolfSSL_CTX_set_verify() or wolfSSL_set_verify() with WOLFSSL_VERIFY_PEER that returns 1 for ASN_BEFORE_DATE_E or ASN_AFTER_DATE_E; wolfSSL ships this exact shape as myVerify() in wolfssl/test.h under VERIFY_OVERRIDE_DATE_ERR, which examples/client -D selects. An application with no callback, or whose callback returns preverify for date errors, still fails the handshake, and wolfSSL_CertManagerVerifyBuffer() and wc_CheckCertSignature() report ASN_SIG_CONFIRM_E correctly in the same binary. TLS 1.2 and TLS 1.3 are affected in both directions, and DTLS reaches the same function; where the forged certificate is a chain certificate the callback\u0027s consent causes it to be cached in the WOLFSSL_CTX certificate manager, so an exposed deployment must restart the context or the process rather than merely reconnect.",
  "id": "GHSA-q4rg-xp99-jj6q",
  "modified": "2026-10-02T21:31:57Z",
  "published": "2026-09-27T09:31:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-94418"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wolfSSL/wolfssl/pull/11500"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "dev.sigstore:sigstore-java"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.0.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2024-53267"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-11-26T16:38:18Z",
    "nvd_published_at": "2024-11-26T19:15:30Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nsigstore-java has insufficient verification for a situation where a validly-signed but \"mismatched\" bundle is presented as proof of inclusion into a transparency log\n\n### Impact\n\nThis bug impacts clients using any variation of KeylessVerifier.verify()\n\nThe verifier may accept a bundle with an unrelated log entry, cryptographically verifying everything but fails to ensure the log entry applies to the artifact in question, thereby \"verifying\" a bundle without any proof the signing event was logged.\n\nThis allows the creation of a bundle without fulcio certificate and private key combined with an unrelated but time-correct log entry to fake logging of a signing event. A malicious actor using a compromised identity may want to do this to prevent discovery via rekor\u0027s log monitors.\n\nThe signer\u0027s identity will still be available to the verifier. The signature on the bundle must still be on the correct artifact for the verifier to pass.\n\nsigstore-gradle-plugin and sigstore-maven-plugin are not affected by this as they only provide signing functionality.\n\n### Steps To Reproduce\n\nBuild the java sigstore-cli at v1.0.0\n```shell\ngit clone --branch v1.0.0 git@github.com:sigstore/sigstore-java\ncd sigstore-java\n./gradlew :sigstore-cli:build\ntar -xf sigstore-cli/build/distributions/sigstore-cli-1.0.0-SNAPSHOT.tar --strip-components 1\n```\n\nCreate two random blobs\n```shell\ndd bs=1 count=50 \u003c/dev/urandom \u003e blob1\ndd bs=1 count=50 \u003c/dev/urandom \u003e blob2\n```\n\nSign each blob using the cli\n```shell\n./bin/sigstore-cli sign --bundle=blob1.sigstore.json blob1\n./bin/sigstore-cli sign --bundle=blob2.sigstore.json blob2\n```\n\nCreate a falsified bundle including the base64Signature and cert fields from blob1\u0027s bundle and the rekorBundle from blob2\u0027s bundle\n```shell\njq --slurpfile bundle2 blob2.sigstore.json \u0027.verificationMaterial.tlogEntries = $bundle2[0].verificationMaterial.tlogEntries\u0027 blob1.sigstore.json \u003e invalidBundle.sigstore.json\n```\n\nFind the embedded artifact hash in the bundle, and compare to the sha256 sums of blob1 and blob2. See that the bundle tlog entry matches blob2.\n```shell\ncat invalidBundle.sigstore.json | jq -r \u0027.verificationMaterial.tlogEntries[0].canonicalizedBody\u0027 | base64 -d | jq -r \u0027.spec.data.hash.value\u0027\n\nsha256sum blob1 blob2\n```\n\nVerify the bundle against blob1\n```shell\n./bin/sigstore-cli verify --bundle=invalidBundle.sigstore.json blob1\n# no errors???!\n```\n\n### Patches\nPatched in v1.1.0 release with https://github.com/sigstore/sigstore-java/pull/856\nAdded conformance test for all clients in: https://github.com/sigstore/sigstore-conformance/pull/166\n\n### Workarounds\n1. Verifiers can recreate the log entry and compare it to the provided log entry.\n```\nvar bundle = Bundle.from(bundleFile, StandardCharsets.UTF_8);\nvar rekorEntry = bundle.getEntries().get(0);\nvar calculatedHashedRekord =\n    Base64.toBase64String(\n        HashedRekordRequest.newHashedRekordRequest(\n                artifactDigest,\n                Certificates.toPemBytes(Certificates.getLeaf(bundle.getCertPath())),\n                bundle.getMessageSignature().get().getSignature())\n            .toJsonPayload()\n            .getBytes(StandardCharsets.UTF_8));\nif (!Objects.equals(calculatedHashedRekord, rekorEntry.getBody())) {\n  throw new Exception(\"Provided verification materials are inconsistent with log entry\");\n}\n```\n2. Verifiers can contact the log and discover if the artifact signing event has indeed been added to the log\n```java\nvar bundle = Bundle.from(bundleFile, StandardCharsets.UTF);\nvar artifactDigest = Files.asByteSource(Path.of(artifact).toFile()).hash(Hashing.sha256()).asBytes();\nvar sigstoreTufClientBuilder = SigstoreTufClient.builder().usePublicGoodInstance();\nvar trustedRootProvider = TrustedRootProvider.from(sigstoreTufClientBuilder);\nvar entry = RekorEntryFetcher.fromTrustedRoot(trustedRootProvider).getEntryFromRekor(artifactDigest, Certificates.getLeaf(bundle.getCertPath()), bundle.getMessageSignature().get().getSignature());\nRekorVerifier.newRekorVerifier(trustedRootProvider.get()).verifyEntry(entry);\n```\n",
  "id": "GHSA-q4xm-6fjc-5f6w",
  "modified": "2024-12-09T17:00:45Z",
  "published": "2024-11-26T16:38:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore-java/security/advisories/GHSA-q4xm-6fjc-5f6w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53267"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore-conformance/pull/166"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore-java/pull/856"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/sigstore-java"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "sigstore-java has vulnerability with bundle verification"
}