From fb471a81f7caa981fe469b74ad2856b4843e9222 Mon Sep 17 00:00:00 2001 From: CVE Team Date: Tue, 22 Nov 2022 20:00:35 +0000 Subject: [PATCH] "-Synchronized-Data." --- 2019/19xxx/CVE-2019-19221.json | 5 ++ 2021/23xxx/CVE-2021-23177.json | 5 ++ 2021/31xxx/CVE-2021-31566.json | 5 ++ 2022/2xxx/CVE-2022-2791.json | 84 ++++++++++++++++++++++++++++++++-- 2022/39xxx/CVE-2022-39199.json | 2 +- 5 files changed, 96 insertions(+), 5 deletions(-) diff --git a/2019/19xxx/CVE-2019-19221.json b/2019/19xxx/CVE-2019-19221.json index f11ae302ef0..cac58f500e6 100644 --- a/2019/19xxx/CVE-2019-19221.json +++ b/2019/19xxx/CVE-2019-19221.json @@ -76,6 +76,11 @@ "refsource": "MLIST", "name": "[debian-lts-announce] 20220430 [SECURITY] [DLA 2987-1] libarchive security update", "url": "https://lists.debian.org/debian-lts-announce/2022/04/msg00020.html" + }, + { + "refsource": "MLIST", + "name": "[debian-lts-announce] 20221122 [SECURITY] [DLA 3202-1] libarchive security update", + "url": "https://lists.debian.org/debian-lts-announce/2022/11/msg00030.html" } ] } diff --git a/2021/23xxx/CVE-2021-23177.json b/2021/23xxx/CVE-2021-23177.json index 1bc3fb38afa..4cdddddb891 100644 --- a/2021/23xxx/CVE-2021-23177.json +++ b/2021/23xxx/CVE-2021-23177.json @@ -63,6 +63,11 @@ "refsource": "MISC", "name": "https://access.redhat.com/security/cve/CVE-2021-23177", "url": "https://access.redhat.com/security/cve/CVE-2021-23177" + }, + { + "refsource": "MLIST", + "name": "[debian-lts-announce] 20221122 [SECURITY] [DLA 3202-1] libarchive security update", + "url": "https://lists.debian.org/debian-lts-announce/2022/11/msg00030.html" } ] }, diff --git a/2021/31xxx/CVE-2021-31566.json b/2021/31xxx/CVE-2021-31566.json index a4d2f4071b5..00b23301ca3 100644 --- a/2021/31xxx/CVE-2021-31566.json +++ b/2021/31xxx/CVE-2021-31566.json @@ -63,6 +63,11 @@ "refsource": "MISC", "name": "https://access.redhat.com/security/cve/CVE-2021-31566", "url": "https://access.redhat.com/security/cve/CVE-2021-31566" + }, + { + "refsource": "MLIST", + "name": "[debian-lts-announce] 20221122 [SECURITY] [DLA 3202-1] libarchive security update", + "url": "https://lists.debian.org/debian-lts-announce/2022/11/msg00030.html" } ] }, diff --git a/2022/2xxx/CVE-2022-2791.json b/2022/2xxx/CVE-2022-2791.json index 97c165fef00..7dfaa757908 100644 --- a/2022/2xxx/CVE-2022-2791.json +++ b/2022/2xxx/CVE-2022-2791.json @@ -1,17 +1,93 @@ { + "data_version": "4.0", "data_type": "CVE", "data_format": "MITRE", - "data_version": "4.0", "CVE_data_meta": { "ID": "CVE-2022-2791", - "ASSIGNER": "cve@mitre.org", - "STATE": "RESERVED" + "ASSIGNER": "ics-cert@hq.dhs.gov", + "STATE": "PUBLIC" }, "description": { "description_data": [ { "lang": "eng", - "value": "** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided." + "value": "Emerson Electric's Proficy Machine Edition Version 9.00 and prior is vulnerable to CWE-434 Unrestricted Upload of File with Dangerous Type, and will upload any file written into the PLC logic folder to the connected PLC." + } + ] + }, + "problemtype": { + "problemtype_data": [ + { + "description": [ + { + "lang": "eng", + "value": "CWE-434 Unrestricted Upload of File with Dangerous Type", + "cweId": "CWE-434" + } + ] + } + ] + }, + "affects": { + "vendor": { + "vendor_data": [ + { + "vendor_name": "Emerson Electric", + "product": { + "product_data": [ + { + "product_name": "Proficy Machine Edition", + "version": { + "version_data": [ + { + "version_value": "0", + "version_affected": "=" + } + ] + } + } + ] + } + } + ] + } + }, + "references": { + "reference_data": [ + { + "url": "https://www.cisa.gov/uscert/ics/advisories/icsa-22-228-06", + "refsource": "MISC", + "name": "https://www.cisa.gov/uscert/ics/advisories/icsa-22-228-06" + } + ] + }, + "generator": { + "engine": "Vulnogram 0.1.0-dev" + }, + "source": { + "discovery": "EXTERNAL" + }, + "credits": [ + { + "lang": "en", + "value": "Sharon Brizinov of Claroty Research" + } + ], + "impact": { + "cvss": [ + { + "attackComplexity": "LOW", + "attackVector": "LOCAL", + "availabilityImpact": "NONE", + "baseScore": 5.9, + "baseSeverity": "MEDIUM", + "confidentialityImpact": "NONE", + "integrityImpact": "HIGH", + "privilegesRequired": "LOW", + "scope": "CHANGED", + "userInteraction": "REQUIRED", + "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:N/I:H/A:N", + "version": "3.1" } ] } diff --git a/2022/39xxx/CVE-2022-39199.json b/2022/39xxx/CVE-2022-39199.json index 3058922876d..b11a452af3f 100644 --- a/2022/39xxx/CVE-2022-39199.json +++ b/2022/39xxx/CVE-2022-39199.json @@ -35,7 +35,7 @@ "description_data": [ { "lang": "eng", - "value": "immudb is a database with built-in cryptographic proof and verification. immudb client SDKs use server's UUID to distinguish between different server instance so that the client can connect to different immudb instances and keep the state for multiple servers. SDK does not validate this uuid and can accept any value reported by the server. A malicious server can change the reported UUID tricking the client to treat it as a different server thus accepting a state completely irrelevant to the one previously retrieved from the server. This issue has been patched in version 1.4.1. As a workaround, when initializing an immudb client object a custom state handler can be used to store the state. Providing custom implementation that ignores the server UUID can be used to ensure that even if the server changes the UUID, client will still consider it to be the same server.\n\n" + "value": "immudb is a database with built-in cryptographic proof and verification. immudb client SDKs use server's UUID to distinguish between different server instance so that the client can connect to different immudb instances and keep the state for multiple servers. SDK does not validate this uuid and can accept any value reported by the server. A malicious server can change the reported UUID tricking the client to treat it as a different server thus accepting a state completely irrelevant to the one previously retrieved from the server. This issue has been patched in version 1.4.1. As a workaround, when initializing an immudb client object a custom state handler can be used to store the state. Providing custom implementation that ignores the server UUID can be used to ensure that even if the server changes the UUID, client will still consider it to be the same server." } ] },