Skip to content

5.1.0 accepts language of "eng" (instead of "en") in most places #260

@ElectricNroff

Description

@ElectricNroff

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."

As far as I know, it was not intended that a provider express a common language with a three-letter code instead of the two-letter code such as "en"

minimal/plausible test case (the CNA uses "eng" under problemTypes)

{"dataType":"CVE_RECORD","dataVersion":"5.1","cveMetadata":{"cveId":"CVE-2025-0001",
"assignerOrgId":"b3476cb9-2e3d-41a6-98d0-0f47421a65b6","state":"PUBLISHED"},
"containers":{"cna":{"providerMetadata":{"orgId":"b3476cb9-2e3d-41a6-98d0-0f47421a65b6"},
"affected":[{"vendor":"v","product":"p",
"versions":[{"version":"1","status":"affected"}],
"defaultStatus":"affected"}],
"problemTypes":[{"descriptions":[{"lang":"eng","description":"d"}]}],
"descriptions":[{"lang":"en","value":"d"}],"references":[{"url":"https://a.ai"}]}}}

possible solution: because English is a required language for some CVE Record content, is the most common language in CVE Records thus far, and has had issues such as CVEProject/cve-services#980 with the three-letter code "eng" in the past, implement a negative lookahead to block only "eng"

"pattern": "^(?!eng)[A-Za-z]{2,4}([_-][A-Za-z]{4})?([_-]([A-Za-z]{2}|[0-9]{3}))?$"

issues on the current CVE List (CNAs sometimes use "eng" instead of "en" to mean English)

CVE-2021-23166
CVE-2021-23176
CVE-2021-23178
CVE-2021-23186
CVE-2021-23203
CVE-2021-26263
CVE-2021-26947
CVE-2021-44460
CVE-2021-44465
CVE-2021-44476
CVE-2021-44547
CVE-2021-44775
CVE-2021-45071
CVE-2021-45111
CVE-2023-0019
CVE-2023-0020
CVE-2023-0021
CVE-2023-0024
CVE-2023-0025
CVE-2023-1903
CVE-2023-23851
CVE-2023-23852
CVE-2023-23853
CVE-2023-23854
CVE-2023-23855
CVE-2023-23856
CVE-2023-23857
CVE-2023-23858
CVE-2023-23859
CVE-2023-23860
CVE-2023-24521
CVE-2023-24522
CVE-2023-24523
CVE-2023-24524
CVE-2023-24525
CVE-2023-24526
CVE-2023-24527
CVE-2023-24528
CVE-2023-24529
CVE-2023-24530
CVE-2023-25614
CVE-2023-25615
CVE-2023-25616
CVE-2023-25617
CVE-2023-25618
CVE-2023-26457
CVE-2023-26458
CVE-2023-26459
CVE-2023-26460
CVE-2023-26461
CVE-2023-27267
CVE-2023-27268
CVE-2023-27269
CVE-2023-27270
CVE-2023-27271
CVE-2023-27497
CVE-2023-27498
CVE-2023-27499
CVE-2023-27500
CVE-2023-27501
CVE-2023-27893
CVE-2023-27894
CVE-2023-27895
CVE-2023-27896
CVE-2023-27897
CVE-2023-2827
CVE-2023-28761
CVE-2023-28762
CVE-2023-28763
CVE-2023-28764
CVE-2023-28765
CVE-2023-29108
CVE-2023-29109
CVE-2023-29110
CVE-2023-29111
CVE-2023-29112
CVE-2023-29185
CVE-2023-29186
CVE-2023-29187
CVE-2023-29188
CVE-2023-29189
CVE-2023-30740
CVE-2023-30741
CVE-2023-30742
CVE-2023-30743
CVE-2023-30744
CVE-2023-31404
CVE-2023-31405
CVE-2023-31406
CVE-2023-31407
CVE-2023-32111
CVE-2023-32112
CVE-2023-32113
CVE-2023-32114
CVE-2023-32115
CVE-2023-33984
CVE-2023-33985
CVE-2023-33986
CVE-2023-33987
CVE-2023-33988
CVE-2023-33989
CVE-2023-33990
CVE-2023-33991
CVE-2023-33992
CVE-2023-33993
CVE-2023-35870
CVE-2023-35871
CVE-2023-35872
CVE-2023-35873
CVE-2023-35874
CVE-2023-36917
CVE-2023-36918
CVE-2023-36919
CVE-2023-36921
CVE-2023-36922
CVE-2023-36923
CVE-2023-36924
CVE-2023-36925
CVE-2023-36926
CVE-2023-37483
CVE-2023-37484
CVE-2023-37486
CVE-2023-37487
CVE-2023-37488
CVE-2023-37489
CVE-2023-37490
CVE-2023-37491
CVE-2023-37492
CVE-2023-39436
CVE-2023-39437
CVE-2023-39439
CVE-2023-39440
CVE-2023-40308
CVE-2023-40309
CVE-2023-40310
CVE-2023-40622
CVE-2023-40623
CVE-2023-40624
CVE-2023-40625
CVE-2023-41365
CVE-2023-41367
CVE-2023-41368
CVE-2023-41369
CVE-2023-42472
CVE-2023-42473
CVE-2023-42474
CVE-2023-42475
CVE-2023-42477

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingsection:otherSchema location is other than those specifically defined

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions