CWE-299
AllowedImproper Check for Certificate Revocation
Abstraction: Base · Status: Draft
The product does not check or incorrectly checks the revocation status of a certificate, which may cause it to use a certificate that has been compromised.
25 vulnerabilities reference this CWE, most recent first.
CVE-2023-23690 (GCVE-0-2023-23690)
Vulnerability from cvelistv5 – Published: 2023-01-19 11:25 – Updated: 2025-04-02 14:58- CWE-299 - Improper Check for Certificate Revocation
| URL | Tags |
|---|---|
| https://www.dell.com/support/kbdoc/en-us/00020752… | vendor-advisory |
| Vendor | Product | Version | |
|---|---|---|---|
| Dell | Cloud Mobility for Dell Storage |
Affected:
0 , < 1.3.3.X
(custom)
|
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-02T10:35:33.747Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"vendor-advisory",
"x_transferred"
],
"url": "https://www.dell.com/support/kbdoc/en-us/000207521/dsa-2023-019-dell-emc-cloud-mobility-security-update-for-certificate-revocation-vulnerability"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2023-23690",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-04-02T14:57:48.546482Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2025-04-02T14:58:04.777Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Cloud Mobility for Dell Storage",
"vendor": "Dell",
"versions": [
{
"lessThan": "1.3.3.X",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\n\n\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eCloud Mobility for Dell EMC Storage, versions 1.3.0.X and below contains an Improper Check for Certificate Revocation vulnerability. A threat actor does not need any specific privileges to potentially exploit this vulnerability. An attacker could perform a man-in-the-middle attack and eavesdrop on encrypted communications from Cloud Mobility to Cloud Storage devices. Exploitation could lead to the compromise of secret and sensitive information, cloud storage connection downtime, and the integrity of the connection to the Cloud devices.\u003c/span\u003e\n\n"
}
],
"value": "\nCloud Mobility for Dell EMC Storage, versions 1.3.0.X and below contains an Improper Check for Certificate Revocation vulnerability. A threat actor does not need any specific privileges to potentially exploit this vulnerability. An attacker could perform a man-in-the-middle attack and eavesdrop on encrypted communications from Cloud Mobility to Cloud Storage devices. Exploitation could lead to the compromise of secret and sensitive information, cloud storage connection downtime, and the integrity of the connection to the Cloud devices.\n\n"
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "LOW",
"baseScore": 7,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:L",
"version": "3.1"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-299",
"description": "CWE-299: Improper Check for Certificate Revocation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2023-01-19T11:26:26.002Z",
"orgId": "c550e75a-17ff-4988-97f0-544cde3820fe",
"shortName": "dell"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://www.dell.com/support/kbdoc/en-us/000207521/dsa-2023-019-dell-emc-cloud-mobility-security-update-for-certificate-revocation-vulnerability"
}
],
"source": {
"discovery": "UNKNOWN"
},
"x_generator": {
"engine": "Vulnogram 0.1.0-dev"
}
}
},
"cveMetadata": {
"assignerOrgId": "c550e75a-17ff-4988-97f0-544cde3820fe",
"assignerShortName": "dell",
"cveId": "CVE-2023-23690",
"datePublished": "2023-01-19T11:25:48.778Z",
"dateReserved": "2023-01-17T05:22:17.394Z",
"dateUpdated": "2025-04-02T14:58:04.777Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2020-16228 (GCVE-0-2020-16228)
Vulnerability from cvelistv5 – Published: 2020-09-11 12:58 – Updated: 2024-08-04 13:37- CWE-299 - Improper Check for Certificate Revocation
| URL | Tags |
|---|---|
| https://us-cert.cisa.gov/ics/advisories/icsma-20-254-01 | x_refsource_MISC |
| https://www.philips.com/productsecurity |
| Vendor | Product | Version | |
|---|---|---|---|
| Philips | Patient Information Center iX (PICiX) |
Affected:
C.02
Affected: C.03 |
|
| Philips | PerformanceBridge Focal Point |
Affected:
A.01
|
|
| Philips | IntelliVue patient monitors |
Affected:
MX100
Affected: MX400-MX550 Affected: MX750 Affected: MX850 |
|
| Philips | IntelliVue X3 |
Affected:
0 , ≤ N
(custom)
|
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-04T13:37:54.179Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_refsource_MISC",
"x_transferred"
],
"url": "https://us-cert.cisa.gov/ics/advisories/icsma-20-254-01"
},
{
"tags": [
"x_transferred"
],
"url": "https://www.philips.com/productsecurity"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Patient Information Center iX (PICiX)",
"vendor": "Philips",
"versions": [
{
"status": "affected",
"version": "C.02"
},
{
"status": "affected",
"version": "C.03"
}
]
},
{
"defaultStatus": "unaffected",
"product": "PerformanceBridge Focal Point",
"vendor": "Philips",
"versions": [
{
"status": "affected",
"version": "A.01"
}
]
},
{
"defaultStatus": "unaffected",
"product": "IntelliVue patient monitors",
"vendor": "Philips",
"versions": [
{
"status": "affected",
"version": "MX100"
},
{
"status": "affected",
"version": "MX400-MX550"
},
{
"status": "affected",
"version": "MX750"
},
{
"status": "affected",
"version": "MX850"
}
]
},
{
"defaultStatus": "unaffected",
"product": "IntelliVue X3",
"vendor": "Philips",
"versions": [
{
"lessThanOrEqual": "N",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"user": "00000000-0000-4000-9000-000000000000",
"value": "Julian Suleder, Nils Emmerich, Birk Kauer of ERNW Research GmbH, Dr. Oliver Matula of ERNW Enno, and Rey Netzwerke GmbH reported these vulnerabilities to the Federal Office for Information Security (BSI), Germany, in the context of the BSI project ManiMed (Manipulation of medical devices), which reported these to Philips."
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003e\nIn Patient Information Center iX (PICiX) Versions C.02 and C.03, \nPerformanceBridge Focal Point Version A.01, IntelliVue patient monitors \nMX100, MX400-MX550, MX750, MX850, and IntelliVue X3 Versions N and \nprior, the software does not check or incorrectly checks the revocation \nstatus of a certificate, which may cause it to use a compromised \ncertificate.\n\n\u003c/p\u003e"
}
],
"value": "In Patient Information Center iX (PICiX) Versions C.02 and C.03, \nPerformanceBridge Focal Point Version A.01, IntelliVue patient monitors \nMX100, MX400-MX550, MX750, MX850, and IntelliVue X3 Versions N and \nprior, the software does not check or incorrectly checks the revocation \nstatus of a certificate, which may cause it to use a compromised \ncertificate."
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-299",
"description": "CWE-299 Improper Check for Certificate Revocation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2023-12-12T20:52:52.755Z",
"orgId": "7d14cffa-0d7d-4270-9dc0-52cabd5a23a6",
"shortName": "icscert"
},
"references": [
{
"tags": [
"x_refsource_MISC"
],
"url": "https://us-cert.cisa.gov/ics/advisories/icsma-20-254-01"
},
{
"url": "https://www.philips.com/productsecurity"
}
],
"solutions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003ePhilips released the following versions to remediate reported vulnerabilities:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ePatient Information Center iX (PICiX) Version C.03\u003c/li\u003e\n\u003cli\u003ePerformanceBridge Focal Point\u003c/li\u003e\n\u003cli\u003eIntelliVue Patient Monitors Versions N.00 and N.01\u003c/li\u003e\n\u003cli\u003eIntelliVue Patient Monitors Version M.04: Contact a \u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://www.usa.philips.com/healthcare/solutions/customer-service-solutions\"\u003ePhilips service support team\u003c/a\u003e for an upgrade path\u003c/li\u003e\n\u003cli\u003eCertificate revocation within the system was implemented for PIC iX \nand Performance Bridge FocalPoint in 2023. The implementation of the \nIntelliVue Patient Monitors will be completed in Q3 of 2024.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cbr\u003e"
}
],
"value": "Philips released the following versions to remediate reported vulnerabilities:\n\n\n\n * Patient Information Center iX (PICiX) Version C.03\n\n * PerformanceBridge Focal Point\n\n * IntelliVue Patient Monitors Versions N.00 and N.01\n\n * IntelliVue Patient Monitors Version M.04: Contact a Philips service support team https://www.usa.philips.com/healthcare/solutions/customer-service-solutions for an upgrade path\n\n * Certificate revocation within the system was implemented for PIC iX \nand Performance Bridge FocalPoint in 2023. The implementation of the \nIntelliVue Patient Monitors will be completed in Q3 of 2024."
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Philips Patient Monitoring Devices Improper Check for Certificate Revocation",
"workarounds": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eAs a mitigation to these vulnerabilities, Philips recommends the following:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eThe Philips patient monitoring network is required to be physically \nor logically isolated from the hospital local area network (LAN). \nPhilips recommends using a firewall or routers that can implement access\n control lists restricting access in and out of the patient monitoring \nnetwork for only necessary ports and IP addresses. Refer to the Philips \nPatient Monitoring System Security for Clinical Networks guide for \nadditional information on \u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://incenter.medical.philips.com/\"\u003eInCenter\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eBy default, the simple certificate enrollment protocol (SCEP) \nservice is not running. When needed, the service is configured to run \nbased on the duration or the number of certificates to be assigned. One \ncertificate is default, but if a certificate is not issued, the service \nwill continue to run. Limit exposure by ensuring the SCEP service is not\n running unless it is actively being used to enroll new devices.\u003c/li\u003e\n\u003cli\u003eWhen enrolling new devices using SCEP, enter a unique challenge password of 8-12 unpredictable and randomized digits.\u003c/li\u003e\n\u003cli\u003eImplement physical security controls to prevent unauthorized login \nattempts on the PIC iX application. Servers should be kept in controlled\n locked data centers. Access to equipment at nurses\u2019 stations should be \ncontrolled and monitored.\u003c/li\u003e\n\u003cli\u003eOnly grant remote access to PIC iX servers on a must-have basis.\u003c/li\u003e\n\u003cli\u003eGrant login privileges to the bedside monitor and PIC iX application\n on a role-based, least-privilege basis, and only to trusted users.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eUsers with questions regarding their specific Philips Patient \nInformation Center (PIC iX) and/or IntelliVue patient monitor \ninstallations and new release eligibility should contact their local \u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://www.usa.philips.com/healthcare/solutions/customer-service-solutions\"\u003ePhilips service support team, or regional service support\u003c/a\u003e, or call 1-800-722-9377.\u003c/p\u003e\n\u003cp\u003ePlease see the \u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://www.philips.com/productsecurity\"\u003ePhilips product security website\u003c/a\u003e for the Philips advisory and the latest security information for Philips products.\u003c/p\u003e\n\n\u003cbr\u003e"
}
],
"value": "As a mitigation to these vulnerabilities, Philips recommends the following:\n\n\n\n * The Philips patient monitoring network is required to be physically \nor logically isolated from the hospital local area network (LAN). \nPhilips recommends using a firewall or routers that can implement access\n control lists restricting access in and out of the patient monitoring \nnetwork for only necessary ports and IP addresses. Refer to the Philips \nPatient Monitoring System Security for Clinical Networks guide for \nadditional information on InCenter https://incenter.medical.philips.com/ .\n\n * By default, the simple certificate enrollment protocol (SCEP) \nservice is not running. When needed, the service is configured to run \nbased on the duration or the number of certificates to be assigned. One \ncertificate is default, but if a certificate is not issued, the service \nwill continue to run. Limit exposure by ensuring the SCEP service is not\n running unless it is actively being used to enroll new devices.\n\n * When enrolling new devices using SCEP, enter a unique challenge password of 8-12 unpredictable and randomized digits.\n\n * Implement physical security controls to prevent unauthorized login \nattempts on the PIC iX application. Servers should be kept in controlled\n locked data centers. Access to equipment at nurses\u2019 stations should be \ncontrolled and monitored.\n\n * Only grant remote access to PIC iX servers on a must-have basis.\n\n * Grant login privileges to the bedside monitor and PIC iX application\n on a role-based, least-privilege basis, and only to trusted users.\n\n\n\n\nUsers with questions regarding their specific Philips Patient \nInformation Center (PIC iX) and/or IntelliVue patient monitor \ninstallations and new release eligibility should contact their local Philips service support team, or regional service support https://www.usa.philips.com/healthcare/solutions/customer-service-solutions , or call 1-800-722-9377.\n\n\nPlease see the Philips product security website https://www.philips.com/productsecurity for the Philips advisory and the latest security information for Philips products."
}
],
"x_generator": {
"engine": "Vulnogram 0.1.0-dev"
},
"x_legacyV4Record": {
"CVE_data_meta": {
"ASSIGNER": "ics-cert@hq.dhs.gov",
"ID": "CVE-2020-16228",
"STATE": "PUBLIC"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "Philips Patient Information Center iX (PICiX), PerformanceBridge Focal Point, IntelliVue patient monitors MX100, MX400-MX850, and MP2-MP90, IntelliVue X3 and X2.",
"version": {
"version_data": [
{
"version_value": "Patient Information Center iX (PICiX) Versions B.02, C.02, C.03, PerformanceBridge Focal Point Version A.01, IntelliVue patient monitors MX100, MX400-MX850, and MP2-MP90 Versions N and prior, IntelliVue X3 and X2 Versions N and prior."
}
]
}
}
]
},
"vendor_name": "n/a"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "Patient Information Center iX (PICiX) Versions B.02, C.02, C.03, PerformanceBridge Focal Point Version A.01, IntelliVue patient monitors MX100, MX400-MX850, and MP2-MP90 Versions N and prior, IntelliVue X3 and X2 Versions N and prior. The software does not check or incorrectly checks the revocation status of a certificate, which may cause it to use a compromised certificate."
}
]
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "IMPROPER CHECK FOR CERTIFICATE REVOCATION CWE-299"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://us-cert.cisa.gov/ics/advisories/icsma-20-254-01",
"refsource": "MISC",
"url": "https://us-cert.cisa.gov/ics/advisories/icsma-20-254-01"
}
]
}
}
}
},
"cveMetadata": {
"assignerOrgId": "7d14cffa-0d7d-4270-9dc0-52cabd5a23a6",
"assignerShortName": "icscert",
"cveId": "CVE-2020-16228",
"datePublished": "2020-09-11T12:58:13.000Z",
"dateReserved": "2020-07-31T00:00:00.000Z",
"dateUpdated": "2024-08-04T13:37:54.179Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2020-1675 (GCVE-0-2020-1675)
Vulnerability from cvelistv5 – Published: 2020-10-16 20:31 – Updated: 2024-09-16 22:01- CWE-299 - Improper Check for Certificate Revocation
| URL | Tags |
|---|---|
| https://kb.juniper.net/JSA11072 | x_refsource_CONFIRM |
| Vendor | Product | Version | |
|---|---|---|---|
| Juniper Networks | MIST Cloud UI |
Affected:
unspecified , < 09/02/2020
(custom)
|
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-04T06:46:30.238Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://kb.juniper.net/JSA11072"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"product": "MIST Cloud UI",
"vendor": "Juniper Networks",
"versions": [
{
"lessThan": "09/02/2020",
"status": "affected",
"version": "unspecified",
"versionType": "custom"
}
]
}
],
"datePublic": "2020-10-14T00:00:00.000Z",
"descriptions": [
{
"lang": "en",
"value": "When Security Assertion Markup Language (SAML) authentication is enabled, Juniper Networks Mist Cloud UI might incorrectly process invalid authentication certificates which could allow a malicious network-based user to access unauthorized data. This issue affects all Juniper Networks Mist Cloud UI versions prior to September 2 2020."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "LOW",
"baseScore": 8.3,
"baseSeverity": "HIGH",
"confidentialityImpact": "LOW",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-299",
"description": "CWE-299 Improper Check for Certificate Revocation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2020-10-16T20:31:32.000Z",
"orgId": "8cbe9d5a-a066-4c94-8978-4b15efeae968",
"shortName": "juniper"
},
"references": [
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://kb.juniper.net/JSA11072"
}
],
"solutions": [
{
"lang": "en",
"value": "Mist Cloud UI has been updated on September 2 2020 to resolve this specific issue."
}
],
"source": {
"advisory": "JSA11072",
"discovery": "INTERNAL"
},
"title": "Juniper Networks Mist Cloud UI: SAML authentication certificate vulnerability.",
"workarounds": [
{
"lang": "en",
"value": "No workarounds are required since the issue has been resolved in the Mist cloud UI."
}
],
"x_generator": {
"engine": "Vulnogram 0.0.9"
},
"x_legacyV4Record": {
"CVE_data_meta": {
"ASSIGNER": "sirt@juniper.net",
"DATE_PUBLIC": "2020-10-14T16:00:00.000Z",
"ID": "CVE-2020-1675",
"STATE": "PUBLIC",
"TITLE": "Juniper Networks Mist Cloud UI: SAML authentication certificate vulnerability."
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "MIST Cloud UI",
"version": {
"version_data": [
{
"version_affected": "\u003c",
"version_value": "09/02/2020"
}
]
}
}
]
},
"vendor_name": "Juniper Networks"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "When Security Assertion Markup Language (SAML) authentication is enabled, Juniper Networks Mist Cloud UI might incorrectly process invalid authentication certificates which could allow a malicious network-based user to access unauthorized data. This issue affects all Juniper Networks Mist Cloud UI versions prior to September 2 2020."
}
]
},
"generator": {
"engine": "Vulnogram 0.0.9"
},
"impact": {
"cvss": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "LOW",
"baseScore": 8.3,
"baseSeverity": "HIGH",
"confidentialityImpact": "LOW",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "CHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L",
"version": "3.1"
}
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "CWE-299 Improper Check for Certificate Revocation"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://kb.juniper.net/JSA11072",
"refsource": "CONFIRM",
"url": "https://kb.juniper.net/JSA11072"
}
]
},
"solution": [
{
"lang": "en",
"value": "Mist Cloud UI has been updated on September 2 2020 to resolve this specific issue."
}
],
"source": {
"advisory": "JSA11072",
"discovery": "INTERNAL"
},
"work_around": [
{
"lang": "en",
"value": "No workarounds are required since the issue has been resolved in the Mist cloud UI."
}
]
}
}
},
"cveMetadata": {
"assignerOrgId": "8cbe9d5a-a066-4c94-8978-4b15efeae968",
"assignerShortName": "juniper",
"cveId": "CVE-2020-1675",
"datePublished": "2020-10-16T20:31:32.283Z",
"dateReserved": "2019-11-04T00:00:00.000Z",
"dateUpdated": "2024-09-16T22:01:32.790Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
GHSA-45V3-38PC-874V
Vulnerability from github – Published: 2025-01-13 16:14 – Updated: 2025-01-14 21:05This issue was identified during Quarkslab's audit of the timestamp feature.
Summary
During the timestamp signature generation, the revocation status of the certificate(s) used to generate the timestamp signature was not verified.
Details
During timestamp signature generation, notation-go did not check the revocation status of the certificate chain used by the TSA. This oversight creates a vulnerability that could be exploited through a Man-in-The-Middle attack. An attacker could potentially use a compromised, intermediate, or revoked leaf certificate to generate a malicious countersignature, which would then be accepted and stored by notation.
Impact
This could lead to denial of service scenarios, particularly in CI/CD environments during signature verification processes because timestamp signature would fail due to the presence of a revoked certificate(s) potentially disrupting operations.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.3.0-rc.1"
},
"package": {
"ecosystem": "Go",
"name": "github.com/notaryproject/notation-go"
},
"ranges": [
{
"events": [
{
"introduced": "1.2.0-beta.1"
},
{
"fixed": "1.3.0-rc.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-56138"
],
"database_specific": {
"cwe_ids": [
"CWE-299"
],
"github_reviewed": true,
"github_reviewed_at": "2025-01-13T16:14:07Z",
"nvd_published_at": "2025-01-13T22:15:14Z",
"severity": "MODERATE"
},
"details": "This issue was identified during Quarkslab\u0027s audit of the timestamp feature.\n\n### Summary\nDuring the timestamp signature generation, the revocation status of the certificate(s) used to generate the timestamp signature was not verified.\n\n### Details\nDuring timestamp signature generation, notation-go did not check the revocation status of the certificate chain used by the TSA. This oversight creates a vulnerability that could be exploited through a Man-in-The-Middle attack. An attacker could potentially use a compromised, intermediate, or revoked leaf certificate to generate a malicious countersignature, which would then be accepted and stored by `notation`.\n\n### Impact\nThis could lead to denial of service scenarios, particularly in CI/CD environments during signature verification processes because timestamp signature would fail due to the presence of a revoked certificate(s) potentially disrupting operations.\n",
"id": "GHSA-45v3-38pc-874v",
"modified": "2025-01-14T21:05:54Z",
"published": "2025-01-13T16:14:07Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/notaryproject/notation-go/security/advisories/GHSA-45v3-38pc-874v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56138"
},
{
"type": "WEB",
"url": "https://github.com/notaryproject/notation-go/commit/e7005a6d13e5ba472d4e166fbb085152f909e102"
},
{
"type": "WEB",
"url": "https://github.com/notaryproject/notation-go/commit/e99be1954a15673020150c5f8800b8174cd7428d"
},
{
"type": "PACKAGE",
"url": "https://github.com/notaryproject/notation-go"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2025-3381"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "notation-go\u0027s timestamp signature generation lacks certificate revocation check"
}
GHSA-5J2H-PWP3-258R
Vulnerability from github – Published: 2025-07-21 21:31 – Updated: 2025-07-21 21:31IBM Cognos Analytics Mobile (iOS) 1.1.0 through 1.1.22
is vulnerable to authentication bypass by using the Local Authentication Framework library which is not needed as biometric authentication is not used in the application.
{
"affected": [],
"aliases": [
"CVE-2025-36057"
],
"database_specific": {
"cwe_ids": [
"CWE-299"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-21T19:15:28Z",
"severity": "MODERATE"
},
"details": "IBM Cognos Analytics Mobile (iOS) 1.1.0 through 1.1.22 \n\nis vulnerable to authentication bypass by using the Local Authentication Framework library which is not needed as biometric authentication is not used in the application.",
"id": "GHSA-5j2h-pwp3-258r",
"modified": "2025-07-21T21:31:37Z",
"published": "2025-07-21T21:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-36057"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7239635"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8CW5-PXRW-VQHC
Vulnerability from github – Published: 2025-10-27 12:32 – Updated: 2025-10-27 12:32Incorrect validation of OCSP certificates vulnerability in TheGreenBow VPN, versions 7.5 and 7.6. During the IKEv2 authentication step, the OCSP-enabled VPN client establishes the tunnel even if it does not receive an OCSP response or if the OCSP response signature is invalid.
{
"affected": [],
"aliases": [
"CVE-2025-11955"
],
"database_specific": {
"cwe_ids": [
"CWE-299"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-27T12:15:32Z",
"severity": "HIGH"
},
"details": "Incorrect validation of OCSP certificates vulnerability in TheGreenBow VPN, versions 7.5 and 7.6. During the IKEv2 authentication step, the OCSP-enabled VPN client establishes the tunnel even if it does not receive an OCSP response or if the OCSP response signature is invalid.",
"id": "GHSA-8cw5-pxrw-vqhc",
"modified": "2025-10-27T12:32:52Z",
"published": "2025-10-27T12:32:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11955"
},
{
"type": "WEB",
"url": "https://www.incibe.es/en/incibe-cert/notices/aviso/incorrect-validation-ocsp-certificates-thegreenbow-vpn-client-windows"
},
{
"type": "WEB",
"url": "https://www.thegreenbow.com/en/support/security-alerts"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-8F6J-263M-G72X
Vulnerability from github – Published: 2026-07-13 23:49 – Updated: 2026-07-13 23:49Summary
SignedDataVerifier attempts to perform online revocation checking when enable_online_checks=True, but its OCSP validation logic accepts stale GOOD responses as valid indefinitely. In appstoreserverlibrary/signed_data_verifier.py, _ChainVerifier.check_ocsp_status() verifies the OCSP response signature and CertID match, but never validates the freshness window carried by producedAt, thisUpdate, or nextUpdate.
As a result, a previously valid signed OCSP GOOD response can be replayed after it is expired, and the library will still treat the certificate as good. If an App Store signing certificate or intermediate is ever revoked, applications using this library with online checks enabled can continue accepting JWS objects signed with the revoked key as long as a stale signed OCSP response is replayed.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.1.1"
},
"package": {
"ecosystem": "PyPI",
"name": "app-store-server-library"
},
"ranges": [
{
"events": [
{
"introduced": "0.2.0"
},
{
"fixed": "3.1.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-295",
"CWE-299"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-13T23:49:14Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n`SignedDataVerifier` attempts to perform online revocation checking when `enable_online_checks=True`, but its OCSP validation logic accepts stale `GOOD` responses as valid indefinitely. In `appstoreserverlibrary/signed_data_verifier.py`, `_ChainVerifier.check_ocsp_status()` verifies the OCSP response signature and CertID match, but never validates the freshness window carried by `producedAt`, `thisUpdate`, or `nextUpdate`.\n\nAs a result, a previously valid signed OCSP `GOOD` response can be replayed after it is expired, and the library will still treat the certificate as good. If an App Store signing certificate or intermediate is ever revoked, applications using this library with online checks enabled can continue accepting JWS objects signed with the revoked key as long as a stale signed OCSP response is replayed.",
"id": "GHSA-8f6j-263m-g72x",
"modified": "2026-07-13T23:49:14Z",
"published": "2026-07-13T23:49:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/apple/app-store-server-library-python/security/advisories/GHSA-8f6j-263m-g72x"
},
{
"type": "PACKAGE",
"url": "https://github.com/apple/app-store-server-library-python"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Apple App Store Server Python Library: SignedDataVerifier accepts stale OCSP GOOD responses and can bypass certificate revocation checks"
}
GHSA-CM26-5974-52H8
Vulnerability from github – Published: 2026-07-14 20:28 – Updated: 2026-07-14 20:28Summary
nebula-mesh revokes a host by adding its certificate fingerprint to a per-CA blocklist and shipping that list to every other agent on each poll. Slack's Nebula enforces certificate revocation ONLY through the pki.blocklist list in config.yml (no CRL/OCSP). The project's own code states this: internal/pki/durations.go:15 — "Revocation via the blocklist remains the immediate security control."
The server side is fully implemented (computes per-CA blocklist via GetBlocklistForCA, returns it in the agent-updates response, sets has_updates=true when non-empty). The agent side was never implemented:
- The agent decodes the
blocklistJSON field intoUpdatesResponse.Blocklist(internal/agent/poller.go:33) and then DISCARDS it —poll()appliesCertificatePEM,CACertPEM,ConfigYAML, but never referencesupdates.Blocklist(internal/agent/poller.go:300-339). - The config generator has NO field to emit
pki.blocklist—pkiSectionis onlyca/cert/key(internal/configgen/marshal.go:42-46) andGeneratorInputcarries no blocklist (internal/configgen/generator.go:23-52). So even the server-renderedconfig.ymlshipped viaConfigYAMLcannot carry it.
Result: a blocked/offboarded/compromised host's certificate is never rejected by its peers. Its handshakes keep succeeding for the full remaining cert lifetime — up to 30 days for agent hosts (DefaultAgentCertDuration) and 365 days for mobile hosts (DefaultMobileCertDuration). Blocking a host in the UI/API has no effect on the data plane.
Affected components
- Agent drops the blocklist:
internal/agent/poller.go:33(decode target),internal/agent/poller.go:300-339(poll() applies cert/CA/config, never the blocklist). - Generator cannot emit it:
internal/configgen/marshal.go:42-46(pkiSection{CA,Cert,Key}),internal/configgen/generator.go:23-52(GeneratorInputhas no blocklist),internal/api/enroll.go:255-330(renderHostConfig, source of shipped ConfigYAML). - Server correctly produces/ships it (proves intent):
internal/store/sqlite.go:2034(GetBlocklistForCA),internal/api/updates.go:182-191(resp.Blocklist),internal/api/updates.go:277(has_updatesset on blocklist change). - Dead helper:
internal/pki/blocklist.go(Blocklisttype) is never used in non-test code — no server-side enforcement either.
Reachability (hop by hop)
- Operator clicks Block on host B (or B is compromised/offboarded). B's fingerprint enters the per-CA
blocklisttable. - Every other host A under the same CA polls
GET /api/v1/agent/updates; server returnsblocklist: [<B-fp>, ...]andhas_updates=true. - A's agent decodes
Blocklistthen discards it;poll()has no blocklist branch. - Even on a config re-render,
configgen.Generateemitspki: {ca,cert,key}with noblocklistkey (proven by PoC). - A's Nebula daemon has an empty blocklist and accepts handshakes from B's still-valid cert. B keeps full mesh access.
Impact
Revocation is the only in-band mechanism that isolates a compromised/offboarded host from a Nebula mesh. Because the blocklist never reaches any peer's config.yml, a Blocked host retains full overlay reachability to every peer under its CA (and internal services on the mesh) for up to 30d (agent) / 365d (mobile). An attacker who exfiltrates host.key+host.crt can run stock slackhq/nebula directly, ignore the agent's 403/410 poll responses, and stay connected after the operator revokes the host. Operator-visible state (UI shows blocked, audit log records it) is misleading.
Proof of Concept (benign)
internal/configgen/blocklist_poc_test.go renders a fully-populated host config and asserts the output contains the pki section but NO blocklist key:
$ go test ./internal/configgen/ -run TestPoC_NMESH001 -v
=== RUN TestPoC_NMESH001_GeneratedConfigOmitsBlocklist
CONFIRMED: generated config has a pki section but no blocklist key
pki:
ca: /etc/nebula/ca.crt
cert: /etc/nebula/host.crt
key: /etc/nebula/host.key
...
--- PASS
The agent half is verifiable by inspection: poll() has branches for CertificatePEM/CACertPEM/ConfigYAML/RekeyRequired but none for Blocklist.
Distinctness
NOT a duplicate of GHSA-339v / CVE-2026-53602 (revocation durability = a blocked host getting a NEW cert re-issued; its fix CheckIssuanceAllowed is present and orthogonal). This bug is that the EXISTING cert is never rejected at peers — the distribution/enforcement layer. Checked against all 17 known advisories; none cover blocklist application in the agent or pki.blocklist generation.
Remediation
- Add
Blocklist []safeStringtopkiSection(yamlblocklist,omitempty) andGeneratorInput; consider alsopki.disconnect_invalid: true. - Have the agent apply
updates.Blocklistby re-rendering/rewritingconfig.yml+ SIGHUP (same path asConfigYAML). Simplest: fold the blocklist into the server-renderedConfigYAMLso it flows through the existing write path. - Add a regression test asserting a non-empty server blocklist yields a
pki.blocklistentry in the agent's written config.yml.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/forgekeep/nebula-mesh"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.7.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-61699"
],
"database_specific": {
"cwe_ids": [
"CWE-299",
"CWE-672"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-14T20:28:18Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nnebula-mesh revokes a host by adding its certificate fingerprint to a per-CA blocklist and shipping that list to every other agent on each poll. Slack\u0027s Nebula enforces certificate revocation ONLY through the `pki.blocklist` list in `config.yml` (no CRL/OCSP). The project\u0027s own code states this: `internal/pki/durations.go:15` \u2014 \"Revocation via the blocklist remains the immediate security control.\"\n\nThe server side is fully implemented (computes per-CA blocklist via `GetBlocklistForCA`, returns it in the agent-updates response, sets `has_updates=true` when non-empty). The agent side was never implemented:\n\n1. The agent decodes the `blocklist` JSON field into `UpdatesResponse.Blocklist` (`internal/agent/poller.go:33`) and then DISCARDS it \u2014 `poll()` applies `CertificatePEM`, `CACertPEM`, `ConfigYAML`, but never references `updates.Blocklist` (`internal/agent/poller.go:300-339`).\n2. The config generator has NO field to emit `pki.blocklist` \u2014 `pkiSection` is only `ca`/`cert`/`key` (`internal/configgen/marshal.go:42-46`) and `GeneratorInput` carries no blocklist (`internal/configgen/generator.go:23-52`). So even the server-rendered `config.yml` shipped via `ConfigYAML` cannot carry it.\n\nResult: a blocked/offboarded/compromised host\u0027s certificate is never rejected by its peers. Its handshakes keep succeeding for the full remaining cert lifetime \u2014 up to 30 days for agent hosts (`DefaultAgentCertDuration`) and 365 days for mobile hosts (`DefaultMobileCertDuration`). Blocking a host in the UI/API has no effect on the data plane.\n\n### Affected components\n\n- Agent drops the blocklist: `internal/agent/poller.go:33` (decode target), `internal/agent/poller.go:300-339` (poll() applies cert/CA/config, never the blocklist).\n- Generator cannot emit it: `internal/configgen/marshal.go:42-46` (`pkiSection{CA,Cert,Key}`), `internal/configgen/generator.go:23-52` (`GeneratorInput` has no blocklist), `internal/api/enroll.go:255-330` (`renderHostConfig`, source of shipped ConfigYAML).\n- Server correctly produces/ships it (proves intent): `internal/store/sqlite.go:2034` (`GetBlocklistForCA`), `internal/api/updates.go:182-191` (`resp.Blocklist`), `internal/api/updates.go:277` (`has_updates` set on blocklist change).\n- Dead helper: `internal/pki/blocklist.go` (`Blocklist` type) is never used in non-test code \u2014 no server-side enforcement either.\n\n### Reachability (hop by hop)\n\n1. Operator clicks Block on host B (or B is compromised/offboarded). B\u0027s fingerprint enters the per-CA `blocklist` table.\n2. Every other host A under the same CA polls `GET /api/v1/agent/updates`; server returns `blocklist: [\u003cB-fp\u003e, ...]` and `has_updates=true`.\n3. A\u0027s agent decodes `Blocklist` then discards it; `poll()` has no blocklist branch.\n4. Even on a config re-render, `configgen.Generate` emits `pki: {ca,cert,key}` with no `blocklist` key (proven by PoC).\n5. A\u0027s Nebula daemon has an empty blocklist and accepts handshakes from B\u0027s still-valid cert. B keeps full mesh access.\n\n### Impact\n\nRevocation is the only in-band mechanism that isolates a compromised/offboarded host from a Nebula mesh. Because the blocklist never reaches any peer\u0027s config.yml, a Blocked host retains full overlay reachability to every peer under its CA (and internal services on the mesh) for up to 30d (agent) / 365d (mobile). An attacker who exfiltrates `host.key`+`host.crt` can run stock slackhq/nebula directly, ignore the agent\u0027s 403/410 poll responses, and stay connected after the operator revokes the host. Operator-visible state (UI shows blocked, audit log records it) is misleading.\n\n### Proof of Concept (benign)\n\n`internal/configgen/blocklist_poc_test.go` renders a fully-populated host config and asserts the output contains the `pki` section but NO `blocklist` key:\n\n```\n$ go test ./internal/configgen/ -run TestPoC_NMESH001 -v\n=== RUN TestPoC_NMESH001_GeneratedConfigOmitsBlocklist\n CONFIRMED: generated config has a pki section but no blocklist key\n pki:\n ca: /etc/nebula/ca.crt\n cert: /etc/nebula/host.crt\n key: /etc/nebula/host.key\n ...\n--- PASS\n```\n\nThe agent half is verifiable by inspection: `poll()` has branches for CertificatePEM/CACertPEM/ConfigYAML/RekeyRequired but none for Blocklist.\n\n### Distinctness\n\nNOT a duplicate of GHSA-339v / CVE-2026-53602 (revocation durability = a blocked host getting a NEW cert re-issued; its fix `CheckIssuanceAllowed` is present and orthogonal). This bug is that the EXISTING cert is never rejected at peers \u2014 the distribution/enforcement layer. Checked against all 17 known advisories; none cover blocklist application in the agent or `pki.blocklist` generation.\n\n### Remediation\n\n1. Add `Blocklist []safeString` to `pkiSection` (yaml `blocklist,omitempty`) and `GeneratorInput`; consider also `pki.disconnect_invalid: true`.\n2. Have the agent apply `updates.Blocklist` by re-rendering/rewriting `config.yml` + SIGHUP (same path as `ConfigYAML`). Simplest: fold the blocklist into the server-rendered `ConfigYAML` so it flows through the existing write path.\n3. Add a regression test asserting a non-empty server blocklist yields a `pki.blocklist` entry in the agent\u0027s written config.yml.",
"id": "GHSA-cm26-5974-52h8",
"modified": "2026-07-14T20:28:18Z",
"published": "2026-07-14T20:28:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/forgekeep/nebula-mesh/security/advisories/GHSA-cm26-5974-52h8"
},
{
"type": "WEB",
"url": "https://github.com/forgekeep/nebula-mesh/commit/0426e2f224a9b1e2029029bf923c93ed39d21cdb"
},
{
"type": "PACKAGE",
"url": "https://github.com/forgekeep/nebula-mesh"
},
{
"type": "WEB",
"url": "https://github.com/forgekeep/nebula-mesh/releases/tag/v0.7.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "nebula-mesh: Certificate revocation is never enforced at the mesh"
}
GHSA-FVQ9-7G3P-R5G2
Vulnerability from github – Published: 2026-07-14 18:31 – Updated: 2026-07-14 18:31A security issue exists within CompactLogix® 5380, ControlLogix® 5580, and EN4 communication modules related to CIP Security certificate revocation handling. The security issue stems from the controller failing to properly reject certificates signed by an intermediate certificate that has been revoked via a Certificate Revocation List (CRL). This could allow a network-based attacker to establish a connection using a certificate that should be untrusted, potentially bypassing CIP Security protections.
{
"affected": [],
"aliases": [
"CVE-2026-9636"
],
"database_specific": {
"cwe_ids": [
"CWE-299"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-14T16:17:05Z",
"severity": "HIGH"
},
"details": "A security issue exists within CompactLogix\u00ae 5380, ControlLogix\u00ae 5580, and EN4 communication modules related to CIP Security certificate revocation handling. The security issue stems from the controller failing to properly reject certificates signed by an intermediate certificate that has been revoked via a Certificate Revocation List (CRL). This could allow a network-based attacker to establish a connection using a certificate that should be untrusted, potentially bypassing CIP Security protections.",
"id": "GHSA-fvq9-7g3p-r5g2",
"modified": "2026-07-14T18:31:56Z",
"published": "2026-07-14T18:31:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9636"
},
{
"type": "WEB",
"url": "https://www.rockwellautomation.com/en-us/trust-center/security-advisories/advisory.SD1788.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-G25M-MG72-9V2W
Vulnerability from github – Published: 2022-05-24 17:28 – Updated: 2023-12-12 21:31Patient Information Center iX (PICiX) Versions B.02, C.02, C.03, PerformanceBridge Focal Point Version A.01, IntelliVue patient monitors MX100, MX400-MX850, and MP2-MP90 Versions N and prior, IntelliVue X3 and X2 Versions N and prior. The software does not check or incorrectly checks the revocation status of a certificate, which may cause it to use a compromised certificate.
{
"affected": [],
"aliases": [
"CVE-2020-16228"
],
"database_specific": {
"cwe_ids": [
"CWE-299"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-09-11T13:15:00Z",
"severity": "MODERATE"
},
"details": "Patient Information Center iX (PICiX) Versions B.02, C.02, C.03, PerformanceBridge Focal Point Version A.01, IntelliVue patient monitors MX100, MX400-MX850, and MP2-MP90 Versions N and prior, IntelliVue X3 and X2 Versions N and prior. The software does not check or incorrectly checks the revocation status of a certificate, which may cause it to use a compromised certificate.",
"id": "GHSA-g25m-mg72-9v2w",
"modified": "2023-12-12T21:31:06Z",
"published": "2022-05-24T17:28:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-16228"
},
{
"type": "WEB",
"url": "https://us-cert.cisa.gov/ics/advisories/icsma-20-254-01"
},
{
"type": "WEB",
"url": "https://www.philips.com/productsecurity"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:L",
"type": "CVSS_V3"
}
]
}
Mitigation
Ensure that certificates are checked for revoked status.
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 revoked status.
No CAPEC attack patterns related to this CWE.