Common Weakness Enumeration
CWE-295
AllowedImproper Certificate Validation
Abstraction: Base · Status: Draft
The product does not validate, or incorrectly validates, a certificate.
1907 vulnerabilities reference this CWE, most recent first.
CVE-2022-33681 (GCVE-0-2022-33681)
Vulnerability from cvelistv5 – Published: 2022-09-23 09:25 – Updated: 2025-05-22 20:37
VLAI
EPSS
VEX
Title
Improper Hostname Verification in Java Client and Proxy can expose authentication data via MITM
Summary
Delayed TLS hostname verification in the Pulsar Java Client and the Pulsar Proxy make each client vulnerable to a man in the middle attack. Connections from the Pulsar Java Client to the Pulsar Broker/Proxy and connections from the Pulsar Proxy to the Pulsar Broker are vulnerable. Authentication data is sent before verifying the server’s TLS certificate matches the hostname, which means authentication data could be exposed to an attacker. An attacker can only take advantage of this vulnerability by taking control of a machine 'between' the client and the server. The attacker must then actively manipulate traffic to perform the attack by providing the client with a cryptographically valid certificate for an unrelated host. Because the client sends authentication data before performing hostname verification, an attacker could gain access to the client’s authentication data. The client eventually closes the connection when it verifies the hostname and identifies the targeted hostname does not match a hostname on the certificate. Because the client eventually closes the connection, the value of the intercepted authentication data depends on the authentication method used by the client. Token based authentication and username/password authentication methods are vulnerable because the authentication data can be used to impersonate the client in a separate session. This issue affects Apache Pulsar Java Client versions 2.7.0 to 2.7.4; 2.8.0 to 2.8.3; 2.9.0 to 2.9.2; 2.10.0; 2.6.4 and earlier.
Severity
5.9 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator (v2.0.3)
CWE
- CWE-295 - Improper Certificate Validation
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/fpo6x10trvn20hlk0… | x_refsource_MISC |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Pulsar |
Affected:
2.10.0
Affected: 2.7 , ≤ 2.7.4 (custom) Affected: 2.8 , ≤ 2.8.3 (custom) Affected: 2.9 , ≤ 2.9.2 (custom) Affected: 2.6 and earlier , ≤ 2.6.4 (custom) |
Credits
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-03T08:09:22.286Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_refsource_MISC",
"x_transferred"
],
"url": "https://lists.apache.org/thread/fpo6x10trvn20hlk0dmnr5vlz5v4kl3d"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 5.9,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"version": "3.1"
}
},
{
"other": {
"content": {
"id": "CVE-2022-33681",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-05-22T20:36:59.341814Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2025-05-22T20:37:29.107Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "Apache Pulsar",
"vendor": "Apache Software Foundation",
"versions": [
{
"status": "affected",
"version": "2.10.0"
},
{
"lessThanOrEqual": "2.7.4",
"status": "affected",
"version": "2.7",
"versionType": "custom"
},
{
"lessThanOrEqual": "2.8.3",
"status": "affected",
"version": "2.8",
"versionType": "custom"
},
{
"lessThanOrEqual": "2.9.2",
"status": "affected",
"version": "2.9",
"versionType": "custom"
},
{
"lessThanOrEqual": "2.6.4",
"status": "affected",
"version": "2.6 and earlier",
"versionType": "custom"
}
]
}
],
"credits": [
{
"lang": "en",
"value": "This issue was discovered by Michael Marshall of DataStax."
}
],
"descriptions": [
{
"lang": "en",
"value": "Delayed TLS hostname verification in the Pulsar Java Client and the Pulsar Proxy make each client vulnerable to a man in the middle attack. Connections from the Pulsar Java Client to the Pulsar Broker/Proxy and connections from the Pulsar Proxy to the Pulsar Broker are vulnerable. Authentication data is sent before verifying the server\u2019s TLS certificate matches the hostname, which means authentication data could be exposed to an attacker. An attacker can only take advantage of this vulnerability by taking control of a machine \u0027between\u0027 the client and the server. The attacker must then actively manipulate traffic to perform the attack by providing the client with a cryptographically valid certificate for an unrelated host. Because the client sends authentication data before performing hostname verification, an attacker could gain access to the client\u2019s authentication data. The client eventually closes the connection when it verifies the hostname and identifies the targeted hostname does not match a hostname on the certificate. Because the client eventually closes the connection, the value of the intercepted authentication data depends on the authentication method used by the client. Token based authentication and username/password authentication methods are vulnerable because the authentication data can be used to impersonate the client in a separate session. This issue affects Apache Pulsar Java Client versions 2.7.0 to 2.7.4; 2.8.0 to 2.8.3; 2.9.0 to 2.9.2; 2.10.0; 2.6.4 and earlier."
}
],
"metrics": [
{
"other": {
"content": {
"other": "high"
},
"type": "unknown"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-295",
"description": "CWE-295 Improper Certificate Validation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2022-09-23T09:25:13.000Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"x_refsource_MISC"
],
"url": "https://lists.apache.org/thread/fpo6x10trvn20hlk0dmnr5vlz5v4kl3d"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Improper Hostname Verification in Java Client and Proxy can expose authentication data via MITM",
"workarounds": [
{
"lang": "en",
"value": "Any users running affected versions of the Java Client should rotate vulnerable authentication data, including tokens and passwords.\n\n2.7 Pulsar Java Client users should upgrade to 2.7.5, and rotate vulnerable authentication data, including tokens and passwords.\n2.8 Pulsar Java Client users should upgrade to 2.8.4, and rotate vulnerable authentication data, including tokens and passwords.\n2.9 Pulsar Java Client users should upgrade to 2.9.3, and rotate vulnerable authentication data, including tokens and passwords.\n2.10 Pulsar Java Client users should upgrade to 2.10.1, and rotate vulnerable authentication data, including tokens and passwords.\nAny users running the Pulsar Java Client for 2.6.4 and earlier should upgrade to one of the above patched versions, and rotate vulnerable authentication data, including tokens and passwords."
}
],
"x_generator": {
"engine": "Vulnogram 0.0.9"
},
"x_legacyV4Record": {
"CVE_data_meta": {
"ASSIGNER": "security@apache.org",
"ID": "CVE-2022-33681",
"STATE": "PUBLIC",
"TITLE": "Improper Hostname Verification in Java Client and Proxy can expose authentication data via MITM"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "Apache Pulsar",
"version": {
"version_data": [
{
"version_affected": "\u003c=",
"version_name": "2.7",
"version_value": "2.7.4"
},
{
"version_affected": "\u003c=",
"version_name": "2.8",
"version_value": "2.8.3"
},
{
"version_affected": "\u003c=",
"version_name": "2.9",
"version_value": "2.9.2"
},
{
"version_affected": "=",
"version_name": "2.10",
"version_value": "2.10.0"
},
{
"version_affected": "\u003c=",
"version_name": "2.6 and earlier",
"version_value": "2.6.4"
}
]
}
}
]
},
"vendor_name": "Apache Software Foundation"
}
]
}
},
"credit": [
{
"lang": "eng",
"value": "This issue was discovered by Michael Marshall of DataStax."
}
],
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "Delayed TLS hostname verification in the Pulsar Java Client and the Pulsar Proxy make each client vulnerable to a man in the middle attack. Connections from the Pulsar Java Client to the Pulsar Broker/Proxy and connections from the Pulsar Proxy to the Pulsar Broker are vulnerable. Authentication data is sent before verifying the server\u2019s TLS certificate matches the hostname, which means authentication data could be exposed to an attacker. An attacker can only take advantage of this vulnerability by taking control of a machine \u0027between\u0027 the client and the server. The attacker must then actively manipulate traffic to perform the attack by providing the client with a cryptographically valid certificate for an unrelated host. Because the client sends authentication data before performing hostname verification, an attacker could gain access to the client\u2019s authentication data. The client eventually closes the connection when it verifies the hostname and identifies the targeted hostname does not match a hostname on the certificate. Because the client eventually closes the connection, the value of the intercepted authentication data depends on the authentication method used by the client. Token based authentication and username/password authentication methods are vulnerable because the authentication data can be used to impersonate the client in a separate session. This issue affects Apache Pulsar Java Client versions 2.7.0 to 2.7.4; 2.8.0 to 2.8.3; 2.9.0 to 2.9.2; 2.10.0; 2.6.4 and earlier."
}
]
},
"generator": {
"engine": "Vulnogram 0.0.9"
},
"impact": [
{
"other": "high"
}
],
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "CWE-295 Improper Certificate Validation"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://lists.apache.org/thread/fpo6x10trvn20hlk0dmnr5vlz5v4kl3d",
"refsource": "MISC",
"url": "https://lists.apache.org/thread/fpo6x10trvn20hlk0dmnr5vlz5v4kl3d"
}
]
},
"source": {
"discovery": "UNKNOWN"
},
"work_around": [
{
"lang": "en",
"value": "Any users running affected versions of the Java Client should rotate vulnerable authentication data, including tokens and passwords.\n\n2.7 Pulsar Java Client users should upgrade to 2.7.5, and rotate vulnerable authentication data, including tokens and passwords.\n2.8 Pulsar Java Client users should upgrade to 2.8.4, and rotate vulnerable authentication data, including tokens and passwords.\n2.9 Pulsar Java Client users should upgrade to 2.9.3, and rotate vulnerable authentication data, including tokens and passwords.\n2.10 Pulsar Java Client users should upgrade to 2.10.1, and rotate vulnerable authentication data, including tokens and passwords.\nAny users running the Pulsar Java Client for 2.6.4 and earlier should upgrade to one of the above patched versions, and rotate vulnerable authentication data, including tokens and passwords."
}
]
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2022-33681",
"datePublished": "2022-09-23T09:25:13.000Z",
"dateReserved": "2022-06-15T00:00:00.000Z",
"dateUpdated": "2025-05-22T20:37:29.107Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2022-32748 (GCVE-0-2022-32748)
Vulnerability from cvelistv5 – Published: 2023-01-30 00:00 – Updated: 2025-02-05 20:07
VLAI
EPSS
VEX
Summary
A CWE-295: Improper Certificate Validation vulnerability exists that could cause the CAE software to give wrong data to end users when using CAE to configure devices. Additionally, credentials could leak which would enable an attacker the ability to log into the configuration tool and compromise other devices in the network. Affected Products: EcoStruxure™ Cybersecurity Admin Expert (CAE) (Versions prior to 2.2)
Severity
7.9 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator (v2.0.3)
CWE
- CWE-295 - Improper Certificate Validation
Assigner
References
1 reference
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Schneider Electric | EcoStruxure™ Cybersecurity Admin Expert (CAE) |
Affected:
All , < 2.2
(custom)
|
Date Public
2022-06-14 00:00
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-03T07:46:45.261Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://download.schneider-electric.com/files?p_enDocType=Security+and+Safety+Notice\u0026p_File_Name=SEVD-2022-165-08_Cybersecurity_Admin_Expert_Security_Notification.pdf"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2022-32748",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-02-05T19:52:27.920514Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2025-02-05T20:07:23.903Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "EcoStruxure\u2122 Cybersecurity Admin Expert (CAE)",
"vendor": "Schneider Electric",
"versions": [
{
"lessThan": "2.2",
"status": "affected",
"version": "All",
"versionType": "custom"
}
]
}
],
"datePublic": "2022-06-14T00:00:00.000Z",
"descriptions": [
{
"lang": "en",
"value": "A CWE-295: Improper Certificate Validation vulnerability exists that could cause the CAE software to give wrong data to end users when using CAE to configure devices. Additionally, credentials could leak which would enable an attacker the ability to log into the configuration tool and compromise other devices in the network. Affected Products: EcoStruxure\u2122 Cybersecurity Admin Expert (CAE) (Versions prior to 2.2)"
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "ADJACENT_NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 7.9,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "REQUIRED",
"vectorString": "CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-295",
"description": "CWE-295 Improper Certificate Validation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2023-01-30T00:00:00.000Z",
"orgId": "076d1eb6-cfab-4401-b34d-6dfc2a413bdb",
"shortName": "schneider"
},
"references": [
{
"url": "https://download.schneider-electric.com/files?p_enDocType=Security+and+Safety+Notice\u0026p_File_Name=SEVD-2022-165-08_Cybersecurity_Admin_Expert_Security_Notification.pdf"
}
],
"source": {
"discovery": "UNKNOWN"
},
"x_generator": {
"engine": "Vulnogram 0.0.9"
}
}
},
"cveMetadata": {
"assignerOrgId": "076d1eb6-cfab-4401-b34d-6dfc2a413bdb",
"assignerShortName": "schneider",
"cveId": "CVE-2022-32748",
"datePublished": "2023-01-30T00:00:00.000Z",
"dateReserved": "2022-06-09T00:00:00.000Z",
"dateUpdated": "2025-02-05T20:07:23.903Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2022-32531 (GCVE-0-2022-32531)
Vulnerability from cvelistv5 – Published: 2022-12-15 10:17 – Updated: 2025-04-17 18:20
VLAI
EPSS
VEX
Title
Apache BookKeeper: Java Client Uses Connection to Host that Failed Hostname Verification
Summary
The Apache Bookkeeper Java Client (before 4.14.6 and also 4.15.0) does not close the connection to the bookkeeper server when TLS hostname verification fails. This leaves
the bookkeeper client vulnerable to a man in the middle attack.
The problem affects BookKeeper client prior to versions 4.14.6 and 4.15.1.
Severity
5.9 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator (v2.0.3)
CWE
- CWE-295 - Improper Certificate Validation
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/xyk2lfc7lzof8mksm… | vendor-advisory |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache BookKeeper |
Affected:
0 , ≤ 4.14.5
(maven)
Affected: 4.15.0 |
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-03T07:46:44.696Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"vendor-advisory",
"x_transferred"
],
"url": "https://lists.apache.org/thread/xyk2lfc7lzof8mksmwyympbqxts1b5s9"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 5.9,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"version": "3.1"
}
},
{
"other": {
"content": {
"id": "CVE-2022-32531",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-04-17T18:20:02.707431Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2025-04-17T18:20:47.178Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Apache BookKeeper",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThanOrEqual": "4.14.5",
"status": "affected",
"version": "0",
"versionType": "maven"
},
{
"status": "affected",
"version": "4.15.0"
}
]
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eThe Apache Bookkeeper Java Client (before 4.14.6 and also 4.15.0) does not close the connection to the\u003c/span\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e bookkeeper server when TLS hostname verification fails. This leaves\u003c/span\u003e\u003cbr\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003ethe bookkeeper client vulnerable to a man in the middle attack.\u003cbr\u003e\u003c/span\u003e\u003cbr\u003eThe problem affects BookKeeper client prior to versions 4.14.6 and 4.15.1."
}
],
"value": "The Apache Bookkeeper Java Client (before 4.14.6 and also 4.15.0) does not close the connection to the bookkeeper server when TLS hostname verification fails. This leaves\nthe bookkeeper client vulnerable to a man in the middle attack.\n\nThe problem affects BookKeeper client prior to versions 4.14.6 and 4.15.1."
}
],
"metrics": [
{
"other": {
"content": {
"text": "Moderate"
},
"type": "Textual description of severity"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-295",
"description": "CWE-295 Improper Certificate Validation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2022-12-15T10:17:19.660Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/xyk2lfc7lzof8mksmwyympbqxts1b5s9"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "Upgrade to 4.14.6 or to 4.15.1\u003cbr\u003e"
}
],
"value": "Upgrade to 4.14.6 or to 4.15.1\n"
}
],
"source": {
"advisory": "https://github.com/apache/bookkeeper/pull/3310",
"discovery": "UNKNOWN"
},
"title": "Apache BookKeeper: Java Client Uses Connection to Host that Failed Hostname Verification",
"x_generator": {
"engine": "Vulnogram 0.1.0-dev"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2022-32531",
"datePublished": "2022-12-15T10:17:19.660Z",
"dateReserved": "2022-06-07T08:44:04.580Z",
"dateUpdated": "2025-04-17T18:20:47.178Z",
"requesterUserId": "01d7ebfd-4418-401d-b8e4-f5ae3da29160",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2022-32210 (GCVE-0-2022-32210)
Vulnerability from cvelistv5 – Published: 2022-07-14 14:51 – Updated: 2024-08-03 07:32
VLAI
EPSS
VEX
Summary
`Undici.ProxyAgent` never verifies the remote server's certificate, and always exposes all request & response data to the proxy. This unexpectedly means that proxies can MitM all HTTPS traffic, and if the proxy's URL is HTTP then it also means that nominally HTTPS requests are actually sent via plain-text HTTP between Undici and the proxy server.
Severity
No CVSS data available.
CWE
- CWE-295 - Improper Certificate Validation (CWE-295)
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://hackerone.com/reports/1583680 | x_refsource_MISC |
| https://github.com/nodejs/undici/security/advisor… | x_refsource_MISC |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| n/a | https://github.com/nodejs/undici |
Affected:
Fixed in version >= v5.5.1. Vulnerable between v4.8.2 and v5.5.0
|
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-03T07:32:56.020Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_refsource_MISC",
"x_transferred"
],
"url": "https://hackerone.com/reports/1583680"
},
{
"tags": [
"x_refsource_MISC",
"x_transferred"
],
"url": "https://github.com/nodejs/undici/security/advisories/GHSA-pgw7-wx7w-2w33"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"product": "https://github.com/nodejs/undici",
"vendor": "n/a",
"versions": [
{
"status": "affected",
"version": "Fixed in version \u003e= v5.5.1. Vulnerable between v4.8.2 and v5.5.0"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "`Undici.ProxyAgent` never verifies the remote server\u0027s certificate, and always exposes all request \u0026 response data to the proxy. This unexpectedly means that proxies can MitM all HTTPS traffic, and if the proxy\u0027s URL is HTTP then it also means that nominally HTTPS requests are actually sent via plain-text HTTP between Undici and the proxy server."
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-295",
"description": "Improper Certificate Validation (CWE-295)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2022-07-14T14:51:40.000Z",
"orgId": "36234546-b8fa-4601-9d6f-f4e334aa8ea1",
"shortName": "hackerone"
},
"references": [
{
"tags": [
"x_refsource_MISC"
],
"url": "https://hackerone.com/reports/1583680"
},
{
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/nodejs/undici/security/advisories/GHSA-pgw7-wx7w-2w33"
}
],
"x_legacyV4Record": {
"CVE_data_meta": {
"ASSIGNER": "support@hackerone.com",
"ID": "CVE-2022-32210",
"STATE": "PUBLIC"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "https://github.com/nodejs/undici",
"version": {
"version_data": [
{
"version_value": "Fixed in version \u003e= v5.5.1. Vulnerable between v4.8.2 and v5.5.0"
}
]
}
}
]
},
"vendor_name": "n/a"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "`Undici.ProxyAgent` never verifies the remote server\u0027s certificate, and always exposes all request \u0026 response data to the proxy. This unexpectedly means that proxies can MitM all HTTPS traffic, and if the proxy\u0027s URL is HTTP then it also means that nominally HTTPS requests are actually sent via plain-text HTTP between Undici and the proxy server."
}
]
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "Improper Certificate Validation (CWE-295)"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://hackerone.com/reports/1583680",
"refsource": "MISC",
"url": "https://hackerone.com/reports/1583680"
},
{
"name": "https://github.com/nodejs/undici/security/advisories/GHSA-pgw7-wx7w-2w33",
"refsource": "MISC",
"url": "https://github.com/nodejs/undici/security/advisories/GHSA-pgw7-wx7w-2w33"
}
]
}
}
}
},
"cveMetadata": {
"assignerOrgId": "36234546-b8fa-4601-9d6f-f4e334aa8ea1",
"assignerShortName": "hackerone",
"cveId": "CVE-2022-32210",
"datePublished": "2022-07-14T14:51:40.000Z",
"dateReserved": "2022-06-01T00:00:00.000Z",
"dateUpdated": "2024-08-03T07:32:56.020Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2022-32156 (GCVE-0-2022-32156)
Vulnerability from cvelistv5 – Published: 2022-06-14 00:00 – Updated: 2024-08-03 07:32
VLAI
EPSS
VEX
Title
Splunk Enterprise and Universal Forwarder CLI connections lacked TLS cert validation
Summary
In Splunk Enterprise and Universal Forwarder versions before 9.0, the Splunk command-line interface (CLI) did not validate TLS certificates while connecting to a remote Splunk platform instance by default. After updating to version 9.0, see Configure TLS host name validation for the Splunk CLI https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation#Configure_TLS_host_name_validation_for_the_Splunk_CLI to enable the remediation. The vulnerability does not affect the Splunk Cloud Platform. At the time of publishing, we have no evidence of exploitation of this vulnerability by external parties.
The issue requires conditions beyond the control of a potential bad actor such as a machine-in-the-middle attack. Hence, Splunk rates the complexity of the attack as High.
Severity
7.4 (High)
8.1 (High)
CWE
- CWE-295 - Improper Certificate Validation
Assigner
References
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| Splunk | Splunk Enterprise |
Affected:
0 , < 9.0.0
(custom)
|
|
| Splunk | Universal Forwarder |
Affected:
0 , < 9.0.0
(custom)
|
Date Public
2022-06-14 16:00
Credits
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-03T07:32:55.975Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_transferred"
],
"url": "https://www.splunk.com/en_us/product-security/announcements/svd-2022-0606.html"
},
{
"tags": [
"x_transferred"
],
"url": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/Updates"
},
{
"tags": [
"x_transferred"
],
"url": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation#Configure_TLS_host_name_validation_for_the_Splunk_CLI"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Splunk Enterprise",
"vendor": "Splunk",
"versions": [
{
"lessThan": "9.0.0",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unaffected",
"product": "Universal Forwarder",
"vendor": "Splunk",
"versions": [
{
"lessThan": "9.0.0",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"configurations": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eSplunk peer communications configured properly with valid certificates were not vulnerable. However, connections from misconfigured nodes without valid certificates did not fail by default.\u0026nbsp;\u003c/p\u003e\u003cp\u003eSplunk strongly recommends securing your Splunk environment with hardened TLS configurations. See \u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://docs.splunk.com/Documentation/Splunk/latest/Security/AboutsecuringyourSplunkconfigurationwithSSL\"\u003eSecuring the Splunk platform with TLS\u003c/a\u003e\u0026nbsp;for more information. However, the vulnerability assumes that you have configured your Splunk platform instances to use transport layer security (TLS) certificates for secure network connections. If you have not and are using the default certificates, the vulnerability is not applicable and is informational.\u003c/p\u003e"
}
],
"value": "Splunk peer communications configured properly with valid certificates were not vulnerable. However, connections from misconfigured nodes without valid certificates did not fail by default. \n\nSplunk strongly recommends securing your Splunk environment with hardened TLS configurations. See Securing the Splunk platform with TLS https://docs.splunk.com/Documentation/Splunk/latest/Security/AboutsecuringyourSplunkconfigurationwithSSL for more information. However, the vulnerability assumes that you have configured your Splunk platform instances to use transport layer security (TLS) certificates for secure network connections. If you have not and are using the default certificates, the vulnerability is not applicable and is informational."
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"user": "00000000-0000-4000-9000-000000000000",
"value": "Chris Green at Splunk"
}
],
"datePublic": "2022-06-14T16:00:00.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Splunk Enterprise and Universal Forwarder versions before 9.0, the Splunk command-line interface (CLI) did not validate TLS certificates while connecting to a remote Splunk platform instance by default. After updating to version 9.0, see \u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation#Configure_TLS_host_name_validation_for_the_Splunk_CLI\"\u003eConfigure TLS host name validation for the Splunk CLI\u003c/a\u003e\u0026nbsp;to enable the remediation.\u0026nbsp;\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eThe vulnerability does not affect the Splunk Cloud Platform. At the time of publishing, we have no evidence of exploitation of this vulnerability by external parties.\u003c/span\u003e\u003c/p\u003e\u003cp\u003eThe issue requires conditions beyond the control of a potential bad actor such as a machine-in-the-middle attack. Hence, Splunk rates the complexity of the attack as High.\u0026nbsp;\u003c/p\u003e"
}
],
"value": "In Splunk Enterprise and Universal Forwarder versions before 9.0, the Splunk command-line interface (CLI) did not validate TLS certificates while connecting to a remote Splunk platform instance by default. After updating to version 9.0, see Configure TLS host name validation for the Splunk CLI https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation#Configure_TLS_host_name_validation_for_the_Splunk_CLI to enable the remediation. The vulnerability does not affect the Splunk Cloud Platform. At the time of publishing, we have no evidence of exploitation of this vulnerability by external parties.\n\nThe issue requires conditions beyond the control of a potential bad actor such as a machine-in-the-middle attack. Hence, Splunk rates the complexity of the attack as High."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 7.4,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "Universal Forwarders"
}
]
},
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 8.1,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "Splunk Enterprise"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-295",
"description": "CWE-295 Improper Certificate Validation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2022-11-11T18:56:14.525Z",
"orgId": "42b59230-ec95-491e-8425-5a5befa1a469",
"shortName": "Splunk"
},
"references": [
{
"url": "https://www.splunk.com/en_us/product-security/announcements/svd-2022-0606.html"
},
{
"url": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/Updates"
},
{
"url": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation#Configure_TLS_host_name_validation_for_the_Splunk_CLI"
}
],
"source": {
"advisory": "SVD-2022-0606",
"discovery": "INTERNAL"
},
"title": "Splunk Enterprise and Universal Forwarder CLI connections lacked TLS cert validation"
}
},
"cveMetadata": {
"assignerOrgId": "42b59230-ec95-491e-8425-5a5befa1a469",
"assignerShortName": "Splunk",
"cveId": "CVE-2022-32156",
"datePublished": "2022-06-14T00:00:00.000Z",
"dateReserved": "2022-05-31T00:00:00.000Z",
"dateUpdated": "2024-08-03T07:32:55.975Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2022-32152 (GCVE-0-2022-32152)
Vulnerability from cvelistv5 – Published: 2022-06-15 16:46 – Updated: 2024-09-17 02:02
VLAI
EPSS
VEX
Title
Splunk Enterprise lacked TLS cert validation for Splunk-to-Splunk communication by default
Summary
Splunk Enterprise peers in Splunk Enterprise versions before 9.0 and Splunk Cloud Platform versions before 8.2.2203 did not validate the TLS certificates during Splunk-to-Splunk communications by default. Splunk peer communications configured properly with valid certificates were not vulnerable. However, an attacker with administrator credentials could add a peer without a valid certificate and connections from misconfigured nodes without valid certificates did not fail by default. For Splunk Enterprise, update to Splunk Enterprise version 9.0 and Configure TLS host name validation for Splunk-to-Splunk communications (https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation) to enable the remediation.
Severity
8.1 (High)
CWE
- CWE-295 - Improper Certificate Validation
Assigner
References
7 references
| URL | Tags |
|---|---|
| https://docs.splunk.com/Documentation/Splunk/9.0.… | x_refsource_CONFIRM |
| https://docs.splunk.com/Documentation/Splunk/9.0.… | x_refsource_CONFIRM |
| https://www.splunk.com/en_us/product-security/ann… | x_refsource_CONFIRM |
| https://research.splunk.com/application/splunk_di… | x_refsource_CONFIRM |
| https://research.splunk.com/application/splunk_di… | x_refsource_CONFIRM |
| https://research.splunk.com/application/splunk_pr… | x_refsource_CONFIRM |
| https://research.splunk.com/network/splunk_identi… | x_refsource_CONFIRM |
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| Splunk | Splunk Enterprise |
Affected:
9.0 , < 9.0
(custom)
|
|
| Splunk | Splunk Cloud Platform |
Affected:
8.2 , < 8.2.2203
(custom)
|
Date Public
2022-06-14 00:00
Credits
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-03T07:32:56.011Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation"
},
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/Updates"
},
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://www.splunk.com/en_us/product-security/announcements/svd-2022-0602.html"
},
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://research.splunk.com/application/splunk_digital_certificates_infrastructure_version/"
},
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://research.splunk.com/application/splunk_digital_certificates_lack_of_encryption/"
},
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://research.splunk.com/application/splunk_protocol_impersonation_weak_encryption_selfsigned/"
},
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://research.splunk.com/network/splunk_identified_ssl_tls_certificates/"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"product": "Splunk Enterprise",
"vendor": "Splunk",
"versions": [
{
"lessThan": "9.0",
"status": "affected",
"version": "9.0",
"versionType": "custom"
}
]
},
{
"product": "Splunk Cloud Platform",
"vendor": "Splunk",
"versions": [
{
"lessThan": "8.2.2203",
"status": "affected",
"version": "8.2",
"versionType": "custom"
}
]
}
],
"credits": [
{
"lang": "en",
"value": "Chris Green at Splunk"
}
],
"datePublic": "2022-06-14T00:00:00.000Z",
"descriptions": [
{
"lang": "en",
"value": "Splunk Enterprise peers in Splunk Enterprise versions before 9.0 and Splunk Cloud Platform versions before 8.2.2203 did not validate the TLS certificates during Splunk-to-Splunk communications by default. Splunk peer communications configured properly with valid certificates were not vulnerable. However, an attacker with administrator credentials could add a peer without a valid certificate and connections from misconfigured nodes without valid certificates did not fail by default. For Splunk Enterprise, update to Splunk Enterprise version 9.0 and Configure TLS host name validation for Splunk-to-Splunk communications (https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation) to enable the remediation."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 8.1,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-295",
"description": "CWE-295 Improper Certificate Validation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2022-06-15T16:46:29.000Z",
"orgId": "42b59230-ec95-491e-8425-5a5befa1a469",
"shortName": "Splunk"
},
"references": [
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation"
},
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/Updates"
},
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://www.splunk.com/en_us/product-security/announcements/svd-2022-0602.html"
},
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://research.splunk.com/application/splunk_digital_certificates_infrastructure_version/"
},
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://research.splunk.com/application/splunk_digital_certificates_lack_of_encryption/"
},
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://research.splunk.com/application/splunk_protocol_impersonation_weak_encryption_selfsigned/"
},
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://research.splunk.com/network/splunk_identified_ssl_tls_certificates/"
}
],
"source": {
"advisory": "SVD-2022-0602",
"discovery": "INTERNAL"
},
"title": "Splunk Enterprise lacked TLS cert validation for Splunk-to-Splunk communication by default",
"x_legacyV4Record": {
"CVE_data_meta": {
"ASSIGNER": "prodsec@splunk.com",
"DATE_PUBLIC": "2022-06-14T11:55:00.000Z",
"ID": "CVE-2022-32152",
"STATE": "PUBLIC",
"TITLE": "Splunk Enterprise lacked TLS cert validation for Splunk-to-Splunk communication by default"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "Splunk Enterprise",
"version": {
"version_data": [
{
"version_affected": "\u003c",
"version_name": "9.0",
"version_value": "9.0"
}
]
}
},
{
"product_name": "Splunk Cloud Platform",
"version": {
"version_data": [
{
"version_affected": "\u003c",
"version_name": "8.2",
"version_value": "8.2.2203"
}
]
}
}
]
},
"vendor_name": "Splunk"
}
]
}
},
"credit": [
{
"lang": "eng",
"value": "Chris Green at Splunk"
}
],
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "Splunk Enterprise peers in Splunk Enterprise versions before 9.0 and Splunk Cloud Platform versions before 8.2.2203 did not validate the TLS certificates during Splunk-to-Splunk communications by default. Splunk peer communications configured properly with valid certificates were not vulnerable. However, an attacker with administrator credentials could add a peer without a valid certificate and connections from misconfigured nodes without valid certificates did not fail by default. For Splunk Enterprise, update to Splunk Enterprise version 9.0 and Configure TLS host name validation for Splunk-to-Splunk communications (https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation) to enable the remediation."
}
]
},
"impact": {
"cvss": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 8.1,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
}
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "CWE-295 Improper Certificate Validation"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation",
"refsource": "CONFIRM",
"url": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation"
},
{
"name": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/Updates",
"refsource": "CONFIRM",
"url": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/Updates"
},
{
"name": "https://www.splunk.com/en_us/product-security/announcements/svd-2022-0602.html",
"refsource": "CONFIRM",
"url": "https://www.splunk.com/en_us/product-security/announcements/svd-2022-0602.html"
},
{
"name": "https://research.splunk.com/application/splunk_digital_certificates_infrastructure_version/",
"refsource": "CONFIRM",
"url": "https://research.splunk.com/application/splunk_digital_certificates_infrastructure_version/"
},
{
"name": "https://research.splunk.com/application/splunk_digital_certificates_lack_of_encryption/",
"refsource": "CONFIRM",
"url": "https://research.splunk.com/application/splunk_digital_certificates_lack_of_encryption/"
},
{
"name": "https://research.splunk.com/application/splunk_protocol_impersonation_weak_encryption_selfsigned/",
"refsource": "CONFIRM",
"url": "https://research.splunk.com/application/splunk_protocol_impersonation_weak_encryption_selfsigned/"
},
{
"name": "https://research.splunk.com/network/splunk_identified_ssl_tls_certificates/",
"refsource": "CONFIRM",
"url": "https://research.splunk.com/network/splunk_identified_ssl_tls_certificates/"
}
]
},
"source": {
"advisory": "SVD-2022-0602",
"discovery": "INTERNAL"
}
}
}
},
"cveMetadata": {
"assignerOrgId": "42b59230-ec95-491e-8425-5a5befa1a469",
"assignerShortName": "Splunk",
"cveId": "CVE-2022-32152",
"datePublished": "2022-06-15T16:46:29.133Z",
"dateReserved": "2022-05-31T00:00:00.000Z",
"dateUpdated": "2024-09-17T02:02:11.058Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2022-32151 (GCVE-0-2022-32151)
Vulnerability from cvelistv5 – Published: 2022-06-15 16:46 – Updated: 2024-09-16 17:59
VLAI
EPSS
VEX
Title
Splunk Enterprise disabled TLS validation using the CA certificate stores in Python 3 libraries by default
Summary
The httplib and urllib Python libraries that Splunk shipped with Splunk Enterprise did not validate certificates using the certificate authority (CA) certificate stores by default in Splunk Enterprise versions before 9.0 and Splunk Cloud Platform versions before 8.2.2203. Python 3 client libraries now verify server certificates by default and use the appropriate CA certificate stores for each library. Apps and add-ons that include their own HTTP libraries are not affected. For Splunk Enterprise, update to Splunk Enterprise version 9.0 and Configure TLS host name validation for Splunk-to-Splunk communications (https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation) to enable the remediation.
Severity
7.4 (High)
CWE
- CWE-295 - Improper Certificate Validation
Assigner
References
4 references
| URL | Tags |
|---|---|
| https://www.splunk.com/en_us/product-security/ann… | x_refsource_CONFIRM |
| https://docs.splunk.com/Documentation/Splunk/9.0.… | x_refsource_CONFIRM |
| https://docs.splunk.com/Documentation/Splunk/9.0.… | x_refsource_CONFIRM |
| https://research.splunk.com/application/splunk_pr… | x_refsource_CONFIRM |
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| Splunk, Inc | Splunk Enterprise |
Affected:
9.0 , < 9.0
(custom)
|
|
| Splunk, Inc | Splunk Cloud Platform |
Affected:
8.2 , < 8.2.2203
(custom)
|
Date Public
2022-06-14 00:00
Credits
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-03T07:32:56.016Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://www.splunk.com/en_us/product-security/announcements/svd-2022-0601.html"
},
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation"
},
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/Updates"
},
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://research.splunk.com/application/splunk_protocol_impersonation_weak_encryption_simplerequest/"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"product": "Splunk Enterprise",
"vendor": "Splunk, Inc",
"versions": [
{
"lessThan": "9.0",
"status": "affected",
"version": "9.0",
"versionType": "custom"
}
]
},
{
"product": "Splunk Cloud Platform",
"vendor": "Splunk, Inc",
"versions": [
{
"lessThan": "8.2.2203",
"status": "affected",
"version": "8.2",
"versionType": "custom"
}
]
}
],
"credits": [
{
"lang": "en",
"value": "Chris Green at Splunk"
}
],
"datePublic": "2022-06-14T00:00:00.000Z",
"descriptions": [
{
"lang": "en",
"value": "The httplib and urllib Python libraries that Splunk shipped with Splunk Enterprise did not validate certificates using the certificate authority (CA) certificate stores by default in Splunk Enterprise versions before 9.0 and Splunk Cloud Platform versions before 8.2.2203. Python 3 client libraries now verify server certificates by default and use the appropriate CA certificate stores for each library. Apps and add-ons that include their own HTTP libraries are not affected. For Splunk Enterprise, update to Splunk Enterprise version 9.0 and Configure TLS host name validation for Splunk-to-Splunk communications (https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation) to enable the remediation."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 7.4,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-295",
"description": "CWE-295 Improper Certificate Validation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2022-06-15T16:46:07.000Z",
"orgId": "42b59230-ec95-491e-8425-5a5befa1a469",
"shortName": "Splunk"
},
"references": [
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://www.splunk.com/en_us/product-security/announcements/svd-2022-0601.html"
},
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation"
},
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/Updates"
},
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://research.splunk.com/application/splunk_protocol_impersonation_weak_encryption_simplerequest/"
}
],
"source": {
"advisory": "SVD-2022-0601",
"discovery": "INTERNAL"
},
"title": "Splunk Enterprise disabled TLS validation using the CA certificate stores in Python 3 libraries by default",
"x_legacyV4Record": {
"CVE_data_meta": {
"ASSIGNER": "prodsec@splunk.com",
"DATE_PUBLIC": "2022-06-14T11:55:00.000Z",
"ID": "CVE-2022-32151",
"STATE": "PUBLIC",
"TITLE": "Splunk Enterprise disabled TLS validation using the CA certificate stores in Python 3 libraries by default"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "Splunk Enterprise",
"version": {
"version_data": [
{
"version_affected": "\u003c",
"version_name": "9.0",
"version_value": "9.0"
}
]
}
},
{
"product_name": "Splunk Cloud Platform",
"version": {
"version_data": [
{
"version_affected": "\u003c",
"version_name": "8.2",
"version_value": "8.2.2203"
}
]
}
}
]
},
"vendor_name": "Splunk, Inc"
}
]
}
},
"credit": [
{
"lang": "eng",
"value": "Chris Green at Splunk"
}
],
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "The httplib and urllib Python libraries that Splunk shipped with Splunk Enterprise did not validate certificates using the certificate authority (CA) certificate stores by default in Splunk Enterprise versions before 9.0 and Splunk Cloud Platform versions before 8.2.2203. Python 3 client libraries now verify server certificates by default and use the appropriate CA certificate stores for each library. Apps and add-ons that include their own HTTP libraries are not affected. For Splunk Enterprise, update to Splunk Enterprise version 9.0 and Configure TLS host name validation for Splunk-to-Splunk communications (https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation) to enable the remediation."
}
]
},
"impact": {
"cvss": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 7.4,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"version": "3.1"
}
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "CWE-295 Improper Certificate Validation"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://www.splunk.com/en_us/product-security/announcements/svd-2022-0601.html",
"refsource": "CONFIRM",
"url": "https://www.splunk.com/en_us/product-security/announcements/svd-2022-0601.html"
},
{
"name": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation",
"refsource": "CONFIRM",
"url": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation"
},
{
"name": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/Updates",
"refsource": "CONFIRM",
"url": "https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/Updates"
},
{
"name": "https://research.splunk.com/application/splunk_protocol_impersonation_weak_encryption_simplerequest/",
"refsource": "CONFIRM",
"url": "https://research.splunk.com/application/splunk_protocol_impersonation_weak_encryption_simplerequest/"
}
]
},
"source": {
"advisory": "SVD-2022-0601",
"discovery": "INTERNAL"
}
}
}
},
"cveMetadata": {
"assignerOrgId": "42b59230-ec95-491e-8425-5a5befa1a469",
"assignerShortName": "Splunk",
"cveId": "CVE-2022-32151",
"datePublished": "2022-06-15T16:46:07.016Z",
"dateReserved": "2022-05-31T00:00:00.000Z",
"dateUpdated": "2024-09-16T17:59:24.447Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2022-31183 (GCVE-0-2022-31183)
Vulnerability from cvelistv5 – Published: 2022-08-01 19:50 – Updated: 2025-04-22 17:45
VLAI
EPSS
VEX
Title
mTLS client verification is skipped in fs2 on Node.js
Summary
fs2 is a compositional, streaming I/O library for Scala. When establishing a server-mode `TLSSocket` using `fs2-io` on Node.js, the parameter `requestCert = true` is ignored, peer certificate verification is skipped, and the connection proceeds. The vulnerability is limited to: 1. `fs2-io` running on Node.js. The JVM TLS implementation is completely independent. 2. `TLSSocket`s in server-mode. Client-mode `TLSSocket`s are implemented via a different API. 3. mTLS as enabled via `requestCert = true` in `TLSParameters`. The default setting is `false` for server-mode `TLSSocket`s. It was introduced with the initial Node.js implementation of fs2-io in 3.1.0. A patch is released in v3.2.11. The requestCert = true parameter is respected and the peer certificate is verified. If verification fails, a SSLException is raised. If using an unpatched version on Node.js, do not use a server-mode TLSSocket with requestCert = true to establish a mTLS connection.
Severity
9.1 (Critical)
SSVC
Exploitation: poc
Automatable: yes
Technical Impact: total
CISA Coordinator (v2.0.3)
CWE
- CWE-295 - Improper Certificate Validation
Assigner
References
3 references
| URL | Tags |
|---|---|
| https://github.com/typelevel/fs2/security/advisor… | x_refsource_CONFIRM |
| https://github.com/nodejs/node/issues/43994 | x_refsource_MISC |
| https://github.com/typelevel/fs2/commit/659824395… | x_refsource_MISC |
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-03T07:11:39.653Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://github.com/typelevel/fs2/security/advisories/GHSA-2cpx-6pqp-wf35"
},
{
"tags": [
"x_refsource_MISC",
"x_transferred"
],
"url": "https://github.com/nodejs/node/issues/43994"
},
{
"tags": [
"x_refsource_MISC",
"x_transferred"
],
"url": "https://github.com/typelevel/fs2/commit/659824395826a314e0a4331535dbf1ef8bef8207"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2022-31183",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-04-22T15:37:11.291758Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2025-04-22T17:45:55.210Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "fs2",
"vendor": "typelevel",
"versions": [
{
"status": "affected",
"version": "\u003e= 3.1.0, \u003c 3.2.11"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "fs2 is a compositional, streaming I/O library for Scala. When establishing a server-mode `TLSSocket` using `fs2-io` on Node.js, the parameter `requestCert = true` is ignored, peer certificate verification is skipped, and the connection proceeds. The vulnerability is limited to: 1. `fs2-io` running on Node.js. The JVM TLS implementation is completely independent. 2. `TLSSocket`s in server-mode. Client-mode `TLSSocket`s are implemented via a different API. 3. mTLS as enabled via `requestCert = true` in `TLSParameters`. The default setting is `false` for server-mode `TLSSocket`s. It was introduced with the initial Node.js implementation of fs2-io in 3.1.0. A patch is released in v3.2.11. The requestCert = true parameter is respected and the peer certificate is verified. If verification fails, a SSLException is raised. If using an unpatched version on Node.js, do not use a server-mode TLSSocket with requestCert = true to establish a mTLS connection."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 9.1,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-295",
"description": "CWE-295: Improper Certificate Validation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2022-08-01T19:50:11.000Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/typelevel/fs2/security/advisories/GHSA-2cpx-6pqp-wf35"
},
{
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/nodejs/node/issues/43994"
},
{
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/typelevel/fs2/commit/659824395826a314e0a4331535dbf1ef8bef8207"
}
],
"source": {
"advisory": "GHSA-2cpx-6pqp-wf35",
"discovery": "UNKNOWN"
},
"title": "mTLS client verification is skipped in fs2 on Node.js",
"x_legacyV4Record": {
"CVE_data_meta": {
"ASSIGNER": "security-advisories@github.com",
"ID": "CVE-2022-31183",
"STATE": "PUBLIC",
"TITLE": "mTLS client verification is skipped in fs2 on Node.js"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "fs2",
"version": {
"version_data": [
{
"version_value": "\u003e= 3.1.0, \u003c 3.2.11"
}
]
}
}
]
},
"vendor_name": "typelevel"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "fs2 is a compositional, streaming I/O library for Scala. When establishing a server-mode `TLSSocket` using `fs2-io` on Node.js, the parameter `requestCert = true` is ignored, peer certificate verification is skipped, and the connection proceeds. The vulnerability is limited to: 1. `fs2-io` running on Node.js. The JVM TLS implementation is completely independent. 2. `TLSSocket`s in server-mode. Client-mode `TLSSocket`s are implemented via a different API. 3. mTLS as enabled via `requestCert = true` in `TLSParameters`. The default setting is `false` for server-mode `TLSSocket`s. It was introduced with the initial Node.js implementation of fs2-io in 3.1.0. A patch is released in v3.2.11. The requestCert = true parameter is respected and the peer certificate is verified. If verification fails, a SSLException is raised. If using an unpatched version on Node.js, do not use a server-mode TLSSocket with requestCert = true to establish a mTLS connection."
}
]
},
"impact": {
"cvss": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 9.1,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"version": "3.1"
}
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "CWE-295: Improper Certificate Validation"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://github.com/typelevel/fs2/security/advisories/GHSA-2cpx-6pqp-wf35",
"refsource": "CONFIRM",
"url": "https://github.com/typelevel/fs2/security/advisories/GHSA-2cpx-6pqp-wf35"
},
{
"name": "https://github.com/nodejs/node/issues/43994",
"refsource": "MISC",
"url": "https://github.com/nodejs/node/issues/43994"
},
{
"name": "https://github.com/typelevel/fs2/commit/659824395826a314e0a4331535dbf1ef8bef8207",
"refsource": "MISC",
"url": "https://github.com/typelevel/fs2/commit/659824395826a314e0a4331535dbf1ef8bef8207"
}
]
},
"source": {
"advisory": "GHSA-2cpx-6pqp-wf35",
"discovery": "UNKNOWN"
}
}
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2022-31183",
"datePublished": "2022-08-01T19:50:11.000Z",
"dateReserved": "2022-05-18T00:00:00.000Z",
"dateUpdated": "2025-04-22T17:45:55.210Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2022-31105 (GCVE-0-2022-31105)
Vulnerability from cvelistv5 – Published: 2022-07-12 22:05 – Updated: 2025-04-23 18:02
VLAI
EPSS
VEX
Title
Argo CD's certificate verification is skipped for connections to OIDC providers
Summary
Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Argo CD starting with version 0.4.0 and prior to 2.2.11, 2.3.6, and 2.4.5 is vulnerable to an improper certificate validation bug which could cause Argo CD to trust a malicious (or otherwise untrustworthy) OpenID Connect (OIDC) provider. A patch for this vulnerability has been released in Argo CD versions 2.4.5, 2.3.6, and 2.2.11. There are no complete workarounds, but a partial workaround is available. Those who use an external OIDC provider (not the bundled Dex instance), can mitigate the issue by setting the `oidc.config.rootCA` field in the `argocd-cm` ConfigMap. 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.
Severity
8.3 (High)
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator (v2.0.3)
Assigner
References
3 references
| URL | Tags |
|---|---|
| https://github.com/argoproj/argo-cd/security/advi… | x_refsource_CONFIRM |
| https://github.com/argoproj/argo-cd/releases/tag/v2.3.6 | x_refsource_MISC |
| https://github.com/argoproj/argo-cd/releases/tag/v2.4.5 | x_refsource_MISC |
Impacted products
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-03T07:11:39.204Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://github.com/argoproj/argo-cd/security/advisories/GHSA-7943-82jg-wmw5"
},
{
"tags": [
"x_refsource_MISC",
"x_transferred"
],
"url": "https://github.com/argoproj/argo-cd/releases/tag/v2.3.6"
},
{
"tags": [
"x_refsource_MISC",
"x_transferred"
],
"url": "https://github.com/argoproj/argo-cd/releases/tag/v2.4.5"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2022-31105",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-04-23T15:51:34.574172Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2025-04-23T18:02:44.544Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "argo-cd",
"vendor": "argoproj",
"versions": [
{
"status": "affected",
"version": "\u003e= 0.4.0, \u003c 2.2.11"
},
{
"status": "affected",
"version": "\u003e= 2.3.0, \u003c 2.3.6"
},
{
"status": "affected",
"version": "\u003e= 2.4.0, \u003c 2.4.5"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Argo CD starting with version 0.4.0 and prior to 2.2.11, 2.3.6, and 2.4.5 is vulnerable to an improper certificate validation bug which could cause Argo CD to trust a malicious (or otherwise untrustworthy) OpenID Connect (OIDC) provider. A patch for this vulnerability has been released in Argo CD versions 2.4.5, 2.3.6, and 2.2.11. There are no complete workarounds, but a partial workaround is available. Those who use an external OIDC provider (not the bundled Dex instance), can mitigate the issue by setting the `oidc.config.rootCA` field in the `argocd-cm` ConfigMap. 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."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 8.3,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "REQUIRED",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-295",
"description": "CWE-295: Improper Certificate Validation",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-599",
"description": "CWE-599: Missing Validation of OpenSSL Certificate",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2022-07-12T22:05:11.000Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/argoproj/argo-cd/security/advisories/GHSA-7943-82jg-wmw5"
},
{
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/argoproj/argo-cd/releases/tag/v2.3.6"
},
{
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/argoproj/argo-cd/releases/tag/v2.4.5"
}
],
"source": {
"advisory": "GHSA-7943-82jg-wmw5",
"discovery": "UNKNOWN"
},
"title": "Argo CD\u0027s certificate verification is skipped for connections to OIDC providers",
"x_legacyV4Record": {
"CVE_data_meta": {
"ASSIGNER": "security-advisories@github.com",
"ID": "CVE-2022-31105",
"STATE": "PUBLIC",
"TITLE": "Argo CD\u0027s certificate verification is skipped for connections to OIDC providers"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "argo-cd",
"version": {
"version_data": [
{
"version_value": "\u003e= 0.4.0, \u003c 2.2.11"
},
{
"version_value": "\u003e= 2.3.0, \u003c 2.3.6"
},
{
"version_value": "\u003e= 2.4.0, \u003c 2.4.5"
}
]
}
}
]
},
"vendor_name": "argoproj"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Argo CD starting with version 0.4.0 and prior to 2.2.11, 2.3.6, and 2.4.5 is vulnerable to an improper certificate validation bug which could cause Argo CD to trust a malicious (or otherwise untrustworthy) OpenID Connect (OIDC) provider. A patch for this vulnerability has been released in Argo CD versions 2.4.5, 2.3.6, and 2.2.11. There are no complete workarounds, but a partial workaround is available. Those who use an external OIDC provider (not the bundled Dex instance), can mitigate the issue by setting the `oidc.config.rootCA` field in the `argocd-cm` ConfigMap. 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."
}
]
},
"impact": {
"cvss": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 8.3,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "REQUIRED",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H",
"version": "3.1"
}
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "CWE-295: Improper Certificate Validation"
}
]
},
{
"description": [
{
"lang": "eng",
"value": "CWE-599: Missing Validation of OpenSSL Certificate"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://github.com/argoproj/argo-cd/security/advisories/GHSA-7943-82jg-wmw5",
"refsource": "CONFIRM",
"url": "https://github.com/argoproj/argo-cd/security/advisories/GHSA-7943-82jg-wmw5"
},
{
"name": "https://github.com/argoproj/argo-cd/releases/tag/v2.3.6",
"refsource": "MISC",
"url": "https://github.com/argoproj/argo-cd/releases/tag/v2.3.6"
},
{
"name": "https://github.com/argoproj/argo-cd/releases/tag/v2.4.5",
"refsource": "MISC",
"url": "https://github.com/argoproj/argo-cd/releases/tag/v2.4.5"
}
]
},
"source": {
"advisory": "GHSA-7943-82jg-wmw5",
"discovery": "UNKNOWN"
}
}
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2022-31105",
"datePublished": "2022-07-12T22:05:11.000Z",
"dateReserved": "2022-05-18T00:00:00.000Z",
"dateUpdated": "2025-04-23T18:02:44.544Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2022-29222 (GCVE-0-2022-29222)
Vulnerability from cvelistv5 – Published: 2022-05-21 00:00 – Updated: 2025-04-23 18:23
VLAI
EPSS
VEX
Title
Improper Certificate Validation in Pion DTLS
Summary
Pion DTLS is a Go implementation of Datagram Transport Layer Security. Prior to version 2.1.5, a DTLS Client could provide a Certificate that it doesn't posses the private key for and Pion DTLS wouldn't reject it. This issue affects users that are using Client certificates only. The connection itself is still secure. The Certificate provided by clients can't be trusted when using a Pion DTLS server prior to version 2.1.5. Users should upgrade to version 2.1.5 to receive a patch. There are currently no known workarounds.
Severity
5.9 (Medium)
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator (v2.0.3)
CWE
- CWE-295 - Improper Certificate Validation
Assigner
References
3 references
| URL | Tags |
|---|---|
| https://github.com/pion/dtls/security/advisories/… | x_refsource_CONFIRM |
| https://github.com/pion/dtls/commit/d2f797183a9f0… | x_refsource_MISC |
| https://github.com/pion/dtls/releases/tag/v2.1.5 | x_refsource_MISC |
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-03T06:17:54.467Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://github.com/pion/dtls/security/advisories/GHSA-w45j-f832-hxvh"
},
{
"tags": [
"x_refsource_MISC",
"x_transferred"
],
"url": "https://github.com/pion/dtls/commit/d2f797183a9f044ce976e6df6f362662ca722412"
},
{
"tags": [
"x_refsource_MISC",
"x_transferred"
],
"url": "https://github.com/pion/dtls/releases/tag/v2.1.5"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2022-29222",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-04-23T14:06:54.695147Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2025-04-23T18:23:10.716Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "dtls",
"vendor": "pion",
"versions": [
{
"status": "affected",
"version": "\u003c 2.1.5"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Pion DTLS is a Go implementation of Datagram Transport Layer Security. Prior to version 2.1.5, a DTLS Client could provide a Certificate that it doesn\u0027t posses the private key for and Pion DTLS wouldn\u0027t reject it. This issue affects users that are using Client certificates only. The connection itself is still secure. The Certificate provided by clients can\u0027t be trusted when using a Pion DTLS server prior to version 2.1.5. Users should upgrade to version 2.1.5 to receive a patch. There are currently no known workarounds."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 5.9,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-295",
"description": "CWE-295: Improper Certificate Validation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2022-05-21T00:00:15.000Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/pion/dtls/security/advisories/GHSA-w45j-f832-hxvh"
},
{
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/pion/dtls/commit/d2f797183a9f044ce976e6df6f362662ca722412"
},
{
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/pion/dtls/releases/tag/v2.1.5"
}
],
"source": {
"advisory": "GHSA-w45j-f832-hxvh",
"discovery": "UNKNOWN"
},
"title": "Improper Certificate Validation in Pion DTLS",
"x_legacyV4Record": {
"CVE_data_meta": {
"ASSIGNER": "security-advisories@github.com",
"ID": "CVE-2022-29222",
"STATE": "PUBLIC",
"TITLE": "Improper Certificate Validation in Pion DTLS"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "dtls",
"version": {
"version_data": [
{
"version_value": "\u003c 2.1.5"
}
]
}
}
]
},
"vendor_name": "pion"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "Pion DTLS is a Go implementation of Datagram Transport Layer Security. Prior to version 2.1.5, a DTLS Client could provide a Certificate that it doesn\u0027t posses the private key for and Pion DTLS wouldn\u0027t reject it. This issue affects users that are using Client certificates only. The connection itself is still secure. The Certificate provided by clients can\u0027t be trusted when using a Pion DTLS server prior to version 2.1.5. Users should upgrade to version 2.1.5 to receive a patch. There are currently no known workarounds."
}
]
},
"impact": {
"cvss": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 5.9,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"version": "3.1"
}
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "CWE-295: Improper Certificate Validation"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://github.com/pion/dtls/security/advisories/GHSA-w45j-f832-hxvh",
"refsource": "CONFIRM",
"url": "https://github.com/pion/dtls/security/advisories/GHSA-w45j-f832-hxvh"
},
{
"name": "https://github.com/pion/dtls/commit/d2f797183a9f044ce976e6df6f362662ca722412",
"refsource": "MISC",
"url": "https://github.com/pion/dtls/commit/d2f797183a9f044ce976e6df6f362662ca722412"
},
{
"name": "https://github.com/pion/dtls/releases/tag/v2.1.5",
"refsource": "MISC",
"url": "https://github.com/pion/dtls/releases/tag/v2.1.5"
}
]
},
"source": {
"advisory": "GHSA-w45j-f832-hxvh",
"discovery": "UNKNOWN"
}
}
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2022-29222",
"datePublished": "2022-05-21T00:00:15.000Z",
"dateReserved": "2022-04-13T00:00:00.000Z",
"dateUpdated": "2025-04-23T18:23:10.716Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
Mitigation
Architecture and Design
Implementation
Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.
Mitigation
Implementation
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.