CWE-295
AllowedImproper Certificate Validation
Abstraction: Base · Status: Draft
The product does not validate, or incorrectly validates, a certificate.
1913 vulnerabilities reference this CWE, most recent first.
GHSA-77H8-XR85-3X5Q
Vulnerability from github – Published: 2022-05-13 01:36 – Updated: 2023-01-27 00:52Hammer CLI, a CLI utility for Foreman, before version 0.10.0, did not explicitly set the verify_ssl flag for apipie-bindings that disable it by default. As a result the server certificates are not checked and connections are prone to man-in-the-middle attacks.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "hammer_cli_foreman"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.10.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2017-2667"
],
"database_specific": {
"cwe_ids": [
"CWE-295",
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2023-01-27T00:52:31Z",
"nvd_published_at": "2018-03-12T15:29:00Z",
"severity": "HIGH"
},
"details": "Hammer CLI, a CLI utility for Foreman, before version 0.10.0, did not explicitly set the verify_ssl flag for apipie-bindings that disable it by default. As a result the server certificates are not checked and connections are prone to man-in-the-middle attacks.",
"id": "GHSA-77h8-xr85-3x5q",
"modified": "2023-01-27T00:52:31Z",
"published": "2022-05-13T01:36:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-2667"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2018:0336"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1436262"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/hammer_cli_foreman/CVE-2017-2667.yml"
},
{
"type": "PACKAGE",
"url": "https://github.com/theforeman/hammer-cli-foreman"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20200227181720/http://www.securityfocus.com/bid/97153"
},
{
"type": "WEB",
"url": "http://projects.theforeman.org/issues/19033"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/97153"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "hammer_cli_foreman Improper Certificate Validation vulnerability"
}
GHSA-77RC-X84Q-PV4F
Vulnerability from github – Published: 2019-01-25 16:19 – Updated: 2024-09-04 20:53The LDAP auth backend (airflow.contrib.auth.backends.ldap_auth) prior to Apache Airflow 1.10.1 was misconfigured and contained improper checking of exceptions which disabled server certificate checking.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "apache-airflow"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.10.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-20245"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2020-06-16T21:21:58Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "The LDAP auth backend (airflow.contrib.auth.backends.ldap_auth) prior to Apache Airflow 1.10.1 was misconfigured and contained improper checking of exceptions which disabled server certificate checking.",
"id": "GHSA-77rc-x84q-pv4f",
"modified": "2024-09-04T20:53:34Z",
"published": "2019-01-25T16:19:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-20245"
},
{
"type": "WEB",
"url": "https://github.com/apache/airflow/commit/28abf87bd173cc4cedc57f553118470e5745a968"
},
{
"type": "WEB",
"url": "https://github.com/apache/airflow/commit/66d0d05ea0802aec407e0ef5435a962080db0926"
},
{
"type": "WEB",
"url": "https://github.com/apache/airflow/commit/d8d0e8c59203f793f81d47d5adb1362df0b5d8d1"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-77rc-x84q-pv4f"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/airflow"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/apache-airflow/PYSEC-2019-143.yaml"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/b549c7573b342a6e457e5a3225c33054244343927bbfb2a4cdc4cf73@%3Cdev.airflow.apache.org%3E"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Improper Certificate Validation in Apache Airflow"
}
GHSA-786P-JMMH-GC9X
Vulnerability from github – Published: 2023-04-12 06:30 – Updated: 2024-04-04 03:25An issue was discovered in x509/x509_verify.c in LibreSSL before 3.6.1, and in OpenBSD before 7.2 errata 001. x509_verify_ctx_add_chain does not store errors that occur during leaf certificate verification, and therefore an incorrect error is returned. This behavior occurs when there is an installed verification callback that instructs the verifier to continue upon detecting an invalid certificate.
{
"affected": [],
"aliases": [
"CVE-2022-48437"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-12T05:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in x509/x509_verify.c in LibreSSL before 3.6.1, and in OpenBSD before 7.2 errata 001. x509_verify_ctx_add_chain does not store errors that occur during leaf certificate verification, and therefore an incorrect error is returned. This behavior occurs when there is an installed verification callback that instructs the verifier to continue upon detecting an invalid certificate.",
"id": "GHSA-786p-jmmh-gc9x",
"modified": "2024-04-04T03:25:05Z",
"published": "2023-04-12T06:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48437"
},
{
"type": "WEB",
"url": "https://github.com/openbsd/src/commit/4f94258c65a918ee3d8670e93916d15bf879e6ec"
},
{
"type": "WEB",
"url": "https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.6.1-relnotes.txt"
},
{
"type": "WEB",
"url": "https://ftp.openbsd.org/pub/OpenBSD/patches/7.2/common/001_x509.patch.sig"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-78C9-5P24-9JCG
Vulnerability from github – Published: 2024-09-06 18:31 – Updated: 2024-09-16 14:37An improper certificate validation vulnerability has been reported to affect QuMagie. If exploited, the vulnerability could allow local network users to compromise the security of the system via unspecified vectors.
We have already fixed the vulnerability in the following version: QuMagie 2.3.1 and later
{
"affected": [],
"aliases": [
"CVE-2024-38642"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-06T17:15:16Z",
"severity": "LOW"
},
"details": "An improper certificate validation vulnerability has been reported to affect QuMagie. If exploited, the vulnerability could allow local network users to compromise the security of the system via unspecified vectors.\n\nWe have already fixed the vulnerability in the following version:\nQuMagie 2.3.1 and later",
"id": "GHSA-78c9-5p24-9jcg",
"modified": "2024-09-16T14:37:25Z",
"published": "2024-09-06T18:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38642"
},
{
"type": "WEB",
"url": "https://www.qnap.com/en/security-advisory/qsa-24-34"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:P/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:L/SA:L/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-78FQ-W796-Q537
Vulnerability from github – Published: 2022-05-17 03:38 – Updated: 2022-07-06 20:25The PKIX trust engines in Shibboleth Identity Provider before 2.4.4 and OpenSAML Java (OpenSAML-J) before 2.6.5 trust candidate X.509 credentials when no trusted names are available for the entityID, which allows remote attackers to impersonate an entity via a certificate issued by a shibmd:KeyAuthority trust anchor.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.6.4"
},
"package": {
"ecosystem": "Maven",
"name": "org.opensaml:opensaml"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.6.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.4.3"
},
"package": {
"ecosystem": "Maven",
"name": "edu.internet2.middleware:shibboleth-identityprovider"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.4.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2015-1796"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2022-07-06T20:25:31Z",
"nvd_published_at": "2015-07-08T15:59:00Z",
"severity": "MODERATE"
},
"details": "The PKIX trust engines in Shibboleth Identity Provider before 2.4.4 and OpenSAML Java (OpenSAML-J) before 2.6.5 trust candidate X.509 credentials when no trusted names are available for the entityID, which allows remote attackers to impersonate an entity via a certificate issued by a shibmd:KeyAuthority trust anchor.",
"id": "GHSA-78fq-w796-q537",
"modified": "2022-07-06T20:25:31Z",
"published": "2022-05-17T03:38:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-1796"
},
{
"type": "WEB",
"url": "https://shibboleth.net/community/advisories/secadv_20150225.txt"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2015-1176.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2015-1177.html"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Improper Certificate Validation in Shibboleth Identity Provider and OpenSAML"
}
GHSA-78MQ-XCR3-XM33
Vulnerability from github – Published: 2026-06-25 22:15 – Updated: 2026-07-22 12:32SSH servers which use CertChecker as a public key callback without setting IsUserAuthority or IsHostAuthority could be caused to panic by a client presenting a certificate. CertChecker now returns an error instead of panicking when these callbacks are nil.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "golang.org/x/crypto"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.52.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-39835"
],
"database_specific": {
"cwe_ids": [
"CWE-295",
"CWE-476"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-25T22:15:17Z",
"nvd_published_at": "2026-05-22T04:16:24Z",
"severity": "MODERATE"
},
"details": "SSH servers which use CertChecker as a public key callback without setting IsUserAuthority or IsHostAuthority could be caused to panic by a client presenting a certificate. CertChecker now returns an error instead of panicking when these callbacks are nil.",
"id": "GHSA-78mq-xcr3-xm33",
"modified": "2026-07-22T12:32:01Z",
"published": "2026-06-25T22:15:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39835"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26546"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:40262"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:40945"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:40969"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:40972"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:40974"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:41019"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:41031"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:41036"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:41066"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:42146"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:42796"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-39835"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2480680"
},
{
"type": "PACKAGE",
"url": "https://cs.opensource.google/go/x/crypto"
},
{
"type": "WEB",
"url": "https://go.dev/cl/781660"
},
{
"type": "WEB",
"url": "https://go.dev/issue/79563"
},
{
"type": "WEB",
"url": "https://groups.google.com/g/golang-announce/c/a082jnz-LvI"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2026-5015"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-39835.json"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26547"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36199"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36207"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36319"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36625"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36648"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36651"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36796"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36797"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:37072"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:37123"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:37268"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:37271"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:37272"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:37286"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:37296"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:37387"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:37410"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:38504"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:40118"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "golang.org/x/crypto is vulnerable to invoking server panic during CheckHostKey/Authenticate flow"
}
GHSA-78PP-WPM2-456Q
Vulnerability from github – Published: 2022-08-17 00:00 – Updated: 2022-08-19 00:00When using Ingest Actions to configure a destination that resides on Amazon Simple Storage Service (S3) in Splunk Web, TLS certificate validation is not correctly performed and tested for the destination. The vulnerability only affects connections between Splunk Enterprise and an Ingest Actions Destination through Splunk Web and only applies to environments that have configured TLS certificate validation. It does not apply to Destinations configured directly in the outputs.conf configuration file. The vulnerability affects Splunk Enterprise version 9.0.0 and does not affect versions below 9.0.0, including the 8.1.x and 8.2.x versions.
{
"affected": [],
"aliases": [
"CVE-2022-37437"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-08-16T21:15:00Z",
"severity": "CRITICAL"
},
"details": "When using Ingest Actions to configure a destination that resides on Amazon Simple Storage Service (S3) in Splunk Web, TLS certificate validation is not correctly performed and tested for the destination. The vulnerability only affects connections between Splunk Enterprise and an Ingest Actions Destination through Splunk Web and only applies to environments that have configured TLS certificate validation. It does not apply to Destinations configured directly in the outputs.conf configuration file. The vulnerability affects Splunk Enterprise version 9.0.0 and does not affect versions below 9.0.0, including the 8.1.x and 8.2.x versions.",
"id": "GHSA-78pp-wpm2-456q",
"modified": "2022-08-19T00:00:21Z",
"published": "2022-08-17T00:00:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-37437"
},
{
"type": "WEB",
"url": "https://www.splunk.com/en_us/product-security/announcements/svd-2022-0801.html"
}
],
"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"
}
]
}
GHSA-78VP-42PH-7F4V
Vulnerability from github – Published: 2026-02-03 03:30 – Updated: 2026-02-19 18:31The DDNS update function in ADM fails to properly validate the hostname of the DDNS server's TLS/SSL certificate. Although the connection uses HTTPS, an improper validated TLS/SSL certificates allows a remote attacker can intercept the communication to perform a Man-in-the-Middle (MitM) attack, which may obtain the sensitive information of DDNS updating process, including the user's account email, MD5 hashed password, and device serial number.This issue affects ADM: from 4.1.0 through 4.3.3.ROF1, from 5.0.0 through 5.1.1.RCI1.
{
"affected": [],
"aliases": [
"CVE-2026-24932"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-03T03:15:53Z",
"severity": "HIGH"
},
"details": "The DDNS update function in ADM fails to properly validate the hostname of the DDNS server\u0027s TLS/SSL certificate. Although the connection uses HTTPS, an improper validated TLS/SSL certificates allows a remote attacker can intercept the communication to perform a Man-in-the-Middle (MitM) attack, which may obtain the sensitive information of DDNS updating process, including the user\u0027s account email, MD5 hashed password, and device serial number.This issue affects ADM: from 4.1.0 through 4.3.3.ROF1, from 5.0.0 through 5.1.1.RCI1.",
"id": "GHSA-78vp-42ph-7f4v",
"modified": "2026-02-19T18:31:43Z",
"published": "2026-02-03T03:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24932"
},
{
"type": "WEB",
"url": "https://www.asustor.com/security/security_advisory_detail?id=50"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/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-7943-82JG-WMW5
Vulnerability from github – Published: 2022-07-12 22:05 – Updated: 2022-07-21 15:54Impact
All versions of Argo CD starting with v0.4.0 are vulnerable to an improper certificate validation bug which could cause Argo CD to trust a malicious (or otherwise untrustworthy) OIDC provider.
(Note: external OIDC provider support was added in v0.11.0. Before that version, the notes below apply only to the bundled Dex instance.)
You are impacted if 1) have SSO enabled and 2) insecure mode is not enabled on the API server. In this case, certificate verification is skipped when connecting to your OIDC provider for the following tasks: verifying auth tokens on API requests and handling SSO login flows. If you are using the bundled Dex instance but have not set the --dex-server flag on the API server to an HTTPS address, then certificate verification is not being skipped (because TLS is not enabled by default for the bundled Dex instance).
Argo CD sends requests to the configured OIDC provider (either the bundled Dex instance or an external provider) to 1) retrieve the OpenID configuration, 2) to retrieve the OIDC provider's key set (at the location determined by the OIDC provider's configured jwks_uri), and 3) (during an SSO login) to exchange an authorization code for a token.
(Note: Starting with v2.3.0, certificate verification is not skipped when handling an SSO login flow if 1) you are not using the bundled Dex OIDC provider and 2) you have set oidc.config.rootCA in the argocd-cm ConfigMap. Certificate verification is still skipped when verifying tokens on API calls.)
Skipping certificate verification when communicating with the OIDC provider opens Argo CD to a variety of risks. For example, if an attacker can successfully intercept, decrypt, and respond to requests bound for the configured OIDC provider (a machine-in-the-middle attack), they could theoretically issue a "valid" admin token. Verifying the OIDC provider's certificate provides an extra layer of protection against such an attack.
Patches
A patch for this vulnerability has been released in the following Argo CD versions:
- v2.4.5
- v2.3.6
- v2.2.11
Note:
To preserve backwards compatibility, this patch adds a oidc.tls.insecure.skip.verify option to the argocd-cm ConfigMap. The default is "false". Before resorting to setting this, you should try to get certificate verification to work. If you are using the bundled Dex instance, user your Argo CD API server's TLS configuration since the API server acts as a reverse proxy to Dex. If you are using an external OIDC provider, set the rootCA config.
If these fail, be sure you are aware of the risks before setting oidc.tls.insecure.skip.verify: "true".
Workarounds
There is no complete workaround besides upgrading.
Partial mitigation when using an external OIDC provider
If you are using an external OIDC provider (not the bundled Dex instance), then you can mitigate the issue by setting the oidc.config.rootCA field in the argocd-cm ConfigMap. If your OIDC provider's certificate is self-signed or otherwise invalid, you must set the rootCA to a certificate that enables verification. If the OIDC provider's certificate passes without an additional root CA, then you can set oidc.config.rootCA to a bogus non-empty string such as "force cert verification". The API server will log a warning, but otherwise things should work fine.
Example:
metadata:
name: argocd-cm
data:
oidc.config: |
...
rootCA: |
force cert verification
This mitigation only forces certificate validation when the API server handles login flows. It does not force certificate verification when verifying tokens on API calls. To fully resolve the vulnerability, you must upgrade.
References
Credits
@jannfis and @crenshaw-dev discovered the vulnerability when reviewing notes from ADA Logics' security audit of the Argo project sponsored by CNCF and facilitated by OSTIF. Thanks to Adam Korczynski and David Korczynski for their work on the audit.
For more information
- Open an issue in the Argo CD issue tracker or discussions
- Join us on Slack in channel #argo-cd
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/argoproj/argo-cd"
},
"ranges": [
{
"events": [
{
"introduced": "0.4.0"
},
{
"fixed": "2.2.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/argoproj/argo-cd"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/argoproj/argo-cd"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.0"
},
{
"fixed": "2.4.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-31105"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2022-07-12T22:05:11Z",
"nvd_published_at": "2022-07-12T22:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\n\nAll versions of Argo CD starting with v0.4.0 are vulnerable to an improper certificate validation bug which could cause Argo CD to trust a malicious (or otherwise untrustworthy) OIDC provider.\n\n(Note: external OIDC provider support was added in v0.11.0. Before that version, the notes below apply only to the bundled Dex instance.)\n\nYou are impacted if 1) have SSO enabled and 2) insecure mode is _not_ enabled on the API server. In this case, certificate verification is skipped when connecting to your OIDC provider for the following tasks: verifying auth tokens on API requests and handling SSO login flows. If you are using the bundled Dex instance but have _not_ set the `--dex-server` flag on the API server to an HTTPS address, then certificate verification is not being skipped (because [TLS is not enabled by default for the bundled Dex instance](https://github.com/argoproj/argo-cd/issues/9424)).\n\nArgo CD sends requests to the configured OIDC provider (either the bundled Dex instance or an external provider) to 1) retrieve the [OpenID configuration](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig), 2) to retrieve the OIDC provider\u0027s key set (at the location determined by the [OIDC provider\u0027s configured `jwks_uri`](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata)), and 3) (during an SSO login) to exchange an authorization code for a token.\n\n(Note: Starting with v2.3.0, certificate verification is _not_ skipped when handling an SSO login flow if 1) you are not using the bundled Dex OIDC provider and 2) you have set `oidc.config.rootCA` in the `argocd-cm` ConfigMap. Certificate verification is still skipped when verifying tokens on API calls.)\n\nSkipping certificate verification when communicating with the OIDC provider opens Argo CD to a variety of risks. For example, if an attacker can successfully intercept, decrypt, and respond to requests bound for the configured OIDC provider (a machine-in-the-middle attack), they could theoretically issue a \"valid\" admin token. Verifying the OIDC provider\u0027s certificate provides an extra layer of protection against such an attack.\n\n### Patches\n\nA patch for this vulnerability has been released in the following Argo CD versions:\n\n* v2.4.5\n* v2.3.6\n* v2.2.11\n\n**Note:**\n\nTo preserve backwards compatibility, this patch adds a `oidc.tls.insecure.skip.verify` option to the `argocd-cm` ConfigMap. The default is `\"false\"`. Before resorting to setting this, you should try to get certificate verification to work. If you are using the bundled Dex instance, user your Argo CD API server\u0027s [TLS configuration](https://argo-cd.readthedocs.io/en/stable/operator-manual/tls/) since the API server acts as a reverse proxy to Dex. If you are using an external OIDC provider, [set the `rootCA` config](https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/#configuring-a-custom-root-ca-certificate-for-communicating-with-the-oidc-provider).\n\nIf these fail, be sure you are aware of the risks before setting `oidc.tls.insecure.skip.verify: \"true\"`.\n\n### Workarounds\n\nThere is no complete workaround besides upgrading.\n\n#### Partial mitigation when using an external OIDC provider\n\nIf you are using an external OIDC provider (not the bundled Dex instance), then you can mitigate the issue by setting the `oidc.config.rootCA` field in the `argocd-cm` ConfigMap. If your OIDC provider\u0027s certificate is self-signed or otherwise invalid, you must set the rootCA to a certificate that enables verification. If the OIDC provider\u0027s certificate passes _without_ an additional root CA, then you can set `oidc.config.rootCA` to a bogus non-empty string such as `\"force cert verification\"`. The API server will log a warning, but otherwise things should work fine.\n\nExample:\n\n```yaml\nmetadata:\n name: argocd-cm\ndata:\n oidc.config: |\n ...\n rootCA: |\n force cert verification\n```\n\nThis mitigation _only_ forces certificate validation when the API server handles login flows. It does not force certificate verification when verifying tokens on API calls. To fully resolve the vulnerability, you must upgrade.\n\n### References\n\n* [Argo CD SSO configuration documentation](https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/#sso)\n\n### Credits\n\n@jannfis and @crenshaw-dev discovered the vulnerability when reviewing notes from ADA Logics\u0027 security audit of the Argo project sponsored by CNCF and facilitated by OSTIF. Thanks to Adam Korczynski and David Korczynski for their work on the audit.\n\n### For more information\n\n* Open an issue in [the Argo CD issue tracker](https://github.com/argoproj/argo-cd/issues) or [discussions](https://github.com/argoproj/argo-cd/discussions)\n* Join us on [Slack](https://argoproj.github.io/community/join-slack) in channel #argo-cd\n",
"id": "GHSA-7943-82jg-wmw5",
"modified": "2022-07-21T15:54:19Z",
"published": "2022-07-12T22:05:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/argoproj/argo-cd/security/advisories/GHSA-7943-82jg-wmw5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31105"
},
{
"type": "PACKAGE",
"url": "https://github.com/argoproj/argo-cd"
},
{
"type": "WEB",
"url": "https://github.com/argoproj/argo-cd/releases/tag/v2.3.6"
},
{
"type": "WEB",
"url": "https://github.com/argoproj/argo-cd/releases/tag/v2.4.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Argo CD certificate verification is skipped for connections to OIDC providers"
}
GHSA-796P-J2GH-9M2Q
Vulnerability from github – Published: 2026-01-26 18:55 – Updated: 2026-01-29 03:22Impact
This vulnerability involves a critical gap in the cryptographic verification process within the dcap-qvl.
The library fetches QE Identity collateral (including qe_identity, qe_identity_signature, and qe_identity_issuer_chain) from the PCCS. However, it skips to verify the QE Identity signature against its certificate chain and does not enforce policy constraints on the QE Report.
Consequences
An attacker can forge the QE Identity data to whitelist a malicious or non-Intel Quoting Enclave. This allows the attacker to forge the QE and sign untrusted quotes that the verifier will accept as valid. Effectively, this bypasses the entire remote attestation security model, as the verifier can no longer trust the entity responsible for signing the quotes.
Who is impacted
All deployments utilizing the dcap-qvl library for SGX or TDX quote verification are affected.
Patches
The vulnerability has been patched in dcap-qvl version 0.3.9. The fix implements the missing cryptographic verification for the QE Identity signature and enforces the required checks for MRSIGNER, ISVPRODID, and ISVSVN against the QE Report.
Users of the @phala/dcap-qvl-node and @phala/dcap-qvl-web packages should switch to the pure JavaScript implementation, @phala/dcap-qvl.
Workarounds
There are no known workarounds for this vulnerability. Users must upgrade to the patched version to ensure that QE Identity collateral is properly verified.
Credit
This bug was reported by Rahul Saxena saxenism@bluethroatlabs.com.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "dcap-qvl"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.3.0"
},
"package": {
"ecosystem": "npm",
"name": "@phala/dcap-qvl"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@phala/dcap-qvl-web"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@phala/dcap-qvl-node"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "dcap-qvl"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-22696"
],
"database_specific": {
"cwe_ids": [
"CWE-295",
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-26T18:55:13Z",
"nvd_published_at": "2026-01-26T22:15:55Z",
"severity": "CRITICAL"
},
"details": "## Impact\nThis vulnerability involves a critical gap in the cryptographic verification process within the dcap-qvl.\n\nThe library fetches QE Identity collateral (including qe_identity, qe_identity_signature, and qe_identity_issuer_chain) from the PCCS. However, it skips to verify the QE Identity signature against its certificate chain and does not enforce policy constraints on the QE Report.\n\n## Consequences\nAn attacker can forge the QE Identity data to whitelist a malicious or non-Intel Quoting Enclave. This allows the attacker to forge the QE and sign untrusted quotes that the verifier will accept as valid. Effectively, this bypasses the entire remote attestation security model, as the verifier can no longer trust the entity responsible for signing the quotes.\n\n## Who is impacted\nAll deployments utilizing the dcap-qvl library for SGX or TDX quote verification are affected.\n\n## Patches\nThe vulnerability has been patched in dcap-qvl version 0.3.9. The fix implements the missing cryptographic verification for the QE Identity signature and enforces the required checks for MRSIGNER, ISVPRODID, and ISVSVN against the QE Report.\n\nUsers of the `@phala/dcap-qvl-node` and `@phala/dcap-qvl-web` packages should switch to the pure JavaScript implementation, `@phala/dcap-qvl`.\n\n## Workarounds\nThere are no known workarounds for this vulnerability. Users must upgrade to the patched version to ensure that QE Identity collateral is properly verified.\n\n## Credit\nThis bug was reported by Rahul Saxena \u003csaxenism@bluethroatlabs.com\u003e.",
"id": "GHSA-796p-j2gh-9m2q",
"modified": "2026-01-29T03:22:29Z",
"published": "2026-01-26T18:55:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Phala-Network/dcap-qvl/security/advisories/GHSA-796p-j2gh-9m2q"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22696"
},
{
"type": "PACKAGE",
"url": "https://github.com/Phala-Network/dcap-qvl"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "dcap-qvl has Missing Verification for QE Identity"
}
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.