CWE-295
AllowedImproper Certificate Validation
Abstraction: Base · Status: Draft
The product does not validate, or incorrectly validates, a certificate.
2141 vulnerabilities reference this CWE, most recent first.
GHSA-W9C6-W29V-4VP6
Vulnerability from github – Published: 2026-08-17 21:31 – Updated: 2026-09-02 00:31A flaw was found in the managedcluster-import-controller. The Certificate Signing Request (CSR) auto-approval logic improperly validates incoming CSRs, specifically by not inspecting the signer name or decoding the PEM-encoded x509 CSR. This vulnerability allows a privileged service account on a spoke cluster to submit a malicious CSR. Successful exploitation can lead to privilege escalation, enabling the attacker to obtain administrative credentials on the hub cluster.
{
"affected": [],
"aliases": [
"CVE-2026-66795"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-17T21:16:47Z",
"severity": "CRITICAL"
},
"details": "A flaw was found in the managedcluster-import-controller. The Certificate Signing Request (CSR) auto-approval logic improperly validates incoming CSRs, specifically by not inspecting the signer name or decoding the PEM-encoded x509 CSR. This vulnerability allows a privileged service account on a spoke cluster to submit a malicious CSR. Successful exploitation can lead to privilege escalation, enabling the attacker to obtain administrative credentials on the hub cluster.",
"id": "GHSA-w9c6-w29v-4vp6",
"modified": "2026-09-02T00:31:27Z",
"published": "2026-08-17T21:31:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-66795"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:59556"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:59557"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:59558"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:59559"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:59579"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:59593"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-66795"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2507540"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W9PH-5M4X-C49R
Vulnerability from github – Published: 2022-03-11 00:02 – Updated: 2022-03-17 00:01A flaw was found in Cockpit in versions prior to 260 in the way it handles the certificate verification performed by the System Security Services Daemon (SSSD). This flaw allows client certificates to authenticate successfully, regardless of the Certificate Revocation List (CRL) configuration or the certificate status. The highest threat from this vulnerability is to confidentiality.
{
"affected": [],
"aliases": [
"CVE-2021-3698"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-10T17:42:00Z",
"severity": "HIGH"
},
"details": "A flaw was found in Cockpit in versions prior to 260 in the way it handles the certificate verification performed by the System Security Services Daemon (SSSD). This flaw allows client certificates to authenticate successfully, regardless of the Certificate Revocation List (CRL) configuration or the certificate status. The highest threat from this vulnerability is to confidentiality.",
"id": "GHSA-w9ph-5m4x-c49r",
"modified": "2022-03-17T00:01:58Z",
"published": "2022-03-11T00:02:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3698"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1992149"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WC4X-4GM2-74J8
Vulnerability from github – Published: 2022-02-10 20:51 – Updated: 2023-09-27 11:18When TLS is enabled with ssl-endpoint-identification-enabled set to true, Apache Geode fails to perform hostname verification of the entries in the certificate SAN during the SSL handshake. This could compromise intra-cluster communication using a man-in-the-middle attack.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.geode:geode-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.10.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-10091"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-03T21:28:10Z",
"nvd_published_at": "2020-03-16T14:15:00Z",
"severity": "HIGH"
},
"details": "When TLS is enabled with ssl-endpoint-identification-enabled set to true, Apache Geode fails to perform hostname verification of the entries in the certificate SAN during the SSL handshake. This could compromise intra-cluster communication using a man-in-the-middle attack.",
"id": "GHSA-wc4x-4gm2-74j8",
"modified": "2023-09-27T11:18:14Z",
"published": "2022-02-10T20:51:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10091"
},
{
"type": "WEB",
"url": "https://github.com/apache/geode/pull/3849"
},
{
"type": "WEB",
"url": "https://github.com/apache/geode/commit/e57028fd62a2f5980ea6c9a7ab89ada06c828634"
},
{
"type": "WEB",
"url": "https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-SecurityVulnerabilities"
},
{
"type": "WEB",
"url": "https://issues.apache.org/jira/browse/GEODE-7018"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3342077ac4798631300366be86e545d0c08753cca8fd2663867fe200%40%3Cdev.geode.apache.org%3E"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Apache Geode SSL endpoint verification vulnerability"
}
GHSA-WC6F-CJCP-CC33
Vulnerability from github – Published: 2022-01-06 19:45 – Updated: 2021-05-25 20:27An issue was found in Apache IoTDB .9.0 to 0.9.1 and 0.8.0 to 0.8.2. When starting IoTDB, the JMX port 31999 is exposed with no certification.Then, clients could execute code remotely.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.iotdb:iotdb-parent"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.9.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-1952"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-25T20:27:25Z",
"nvd_published_at": "2020-04-27T17:15:00Z",
"severity": "HIGH"
},
"details": "An issue was found in Apache IoTDB .9.0 to 0.9.1 and 0.8.0 to 0.8.2. When starting IoTDB, the JMX port 31999 is exposed with no certification.Then, clients could execute code remotely.",
"id": "GHSA-wc6f-cjcp-cc33",
"modified": "2021-05-25T20:27:25Z",
"published": "2022-01-06T19:45:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1952"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3d2ff899ead64d2952fdc1fbb1f520ca42011ed2b4c7f786e921f6b9%40%3Cdev.iotdb.apache.org%3E"
}
],
"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": "Improper Certificate Validation in Apache IoTDB"
}
GHSA-WC6M-WGGM-HJR8
Vulnerability from github – Published: 2026-08-01 15:30 – Updated: 2026-08-01 15:30FreeRDP before 3.29.0 (affected versions <= 3.28.0) contains an improper certificate hostname validation vulnerability. The TLS hostname matcher (tls_match_hostname() in libfreerdp/crypto/tls.c) treats a wildcard pattern such as *.example.com as matching any hostname ending in .example.com, so it incorrectly accepts a wildcard certificate for multi-label subdomains like a.b.example.com (which OpenSSL's X509_check_host() rejects). This weakens TLS server authentication under wildcard-certificate conditions.
{
"affected": [],
"aliases": [
"CVE-2026-67293"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-01T13:16:58Z",
"severity": "CRITICAL"
},
"details": "FreeRDP before 3.29.0 (affected versions \u003c= 3.28.0) contains an improper certificate hostname validation vulnerability. The TLS hostname matcher (tls_match_hostname() in libfreerdp/crypto/tls.c) treats a wildcard pattern such as *.example.com as matching any hostname ending in .example.com, so it incorrectly accepts a wildcard certificate for multi-label subdomains like a.b.example.com (which OpenSSL\u0027s X509_check_host() rejects). This weakens TLS server authentication under wildcard-certificate conditions.",
"id": "GHSA-wc6m-wggm-hjr8",
"modified": "2026-08-01T15:30:25Z",
"published": "2026-08-01T15:30:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FreeRDP/FreeRDP/security/advisories/GHSA-5wr6-8m8j-3h7f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-67293"
},
{
"type": "WEB",
"url": "https://github.com/FreeRDP/FreeRDP/commit/f3b4347105114fe7453828736bea069999af319f"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/freerdp-before-improper-certificate-hostname-validation"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N",
"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: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-WC82-HQX6-G35Q
Vulnerability from github – Published: 2026-08-12 21:31 – Updated: 2026-08-12 21:31When kuma-dp is started against an HTTPS control plane and the operator did not pass a CA certificate, the data plane connects with TLS peer verification disabled, and the dataplane authentication token is sent over that unverified connection.
An on-path actor can intercept the dataplane authentication token and impersonate the control plane to the data plane, injecting a forged bootstrap configuration and taking over the proxy.
{
"affected": [],
"aliases": [
"CVE-2026-18679"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-12T20:17:41Z",
"severity": "MODERATE"
},
"details": "When kuma-dp is started against an HTTPS control plane and the operator did not pass a CA certificate, the data plane connects with TLS peer verification disabled, and the dataplane authentication token is sent over that unverified connection.\n\n\n\nAn on-path actor can intercept the dataplane authentication token and impersonate the control plane to the data plane, injecting a forged bootstrap configuration and taking over the proxy.",
"id": "GHSA-wc82-hqx6-g35q",
"modified": "2026-08-12T21:31:40Z",
"published": "2026-08-12T21:31:40Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kumahq/kuma/security/advisories/GHSA-wvmp-6r4v-j6cv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-18679"
},
{
"type": "WEB",
"url": "https://github.com/kumahq/kuma/pull/16777"
},
{
"type": "WEB",
"url": "https://developer.konghq.com/mesh/changelog"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H/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-WCFR-WFM2-2RJM
Vulnerability from github – Published: 2022-05-13 01:01 – Updated: 2022-05-13 01:01An exploitable denial of service vulnerability exists within the reading of proprietary server certificates in FreeRDP 2.0.0-beta1+android11. A specially crafted challenge packet can cause the program termination leading to a denial of service condition. An attacker can compromise the server or use man in the middle to trigger this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2017-2836"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-04-24T19:29:00Z",
"severity": "MODERATE"
},
"details": "An exploitable denial of service vulnerability exists within the reading of proprietary server certificates in FreeRDP 2.0.0-beta1+android11. A specially crafted challenge packet can cause the program termination leading to a denial of service condition. An attacker can compromise the server or use man in the middle to trigger this vulnerability.",
"id": "GHSA-wcfr-wfm2-2rjm",
"modified": "2022-05-13T01:01:23Z",
"published": "2022-05-13T01:01:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-2836"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2017/dsa-3923"
},
{
"type": "WEB",
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0338"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/99942"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-WCW9-6J3M-22M2
Vulnerability from github – Published: 2026-03-11 21:31 – Updated: 2026-03-11 21:31An improper certificate validation vulnerability was reported in the Lenovo Filez application that could allow a user capable of intercepting network traffic to execute arbitrary code.
{
"affected": [],
"aliases": [
"CVE-2026-2368"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-11T21:16:15Z",
"severity": "HIGH"
},
"details": "An improper certificate validation vulnerability was reported in the Lenovo Filez application that could allow a user capable of intercepting network traffic to execute arbitrary code.",
"id": "GHSA-wcw9-6j3m-22m2",
"modified": "2026-03-11T21:31:04Z",
"published": "2026-03-11T21:31:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2368"
},
{
"type": "WEB",
"url": "https://www.filez.com/securityPolicy"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/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"
}
]
}
GHSA-WF9J-M9FV-92GQ
Vulnerability from github – Published: 2022-05-17 19:57 – Updated: 2024-10-08 12:56ovirt-engine-sdk-python before 3.4.0.7 and 3.5.0.4 does not verify that the hostname of the remote endpoint matches the Common Name (CN) or subjectAltName as specified by its x.509 certificate in a TLS/SSL session. This could allow man-in-the-middle attackers to spoof remote endpoints via an arbitrary valid certificate.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "ovirt-engine-sdk-python"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.4.0.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "ovirt-engine-sdk-python"
},
"ranges": [
{
"events": [
{
"introduced": "3.5.0.0"
},
{
"fixed": "3.5.0.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2014-0161"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2023-10-19T17:37:44Z",
"nvd_published_at": "2020-01-02T18:15:00Z",
"severity": "HIGH"
},
"details": "ovirt-engine-sdk-python before 3.4.0.7 and 3.5.0.4 does not verify that the hostname of the remote endpoint matches the Common Name (CN) or subjectAltName as specified by its x.509 certificate in a TLS/SSL session. This could allow man-in-the-middle attackers to spoof remote endpoints via an arbitrary valid certificate.",
"id": "GHSA-wf9j-m9fv-92gq",
"modified": "2024-10-08T12:56:21Z",
"published": "2022-05-17T19:57:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-0161"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/cve-2014-0161"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-0161"
},
{
"type": "PACKAGE",
"url": "https://github.com/oVirt/python-ovirt-engine-sdk4"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/ovirt-engine-sdk-python/PYSEC-2020-245.yaml"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "ovirt-engine-sdk-python improper validation of hostname in x.509 certificate"
}
GHSA-WFQV-66VQ-46RM
Vulnerability from github – Published: 2026-02-19 22:09 – Updated: 2026-02-20 16:43Summary
When verifying artifact signatures using a certificate, Cosign first verifies the certificate chain using the leaf certificate's "not before" timestamp and later checks expiry of the leaf certificate using either a signed timestamp provided by the Rekor transparency log or from a timestamp authority, or using the current time. The root and all issuing certificates are assumed to be valid during the leaf certificate's validity. An issuing certificate with a validity that expires before the leaf certificate will be considered valid during verification even if the provided timestamp would mean the issuing certificate should be considered expired.
Impact
No impact to users of the public Sigstore infrastructure. This may affect private deployments with customized PKIs. In practice, this is unlikely to occur as CAs should not be issuing certificates that outlive the validity of the CA and its parents.
Workarounds
Upgrade to the latest release, or verify the certificate chain out of band.
Example to Reproduce
- Root CA certificate is valid from 12pm-2pm
- Intermediate CA certificate is valid from 12:30pm-1:30pm
- Leaf certificate is valid from 1pm-3pm - Note that this is unlikely to happen in practice, as a CA shouldn't issue a certificate that would be valid after the issuing CA certificate expires
- Signature generated at 2:30pm with a signed timestamp
- During verification, the leaf certificate's not before time (1pm) is used to verify the chain - 1pm is in the validity windows for the root and intermediate CA certificates
- The timestamp's time is checked to be in the validity window of only the leaf certificate - 2:30pm is in the validity window for the leaf
- Even though the root and intermediate would be expired at 2:30pm, verification succeeds
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.4"
},
"package": {
"ecosystem": "Go",
"name": "github.com/sigstore/cosign"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-24122"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-19T22:09:12Z",
"nvd_published_at": "2026-02-19T23:16:24Z",
"severity": "LOW"
},
"details": "## Summary\n\nWhen verifying artifact signatures using a certificate, Cosign first verifies the certificate chain using the leaf certificate\u0027s \"not before\" timestamp and later checks expiry of the leaf certificate using either a signed timestamp provided by the Rekor transparency log or from a timestamp authority, or using the current time. The root and all issuing certificates are assumed to be valid during the leaf certificate\u0027s validity. An issuing certificate with a validity that expires before the leaf certificate will be considered valid during verification even if the provided timestamp would mean the issuing certificate should be considered expired.\n\n## Impact\n\nNo impact to users of the public Sigstore infrastructure. This may affect private deployments with customized PKIs. In practice, this is unlikely to occur as CAs should not be issuing certificates that outlive the validity of the CA and its parents.\n\n## Workarounds\n\nUpgrade to the latest release, or verify the certificate chain out of band.\n\n## Example to Reproduce\n\n* Root CA certificate is valid from 12pm-2pm\n* Intermediate CA certificate is valid from 12:30pm-1:30pm\n* Leaf certificate is valid from 1pm-3pm - **Note that this is unlikely to happen in practice**, as a CA shouldn\u0027t issue a certificate that would be valid after the issuing CA certificate expires\n* Signature generated at 2:30pm with a signed timestamp\n* During verification, the leaf certificate\u0027s not before time (1pm) is used to verify the chain - 1pm is in the validity windows for the root and intermediate CA certificates\n* The timestamp\u0027s time is checked to be in the validity window of only the leaf certificate - 2:30pm is in the validity window for the leaf\n* Even though the root and intermediate would be expired at 2:30pm, verification succeeds",
"id": "GHSA-wfqv-66vq-46rm",
"modified": "2026-02-20T16:43:55Z",
"published": "2026-02-19T22:09:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sigstore/cosign/security/advisories/GHSA-wfqv-66vq-46rm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24122"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/cosign/commit/3c9a7363f563db76d78e2de2cabd945450f3781e"
},
{
"type": "PACKAGE",
"url": "https://github.com/sigstore/cosign"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/cosign/releases/tag/v3.0.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Cosign considered signatures valid with expired intermediate certificates when transparency log verification is skipped"
}
Mitigation
Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.
Mitigation
If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the hostname.
CAPEC-459: Creating a Rogue Certification Authority Certificate
An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.
CAPEC-475: Signature Spoofing by Improper Validation
An adversary exploits a cryptographic weakness in the signature verification algorithm implementation to generate a valid signature without knowing the key.