At the 2023-12-14 TWG meeting, the discussion suggested that, during testing of the 5.1.0 schema, any CVE Record that validated even though the record format was not "intended" would be considered a "loophole."
|
"user": { |
|
"description": "UUID of the user being credited if present in the CVE User Registry (optional). This UUID can be used to lookup the user record in the user registry service.", |
|
"$ref": "#/definitions/uuidType" |
|
}, |
indicates that a field such as /containers/cna/credits/0/user should be used only if the user is present in the User Registry. A User Registry has not yet been deployed, and thus this field should
not exist in any CVE Record. However, more than 4000 CVE Records have this, all with the 00000000-0000-4000-9000-000000000000 UUID.
As far as I know, it was not intended that a provider populate the /containers/cna/credits/0/user field with an arbitrary UUID that complies with the version 4 UUID syntax. It is an optional field, and it has always been possible to construct a CVE Record without this, and still comply with either the 5.0.0 or 5.1.0 schema.
possible workaround: implement a negative lookahead for 00000000-0000-4000-9000-000000000000 (this is similar to the suggestion of a negative lookahead for "eng" in the #260 issue). This may effectively prevent all known clients from continuing to submit this type of invalid data. Later, when the User Registry exists, the server will be able to deny all CVE Record container submissions that mention a user UUID that does not exist in the User Registry.
Issues on the current CVE List: 4212 CVE Records from at least 122 different CNAs (this list is too large for a single post to a GitHub issue)
Count by CNA
2183 Patchstack
310 icscert
178 TR-CERT
163 INCIBE
129 hpe
102 CERTVDE
87 Mattermost
50 INCD
47 SolarWinds
40 f5
40 SEL
35 qnap
34 rapid7
34 DIVD
32 Google
30 STAR_Labs
27 trellix
25 Securifera
24 lenovo
22 cloudflare
22 Rockwell
22 @huntrdev
21 openssl
21 dell
20 NCSC.ch
20 HITVAN
20 ABB
19 PandoraFMS
15 Zscaler
15 Nozomi
15 GitHub_P
14 kubernetes
13 ProgressSoftware
13 ASRG
13 AMI
11 Hitachi
10 freebsd
10 WDC
10 TML
10 NEC
10 3DS
9 suse
9 mozilla
9 OpenNMS
9 Bitdefender
9 ASUSTOR1
8 Zabbix
8 Splunk
8 OpenText
8 Liferay
8 CyberDanube
7 php
7 SN
7 ONEKEY
7 Docker
7 Arm
6 mongodb
6 VulnCheck
6 Qualys
6 Pega
6 OTRS
6 CERT-PL
6 AHA
5 palo_alto
5 openEuler
5 eclipse
5 certcc
5 Proofpoint
5 GandC
5 Dragos
5 1E
4 jci
4 Netskope
4 Moxa
4 M-Files
4 Eaton
4 Baicells
3 tenable
3 krcert
3 forcepoint
3 SNPS
3 Joomla
3 HashiCorp
2 samsung.tv_appliance
2 crafter
2 Sophos
2 Snow
2 SEC-VLab
2 ODA
2 Mandiant
2 KNIME
2 Halborn
2 Gallagher
2 ESET
2 Document
2 @huntr_ai
1 zephyr
1 wolfSSL
1 vmware
1 cisa-cg
1 avaya
1 Wordfence
1 Vaadin
1 Tigera
1 Temporal
1 THA-PSIRT
1 SailPoint
1 SK-CERT
1 PureStorage
1 Payara
1 PaperCut
1 PSF
1 OpenCloudOS
1 NLOK
1 Medtronic
1 MIM
1 GreenRocketSecurity
1 GovTech
1 GE
1 DEVOLUTIONS
1 B.Braun
1 AlgoSec
At the 2023-12-14 TWG meeting, the discussion suggested that, during testing of the 5.1.0 schema, any CVE Record that validated even though the record format was not "intended" would be considered a "loophole."
cve-schema/schema/v5.0/CVE_JSON_5.1_schema.json
Lines 1013 to 1016 in 2aa608b
indicates that a field such as /containers/cna/credits/0/user should be used only if the user is present in the User Registry. A User Registry has not yet been deployed, and thus this field should not exist in any CVE Record. However, more than 4000 CVE Records have this, all with the 00000000-0000-4000-9000-000000000000 UUID.
As far as I know, it was not intended that a provider populate the /containers/cna/credits/0/user field with an arbitrary UUID that complies with the version 4 UUID syntax. It is an optional field, and it has always been possible to construct a CVE Record without this, and still comply with either the 5.0.0 or 5.1.0 schema.
possible workaround: implement a negative lookahead for 00000000-0000-4000-9000-000000000000 (this is similar to the suggestion of a negative lookahead for "eng" in the #260 issue). This may effectively prevent all known clients from continuing to submit this type of invalid data. Later, when the User Registry exists, the server will be able to deny all CVE Record container submissions that mention a user UUID that does not exist in the User Registry.
Issues on the current CVE List: 4212 CVE Records from at least 122 different CNAs (this list is too large for a single post to a GitHub issue)
Count by CNA
2183 Patchstack
310 icscert
178 TR-CERT
163 INCIBE
129 hpe
102 CERTVDE
87 Mattermost
50 INCD
47 SolarWinds
40 f5
40 SEL
35 qnap
34 rapid7
34 DIVD
32 Google
30 STAR_Labs
27 trellix
25 Securifera
24 lenovo
22 cloudflare
22 Rockwell
22 @huntrdev
21 openssl
21 dell
20 NCSC.ch
20 HITVAN
20 ABB
19 PandoraFMS
15 Zscaler
15 Nozomi
15 GitHub_P
14 kubernetes
13 ProgressSoftware
13 ASRG
13 AMI
11 Hitachi
10 freebsd
10 WDC
10 TML
10 NEC
10 3DS
9 suse
9 mozilla
9 OpenNMS
9 Bitdefender
9 ASUSTOR1
8 Zabbix
8 Splunk
8 OpenText
8 Liferay
8 CyberDanube
7 php
7 SN
7 ONEKEY
7 Docker
7 Arm
6 mongodb
6 VulnCheck
6 Qualys
6 Pega
6 OTRS
6 CERT-PL
6 AHA
5 palo_alto
5 openEuler
5 eclipse
5 certcc
5 Proofpoint
5 GandC
5 Dragos
5 1E
4 jci
4 Netskope
4 Moxa
4 M-Files
4 Eaton
4 Baicells
3 tenable
3 krcert
3 forcepoint
3 SNPS
3 Joomla
3 HashiCorp
2 samsung.tv_appliance
2 crafter
2 Sophos
2 Snow
2 SEC-VLab
2 ODA
2 Mandiant
2 KNIME
2 Halborn
2 Gallagher
2 ESET
2 Document
2 @huntr_ai
1 zephyr
1 wolfSSL
1 vmware
1 cisa-cg
1 avaya
1 Wordfence
1 Vaadin
1 Tigera
1 Temporal
1 THA-PSIRT
1 SailPoint
1 SK-CERT
1 PureStorage
1 Payara
1 PaperCut
1 PSF
1 OpenCloudOS
1 NLOK
1 Medtronic
1 MIM
1 GreenRocketSecurity
1 GovTech
1 GE
1 DEVOLUTIONS
1 B.Braun
1 AlgoSec