{"id":"CVE-2024-51746","aliases":["EUVD-2024-3224","GHSA-8pmp-678w-c8xx","GO-2024-3252","SUSE-SU-2024:4042-1","openSUSE-SU-2024:14470-1"],"status":"published","title":"Use of incorrect Rekor entries during verification in gitsign","description":"Gitsign is a keyless Sigstore to signing tool for Git commits with your a GitHub / OIDC identity. gitsign may select the wrong Rekor entry to use during online verification when multiple entries are returned by the log. gitsign uses Rekor's search API to fetch entries that apply to a signature being verified. The parameters used for the search are the public key and the payload. The search API returns entries that match either condition rather than both. When gitsign's credential cache is used, there can be multiple entries that use the same ephemeral keypair / signing certificate. As gitsign assumes both conditions are matched by Rekor, there is no additional validation that the entry's hash matches the payload being verified, meaning that the wrong entry can be used to successfully pass verification. Impact is minimal as while gitsign does not match the payload against the entry, it does ensure that the certificate matches. This would need to be exploited during the certificate validity window (10 minutes) by the key holder.","severity":{"version":"4.0","score":1.8,"vector":"CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:A/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"low","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00116,"percentile":0.01641,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-287","CWE-706"],"published":"2024-11-05T15:26:57Z","modified":"2026-10-28T02:30:52Z","fixes":[{"ecosystem":"Go","package":"github.com/sigstore/gitsign","fixed_in":["0.11.0"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/sigstore/gitsign","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.11.0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/sigstore/gitsign","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.11.0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/sigstore/gitsign","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.11.0"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Package Hub 15 SP5","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20241112T145010-150000.1.17.1"}]}],"bundled":7},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Package Hub 15 SP6","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20241112T145010-150000.1.17.1"}]}],"bundled":7},{"source":"osv","ecosystem":"openSUSE:Leap 15.5","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20241112T145010-150000.1.17.1"}]}],"bundled":7},{"source":"osv","ecosystem":"openSUSE:Leap 15.6","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20241112T145010-150000.1.17.1"}]}],"bundled":7},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20241106T172143-1.1"}]}],"bundled":4}],"products":[{"vendor":"sigstore","product":"gitsign"}],"references":[{"url":"https://github.com/sigstore/gitsign/security/advisories/GHSA-8pmp-678w-c8xx","tags":["x_refsource_CONFIRM","advisory","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-51746","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-8pmp-678w-c8xx"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/51xxx/CVE-2024-51746.json","tags":["advisory"]},{"url":"https://github.com/sigstore/gitsign","tags":["package"]},{"url":"https://www.suse.com/support/update/announcement/2024/suse-su-20244042-1/","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2024-10389","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-10975","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-45794","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-48057","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-51735","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-51744","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-51746","tags":["web"]},{"url":"https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/OX53GMPD3MLNI5INQF5WZ3M4WW7BFHZC/","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2024-51746","title":"Use of incorrect Rekor entries during verification in gitsign","description":"Gitsign is a keyless Sigstore to signing tool for Git commits with your a GitHub / OIDC identity. gitsign may select the wrong Rekor entry to use during online verification when multiple entries are returned by the log. gitsign uses Rekor's search API to fetch entries that apply to a signature being verified. The parameters used for the search are the public key and the payload. The search API returns entries that match either condition rather than both. When gitsign's credential cache is used, there can be multiple entries that use the same ephemeral keypair / signing certificate. As gitsign assumes both conditions are matched by Rekor, there is no additional validation that the entry's hash matches the payload being verified, meaning that the wrong entry can be used to successfully pass verification. Impact is minimal as while gitsign does not match the payload against the entry, it does ensure that the certificate matches. This would need to be exploited during the certificate validity window (10 minutes) by the key holder.","status":"published","published":"2024-11-05T18:54:39.494Z","modified":"2024-11-05T20:30:02.393Z","cvss":[{"version":"4.0","score":1.8,"vector":"CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:A/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"low","assessor":"cna"}],"cwes":["CWE-706"],"updated_at":"2026-11-02T14:34:01.630882Z"}],"euvd":[{"id":"EUVD-2024-3224","description":"Gitsign is a keyless Sigstore to signing tool for Git commits with your a GitHub / OIDC identity. gitsign may select the wrong Rekor entry to use during online verification when multiple entries are returned by the log. gitsign uses Rekor's search API to fetch entries that apply to a signature being verified. The parameters used for the search are the public key and the payload. The search API returns entries that match either condition rather than both. When gitsign's credential cache is used, there can be multiple entries that use the same ephemeral keypair / signing certificate. As gitsign assumes both conditions are matched by Rekor, there is no additional validation that the entry's hash matches the payload being verified, meaning that the wrong entry can be used to successfully pass verification. Impact is minimal as while gitsign does not match the payload against the entry, it does ensure that the certificate matches. This would need to be exploited during the certificate validity window (10 minutes) by the key holder.","status":"published","published":"2024-11-05T18:54:39Z","modified":"2024-11-05T20:30:02Z","cvss":[{"version":"4.0","score":1.8,"vector":"CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:A/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"low"}],"updated_at":"2026-11-03T00:05:10.508802Z"}],"ghsa":[{"id":"GHSA-8pmp-678w-c8xx","title":"gitsign may use incorrect Rekor entries during verification","description":"### Summary\n\ngitsign may select the wrong Rekor entry to use during online verification when multiple entries are returned by the log.\n\n### Details\n\ngitsign uses Rekor's search API to fetch entries that apply to a signature being verified. The parameters used for the search are the public key and the payload. The search API returns entries that match _either_ condition rather than _both_. When gitsign's credential cache is used, there can be multiple entries that use the same ephemeral keypair / signing certificate. As gitsign assumes both conditions are matched by Rekor, there is no additional validation that the entry's hash matches the payload being verified, meaning that the wrong entry can be used to successfully pass verification.\n\n### PoC\n\nEnable the credential cache and create commit signatures using the cached signing certificate. `gitsign verify` or `git log --show-signature` will demonstrate the use of the wrong entry index for the corresponding commit. Note that this depends on the order of matching entries in the response from the Rekor search API, so it may take a few attempts to trigger this.\n\n### Impact\n\nMinimal. While gitsign does not match the payload against the entry, it does ensure that the certificate matches. This would need to be exploited during the certificate validity window (10 minutes) by the key holder.","status":"published","published":"2024-11-05T15:26:57Z","modified":"2024-11-06T19:55:45Z","cvss":[{"version":"4.0","score":1.8,"vector":"CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:A/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"low"}],"cwes":["CWE-287","CWE-706"],"updated_at":"2026-11-02T14:38:16.477822Z"}],"nvd":[{"id":"CVE-2024-51746","description":"Gitsign is a keyless Sigstore to signing tool for Git commits with your a GitHub / OIDC identity. gitsign may select the wrong Rekor entry to use during online verification when multiple entries are returned by the log. gitsign uses Rekor's search API to fetch entries that apply to a signature being verified. The parameters used for the search are the public key and the payload. The search API returns entries that match either condition rather than both. When gitsign's credential cache is used, there can be multiple entries that use the same ephemeral keypair / signing certificate. As gitsign assumes both conditions are matched by Rekor, there is no additional validation that the entry's hash matches the payload being verified, meaning that the wrong entry can be used to successfully pass verification. Impact is minimal as while gitsign does not match the payload against the entry, it does ensure that the certificate matches. This would need to be exploited during the certificate validity window (10 minutes) by the key holder.","status":"published","published":"2024-11-05T19:15:08.3Z","modified":"2026-06-17T08:06:14.353Z","cvss":[{"version":"4.0","score":1.8,"vector":"CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:A/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","level":"low","assessor":"secondary"}],"cwes":["CWE-706"],"updated_at":"2026-11-02T14:10:35.864552Z"}],"osv":[{"id":"CVE-2024-51746","title":"Use of incorrect Rekor entries during verification in gitsign","description":"Gitsign is a keyless Sigstore to signing tool for Git commits with your a GitHub / OIDC identity. gitsign may select the wrong Rekor entry to use during online verification when multiple entries are returned by the log. gitsign uses Rekor's search API to fetch entries that apply to a signature being verified. The parameters used for the search are the public key and the payload. The search API returns entries that match either condition rather than both. When gitsign's credential cache is used, there can be multiple entries that use the same ephemeral keypair / signing certificate. As gitsign assumes both conditions are matched by Rekor, there is no additional validation that the entry's hash matches the payload being verified, meaning that the wrong entry can be used to successfully pass verification. Impact is minimal as while gitsign does not match the payload against the entry, it does ensure that the certificate matches. This would need to be exploited during the certificate validity window (10 minutes) by the key holder.","status":"published","published":"2024-11-05T18:54:39.494Z","modified":"2026-10-28T02:30:52.524511989Z","cvss":[{"version":"4.0","score":1.8,"vector":"CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:A/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"low"}],"cwes":["CWE-706"],"updated_at":"2026-11-02T15:44:44.032344Z"},{"id":"GHSA-8pmp-678w-c8xx","title":"gitsign may use incorrect Rekor entries during verification","description":"### Summary\n\ngitsign may select the wrong Rekor entry to use during online verification when multiple entries are returned by the log.\n\n### Details\n\ngitsign uses Rekor's search API to fetch entries that apply to a signature being verified. The parameters used for the search are the public key and the payload. The search API returns entries that match _either_ condition rather than _both_. When gitsign's credential cache is used, there can be multiple entries that use the same ephemeral keypair / signing certificate. As gitsign assumes both conditions are matched by Rekor, there is no additional validation that the entry's hash matches the payload being verified, meaning that the wrong entry can be used to successfully pass verification.\n\n### PoC\n\nEnable the credential cache and create commit signatures using the cached signing certificate. `gitsign verify` or `git log --show-signature` will demonstrate the use of the wrong entry index for the corresponding commit. Note that this depends on the order of matching entries in the response from the Rekor search API, so it may take a few attempts to trigger this.\n\n### Impact\n\nMinimal. While gitsign does not match the payload against the entry, it does ensure that the certificate matches. This would need to be exploited during the certificate validity window (10 minutes) by the key holder.","status":"published","published":"2024-11-05T15:26:57Z","modified":"2024-11-06T19:55:44Z","cvss":[{"version":"4.0","score":1.8,"vector":"CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:A/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"low"}],"cwes":["CWE-287","CWE-706"],"updated_at":"2026-11-02T15:46:42.78452Z"},{"id":"GO-2024-3252","title":"gitsign may use incorrect Rekor entries during verification in github.com/sigstore/gitsign","description":"gitsign may use incorrect Rekor entries during verification in github.com/sigstore/gitsign","status":"published","published":"2024-11-06T17:21:43Z","modified":"2026-03-03T04:56:00.623204Z","updated_at":"2026-11-02T15:47:01.453823Z"},{"id":"openSUSE-SU-2024:14470-1","title":"govulncheck-vulndb-0.0.20241106T172143-1.1 on GA media","description":"These are all security issues fixed in the govulncheck-vulndb-0.0.20241106T172143-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2024-11-07T00:00:00Z","modified":"2026-02-04T02:36:04.785647Z","updated_at":"2026-11-02T16:58:36.976155Z"},{"id":"SUSE-SU-2024:4042-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20241112T145010 2024-11-12T14:50:10Z.\n  Refs jsc#PED-11136\n  Go CVE Numbering Authority IDs added or updated with aliases:\n  * GO-2024-3250 CVE-2024-51744 GHSA-29wx-vh33-7x7r\n\n- Update to version 0.0.20241108T172500 2024-11-08T17:25:00Z.\n  Refs jsc#PED-11136\n  Go CVE Numbering Authority IDs added or updated with aliases:\n  * GO-2024-3260 CVE-2024-45794 GHSA-q78v-cv36-8fxj\n  * GO-2024-3262 CVE-2024-10975 GHSA-2w5v-x29g-jw7j\n\n- Update to version 0.0.20241106T172143 2024-11-06T17:21:43Z.\n  Refs jsc#PED-11136\n  Go CVE Numbering Authority IDs added or updated with aliases:\n  * GO-2024-3251 CVE-2024-10389 GHSA-q3rp-vvm7-j8jg\n  * GO-2024-3252 CVE-2024-51746 GHSA-8pmp-678w-c8xx\n  * GO-2024-3253 CVE-2024-48057 GHSA-ghx4-cgxw-7h9p\n  * GO-2024-3254 CVE-2024-51735 GHSA-wvv7-wm5v-w2gv\n","status":"published","published":"2024-11-22T10:44:11Z","modified":"2026-02-04T19:52:46.813701Z","updated_at":"2026-11-02T15:53:55.639015Z"}]}}