@blamejs/exceptd-skills 0.18.28 → 0.18.29

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "_meta": {
3
3
  "schema_version": "1.0.0",
4
- "last_updated": "2026-07-30",
4
+ "last_updated": "2026-08-06",
5
5
  "cwe_version": "4.20",
6
6
  "cwe_version_release_date": "2026-04-30",
7
7
  "source": "https://cwe.mitre.org",
@@ -48,10 +48,17 @@
48
48
  "fuzz-testing-strategy"
49
49
  ],
50
50
  "evidence_cves": [
51
+ "CVE-2010-2568",
52
+ "CVE-2013-6282",
53
+ "CVE-2015-2291",
51
54
  "CVE-2016-3714",
52
55
  "CVE-2021-25489",
53
56
  "CVE-2022-1471",
57
+ "CVE-2022-2856",
58
+ "CVE-2022-3075",
59
+ "CVE-2022-47966",
54
60
  "CVE-2023-22515",
61
+ "CVE-2023-22952",
55
62
  "CVE-2023-23397",
56
63
  "CVE-2023-2868",
57
64
  "CVE-2023-36563",
@@ -109,14 +116,20 @@
109
116
  ],
110
117
  "evidence_cves": [
111
118
  "CVE-2017-12637",
119
+ "CVE-2018-18809",
120
+ "CVE-2018-5430",
112
121
  "CVE-2019-16278",
113
122
  "CVE-2019-5418",
123
+ "CVE-2020-36193",
114
124
  "CVE-2021-20123",
115
125
  "CVE-2021-20124",
116
126
  "CVE-2021-26086",
117
127
  "CVE-2021-41277",
118
128
  "CVE-2021-43798",
129
+ "CVE-2022-26352",
130
+ "CVE-2022-26500",
119
131
  "CVE-2022-41328",
132
+ "CVE-2022-41352",
120
133
  "CVE-2023-32315",
121
134
  "CVE-2023-35081",
122
135
  "CVE-2023-38950",
@@ -201,6 +214,7 @@
201
214
  "CVE-2020-25079",
202
215
  "CVE-2021-27878",
203
216
  "CVE-2021-33515",
217
+ "CVE-2022-40765",
204
218
  "CVE-2023-1389",
205
219
  "CVE-2023-1671",
206
220
  "CVE-2023-20118",
@@ -267,6 +281,7 @@
267
281
  "CVE-2017-3506",
268
282
  "CVE-2017-6884",
269
283
  "CVE-2018-14933",
284
+ "CVE-2018-6530",
270
285
  "CVE-2018-9276",
271
286
  "CVE-2019-11001",
272
287
  "CVE-2019-17621",
@@ -277,7 +292,13 @@
277
292
  "CVE-2021-20035",
278
293
  "CVE-2021-36380",
279
294
  "CVE-2021-40407",
295
+ "CVE-2022-26258",
296
+ "CVE-2022-28810",
280
297
  "CVE-2022-29303",
298
+ "CVE-2022-33891",
299
+ "CVE-2022-36804",
300
+ "CVE-2022-44877",
301
+ "CVE-2022-46169",
281
302
  "CVE-2023-20273",
282
303
  "CVE-2023-25280",
283
304
  "CVE-2023-27992",
@@ -424,6 +445,7 @@
424
445
  "skills_referencing": [],
425
446
  "evidence_cves": [
426
447
  "CVE-2016-10033",
448
+ "CVE-2022-36804",
427
449
  "CVE-2024-41710",
428
450
  "CVE-2026-24061",
429
451
  "CVE-2026-30623",
@@ -525,9 +547,13 @@
525
547
  "CVE-2021-3129",
526
548
  "CVE-2021-39144",
527
549
  "CVE-2021-44529",
550
+ "CVE-2022-22963",
528
551
  "CVE-2022-24816",
552
+ "CVE-2022-3236",
553
+ "CVE-2022-41223",
529
554
  "CVE-2022-43769",
530
555
  "CVE-2022-48503",
556
+ "CVE-2023-22952",
531
557
  "CVE-2023-24955",
532
558
  "CVE-2023-25717",
533
559
  "CVE-2023-29492",
@@ -584,6 +610,7 @@
584
610
  "CVE-2026-45829",
585
611
  "CVE-2026-5760",
586
612
  "CVE-2026-6973",
613
+ "CVE-2026-9198",
587
614
  "MAL-2026-3083",
588
615
  "MAL-2026-TRAPDOOR-CROSS-ECOSYSTEM"
589
616
  ],
@@ -700,7 +727,10 @@
700
727
  "evidence_cves": [
701
728
  "CVE-2015-5317",
702
729
  "CVE-2016-6415",
730
+ "CVE-2017-5521",
731
+ "CVE-2018-5430",
703
732
  "CVE-2020-3259",
733
+ "CVE-2021-25369",
704
734
  "CVE-2021-41277",
705
735
  "CVE-2023-21237",
706
736
  "CVE-2023-28432",
@@ -813,6 +843,7 @@
813
843
  "CVE-2013-0643",
814
844
  "CVE-2016-0165",
815
845
  "CVE-2019-1388",
846
+ "CVE-2021-25337",
816
847
  "CVE-2021-43226",
817
848
  "CVE-2022-38028",
818
849
  "CVE-2023-28434",
@@ -931,7 +962,9 @@
931
962
  "CVE-2021-32030",
932
963
  "CVE-2021-33044",
933
964
  "CVE-2021-33045",
965
+ "CVE-2021-39226",
934
966
  "CVE-2022-0492",
967
+ "CVE-2022-40684",
935
968
  "CVE-2023-20867",
936
969
  "CVE-2023-27351",
937
970
  "CVE-2023-28461",
@@ -990,8 +1023,12 @@
990
1023
  "evidence_cves": [
991
1024
  "CVE-2018-19410",
992
1025
  "CVE-2020-24363",
1026
+ "CVE-2021-35587",
993
1027
  "CVE-2021-39144",
1028
+ "CVE-2022-21587",
994
1029
  "CVE-2022-23227",
1030
+ "CVE-2022-24990",
1031
+ "CVE-2022-26501",
995
1032
  "CVE-2023-21839",
996
1033
  "CVE-2023-27532",
997
1034
  "CVE-2023-28461",
@@ -1076,7 +1113,9 @@
1076
1113
  "CAPEC-37"
1077
1114
  ],
1078
1115
  "skills_referencing": [],
1079
- "evidence_cves": [],
1116
+ "evidence_cves": [
1117
+ "CVE-2011-4723"
1118
+ ],
1080
1119
  "framework_controls_partially_addressing": [
1081
1120
  "NIST-800-53-SC-28",
1082
1121
  "ISO-27001-2022-A.8.24",
@@ -1387,6 +1426,7 @@
1387
1426
  "self-update-integrity"
1388
1427
  ],
1389
1428
  "evidence_cves": [
1429
+ "CVE-2022-40139",
1390
1430
  "CVE-2026-32202"
1391
1431
  ],
1392
1432
  "framework_controls_partially_addressing": [
@@ -1467,6 +1507,7 @@
1467
1507
  "CVE-2016-9079",
1468
1508
  "CVE-2019-8526",
1469
1509
  "CVE-2020-9715",
1510
+ "CVE-2021-25370",
1470
1511
  "CVE-2021-25394",
1471
1512
  "CVE-2021-29256",
1472
1513
  "CVE-2022-22071",
@@ -1475,6 +1516,7 @@
1475
1516
  "CVE-2022-38181",
1476
1517
  "CVE-2023-0266",
1477
1518
  "CVE-2023-21608",
1519
+ "CVE-2023-21674",
1478
1520
  "CVE-2023-28205",
1479
1521
  "CVE-2023-29336",
1480
1522
  "CVE-2023-32373",
@@ -1571,6 +1613,7 @@
1571
1613
  "webapp-security"
1572
1614
  ],
1573
1615
  "evidence_cves": [
1616
+ "CVE-2017-11357",
1574
1617
  "CVE-2018-4063",
1575
1618
  "CVE-2021-26828",
1576
1619
  "CVE-2024-39717",
@@ -1657,6 +1700,7 @@
1657
1700
  "CVE-2017-3066",
1658
1701
  "CVE-2018-0824",
1659
1702
  "CVE-2018-15133",
1703
+ "CVE-2018-2628",
1660
1704
  "CVE-2019-0344",
1661
1705
  "CVE-2019-9874",
1662
1706
  "CVE-2019-9875",
@@ -1664,11 +1708,17 @@
1664
1708
  "CVE-2020-14644",
1665
1709
  "CVE-2020-2551",
1666
1710
  "CVE-2020-2883",
1711
+ "CVE-2020-5741",
1712
+ "CVE-2021-31010",
1667
1713
  "CVE-2021-31196",
1668
1714
  "CVE-2021-39144",
1669
1715
  "CVE-2022-1471",
1670
1716
  "CVE-2022-21445",
1671
1717
  "CVE-2022-31199",
1718
+ "CVE-2022-35405",
1719
+ "CVE-2022-41082",
1720
+ "CVE-2022-47986",
1721
+ "CVE-2023-0669",
1672
1722
  "CVE-2023-21529",
1673
1723
  "CVE-2023-21839",
1674
1724
  "CVE-2023-26359",
@@ -1902,7 +1952,8 @@
1902
1952
  "evidence_cves": [
1903
1953
  "BUG-2026-NIGHTMARE-ECLIPSE-GREENPLASMA",
1904
1954
  "BUG-2026-NIGHTMARE-ECLIPSE-UNDEFEND",
1905
- "BUG-2026-NIGHTMARE-ECLIPSE-YELLOWKEY"
1955
+ "BUG-2026-NIGHTMARE-ECLIPSE-YELLOWKEY",
1956
+ "CVE-2018-13374"
1906
1957
  ],
1907
1958
  "framework_controls_partially_addressing": [
1908
1959
  "NIST-800-53-AC-3",
@@ -2001,7 +2052,20 @@
2001
2052
  "CVE-2021-22555",
2002
2053
  "CVE-2021-25372",
2003
2054
  "CVE-2021-30900",
2055
+ "CVE-2021-38406",
2056
+ "CVE-2022-2294",
2057
+ "CVE-2022-32893",
2058
+ "CVE-2022-32894",
2059
+ "CVE-2022-32917",
2060
+ "CVE-2022-37969",
2061
+ "CVE-2022-41073",
2062
+ "CVE-2022-41125",
2063
+ "CVE-2022-41128",
2064
+ "CVE-2022-4135",
2065
+ "CVE-2022-42475",
2066
+ "CVE-2022-42827",
2004
2067
  "CVE-2023-20109",
2068
+ "CVE-2023-23376",
2005
2069
  "CVE-2023-26369",
2006
2070
  "CVE-2023-27997",
2007
2071
  "CVE-2023-28206",
@@ -2086,6 +2150,7 @@
2086
2150
  "evidence_cves": [
2087
2151
  "CVE-2019-6693",
2088
2152
  "CVE-2021-44207",
2153
+ "CVE-2022-28810",
2089
2154
  "CVE-2023-6448",
2090
2155
  "CVE-2024-20439",
2091
2156
  "CVE-2024-28987",
@@ -2166,6 +2231,7 @@
2166
2231
  "webapp-security"
2167
2232
  ],
2168
2233
  "evidence_cves": [
2234
+ "CVE-2021-39226",
2169
2235
  "CVE-2022-0492",
2170
2236
  "CVE-2023-48022",
2171
2237
  "CVE-2023-52163",
@@ -2213,9 +2279,13 @@
2213
2279
  "webapp-security"
2214
2280
  ],
2215
2281
  "evidence_cves": [
2282
+ "CVE-2021-3493",
2216
2283
  "CVE-2021-3560",
2217
2284
  "CVE-2021-40655",
2285
+ "CVE-2022-41091",
2286
+ "CVE-2022-46169",
2218
2287
  "CVE-2023-20269",
2288
+ "CVE-2023-21715",
2219
2289
  "CVE-2023-22518",
2220
2290
  "CVE-2023-24880",
2221
2291
  "CVE-2023-38035",
@@ -2298,6 +2368,8 @@
2298
2368
  "CVE-2021-22175",
2299
2369
  "CVE-2021-39935",
2300
2370
  "CVE-2022-36551",
2371
+ "CVE-2022-41040",
2372
+ "CVE-2022-41080",
2301
2373
  "CVE-2023-41763",
2302
2374
  "CVE-2023-43654",
2303
2375
  "CVE-2023-48022",
@@ -2392,6 +2464,7 @@
2392
2464
  "webapp-security"
2393
2465
  ],
2394
2466
  "evidence_cves": [
2467
+ "CVE-2022-24706",
2395
2468
  "CVE-2023-27524",
2396
2469
  "CVE-2023-6448",
2397
2470
  "CVE-2024-2912",
@@ -2618,6 +2691,7 @@
2618
2691
  ],
2619
2692
  "evidence_cves": [
2620
2693
  "BUG-2026-NIGHTMARE-ECLIPSE-UNDEFEND",
2694
+ "CVE-2020-9934",
2621
2695
  "CVE-2023-32049",
2622
2696
  "CVE-2023-36025",
2623
2697
  "CVE-2023-36584",
@@ -2690,6 +2764,7 @@
2690
2764
  ],
2691
2765
  "related_weaknesses": [],
2692
2766
  "evidence_cves": [
2767
+ "CVE-2020-36193",
2693
2768
  "CVE-2023-36874",
2694
2769
  "CVE-2025-21391",
2695
2770
  "CVE-2025-48384",
@@ -2760,6 +2835,7 @@
2760
2835
  "CVE-2014-3931",
2761
2836
  "CVE-2017-1000253",
2762
2837
  "CVE-2017-6742",
2838
+ "CVE-2018-7445",
2763
2839
  "CVE-2022-22706",
2764
2840
  "CVE-2023-33106",
2765
2841
  "CVE-2023-36033",
@@ -2817,6 +2893,7 @@
2817
2893
  ],
2818
2894
  "related_weaknesses": [],
2819
2895
  "evidence_cves": [
2896
+ "CVE-2013-2597",
2820
2897
  "CVE-2021-27137",
2821
2898
  "CVE-2025-0282",
2822
2899
  "CVE-2025-20352",
@@ -2841,10 +2918,13 @@
2841
2918
  ],
2842
2919
  "related_weaknesses": [],
2843
2920
  "evidence_cves": [
2921
+ "CVE-2011-1823",
2922
+ "CVE-2013-2596",
2844
2923
  "CVE-2018-14634",
2845
2924
  "CVE-2021-30952",
2846
2925
  "CVE-2022-0185",
2847
2926
  "CVE-2023-2136",
2927
+ "CVE-2023-21823",
2848
2928
  "CVE-2023-32434",
2849
2929
  "CVE-2023-33107",
2850
2930
  "CVE-2023-6345",
@@ -2962,6 +3042,8 @@
2962
3042
  "CVE-2025-4427",
2963
3043
  "CVE-2025-57819",
2964
3044
  "CVE-2026-1603",
3045
+ "CVE-2026-18556",
3046
+ "CVE-2026-18577",
2965
3047
  "CVE-2026-23760",
2966
3048
  "CVE-2026-24206",
2967
3049
  "CVE-2026-24207",
@@ -3134,7 +3216,8 @@
3134
3216
  "evidence_cves": [
3135
3217
  "CVE-2019-9621",
3136
3218
  "CVE-2026-21509",
3137
- "CVE-2026-21514"
3219
+ "CVE-2026-21514",
3220
+ "CVE-2026-34486"
3138
3221
  ],
3139
3222
  "last_verified": "2026-05-18",
3140
3223
  "notes": "Added v0.13.17 KEV bulk-import.",
@@ -3179,7 +3262,12 @@
3179
3262
  ],
3180
3263
  "related_weaknesses": [],
3181
3264
  "evidence_cves": [
3265
+ "CVE-2022-3723",
3266
+ "CVE-2022-41033",
3267
+ "CVE-2022-4262",
3268
+ "CVE-2022-42856",
3182
3269
  "CVE-2023-2033",
3270
+ "CVE-2023-23529",
3183
3271
  "CVE-2023-3079",
3184
3272
  "CVE-2023-32439",
3185
3273
  "CVE-2023-4762",
@@ -3311,8 +3399,11 @@
3311
3399
  ],
3312
3400
  "related_weaknesses": [],
3313
3401
  "evidence_cves": [
3402
+ "CVE-2020-28949",
3314
3403
  "CVE-2021-38371",
3404
+ "CVE-2022-35914",
3315
3405
  "CVE-2022-43769",
3406
+ "CVE-2022-46169",
3316
3407
  "CVE-2023-22527",
3317
3408
  "CVE-2025-20281",
3318
3409
  "CVE-2025-20337"
@@ -3335,6 +3426,7 @@
3335
3426
  "related_weaknesses": [],
3336
3427
  "evidence_cves": [
3337
3428
  "CVE-2009-3459",
3429
+ "CVE-2023-23376",
3338
3430
  "CVE-2023-27997",
3339
3431
  "CVE-2023-28252",
3340
3432
  "CVE-2023-36036",
@@ -3404,6 +3496,7 @@
3404
3496
  ],
3405
3497
  "related_weaknesses": [],
3406
3498
  "evidence_cves": [
3499
+ "CVE-2022-24112",
3407
3500
  "CVE-2023-50224",
3408
3501
  "CVE-2024-4358",
3409
3502
  "CVE-2024-54085"
@@ -3697,6 +3790,9 @@
3697
3790
  ],
3698
3791
  "related_weaknesses": [],
3699
3792
  "evidence_cves": [
3793
+ "CVE-2010-2568",
3794
+ "CVE-2020-3153",
3795
+ "CVE-2020-3433",
3700
3796
  "MAL-2026-MOIKA-DEPCONFUSION"
3701
3797
  ],
3702
3798
  "last_verified": "2026-05-19",
@@ -3737,6 +3833,7 @@
3737
3833
  ],
3738
3834
  "related_weaknesses": [],
3739
3835
  "evidence_cves": [
3836
+ "CVE-2022-22536",
3740
3837
  "CVE-2023-41265",
3741
3838
  "CVE-2023-48365"
3742
3839
  ],
@@ -4106,7 +4203,9 @@
4106
4203
  "CWE-2000"
4107
4204
  ],
4108
4205
  "related_weaknesses": [],
4109
- "evidence_cves": [],
4206
+ "evidence_cves": [
4207
+ "CVE-2022-40139"
4208
+ ],
4110
4209
  "last_verified": "2026-05-19",
4111
4210
  "notes": "Bulk-imported v0.13.18 from the canonical MITRE Top 25 + commonly-referenced-class expansion.",
4112
4211
  "_auto_imported": true,
@@ -4203,7 +4302,9 @@
4203
4302
  "CWE-2000"
4204
4303
  ],
4205
4304
  "related_weaknesses": [],
4206
- "evidence_cves": [],
4305
+ "evidence_cves": [
4306
+ "CVE-2018-19322"
4307
+ ],
4207
4308
  "last_verified": "2026-05-19",
4208
4309
  "notes": "Bulk-imported v0.13.18 from the canonical MITRE Top 25 + commonly-referenced-class expansion.",
4209
4310
  "_auto_imported": true,
@@ -4247,6 +4348,7 @@
4247
4348
  ],
4248
4349
  "related_weaknesses": [],
4249
4350
  "evidence_cves": [
4351
+ "CVE-2022-44698",
4250
4352
  "CVE-2024-29748"
4251
4353
  ],
4252
4354
  "last_verified": "2026-05-19",
@@ -4482,7 +4584,8 @@
4482
4584
  ],
4483
4585
  "related_weaknesses": [],
4484
4586
  "evidence_cves": [
4485
- "CVE-2021-45046"
4587
+ "CVE-2021-45046",
4588
+ "CVE-2022-22963"
4486
4589
  ],
4487
4590
  "last_verified": "2026-05-19",
4488
4591
  "notes": "Bulk-imported v0.13.18 from the canonical MITRE Top 25 + commonly-referenced-class expansion.",
@@ -5512,6 +5615,7 @@
5512
5615
  "related_attack_patterns_capec": [],
5513
5616
  "skills_referencing": [],
5514
5617
  "evidence_cves": [
5618
+ "CVE-2022-27593",
5515
5619
  "CVE-2025-0111"
5516
5620
  ]
5517
5621
  },
@@ -6071,6 +6175,7 @@
6071
6175
  ],
6072
6176
  "skills_referencing": [],
6073
6177
  "evidence_cves": [
6178
+ "CVE-2022-26923",
6074
6179
  "CVE-2023-20963",
6075
6180
  "CVE-2023-41991"
6076
6181
  ],
@@ -6150,6 +6255,7 @@
6150
6255
  "related_attack_patterns_capec": [],
6151
6256
  "skills_referencing": [],
6152
6257
  "evidence_cves": [
6258
+ "CVE-2021-25370",
6153
6259
  "CVE-2021-25372",
6154
6260
  "CVE-2022-22265"
6155
6261
  ],
@@ -6248,5 +6354,361 @@
6248
6354
  "real_requirement": "Replay-resistant authentication (channel binding, per-message nonces/timestamps, signed challenge-response) and blocking outbound authentication to untrusted hosts, so a captured authenticator cannot be relayed — password rotation and account lockout do not address a protocol that accepts a replayed credential.",
6249
6355
  "lag_notes": "IA-2 identification-and-authentication and A.5.15 access-control assume the authenticator is secret; they do not mandate the channel binding or egress control that stops a coerced NTLM authentication from being relayed, which is the actual exploited path.",
6250
6356
  "last_verified": "2026-07-29"
6357
+ },
6358
+ "CWE-197": {
6359
+ "id": "CWE-197",
6360
+ "name": "Numeric Truncation Error",
6361
+ "abstraction": "Base",
6362
+ "category": "Numeric Errors",
6363
+ "description": "A primitive is cast to a primitive of smaller size and the high-order bits are lost in the conversion, so the resulting value no longer equals the original. When the truncated value is then used as a length, an index or a loop bound, the code operates on a size the caller never intended — the classic route from an attacker-supplied 64-bit length to a small allocation followed by a full-size copy.",
6364
+ "top_25_rank_2024": null,
6365
+ "top_25_rank_2025": null,
6366
+ "view_memberships": [
6367
+ "CWE-1000",
6368
+ "CWE-1305",
6369
+ "CWE-1340"
6370
+ ],
6371
+ "related_attack_patterns_capec": [],
6372
+ "evidence_cves": [
6373
+ "CVE-2022-42475"
6374
+ ],
6375
+ "framework_controls_partially_addressing": [
6376
+ "NIST-800-53-SI-10",
6377
+ "NIST-800-53-SI-16",
6378
+ "ISO-27001-2022-A.8.28"
6379
+ ],
6380
+ "real_requirement": "Truncation is a property of the type system, not of input validation: SI-10 validates the value a caller supplies, but the loss happens after validation when the checked 64-bit quantity is narrowed. Closing it requires compiler-enforced conversion checks (-fsanitize=implicit-conversion, Rust's TryFrom over `as`) and a rule that no width-narrowing cast may reach an allocation size or an index without an explicit range check at the cast site.",
6381
+ "lag_notes": "Every framework in scope treats this as an input-validation control, which is the wrong layer — the value that reaches the allocator passed validation and was corrupted afterwards. No control in NIST 800-53, ISO 27001:2022 or the Essential Eight asks whether narrowing conversions are checked at all.",
6382
+ "last_verified": "2026-08-06"
6383
+ },
6384
+ "CWE-259": {
6385
+ "id": "CWE-259",
6386
+ "name": "Use of Hard-coded Password",
6387
+ "abstraction": "Variant",
6388
+ "category": "Credentials Management",
6389
+ "description": "The product ships a password embedded in its own code or configuration and uses it for inbound authentication or for outbound connections to another component. Because the credential is identical on every installation, recovering it once from a single device, firmware image or decompiled binary yields access to the entire installed base, and an operator cannot revoke it without a vendor fix.",
6390
+ "top_25_rank_2024": null,
6391
+ "top_25_rank_2025": null,
6392
+ "view_memberships": [
6393
+ "CWE-1000",
6394
+ "CWE-1008",
6395
+ "CWE-1305",
6396
+ "CWE-1340"
6397
+ ],
6398
+ "related_attack_patterns_capec": [
6399
+ "CAPEC-191",
6400
+ "CAPEC-70"
6401
+ ],
6402
+ "evidence_cves": [
6403
+ "CVE-2026-20316"
6404
+ ],
6405
+ "framework_controls_partially_addressing": [
6406
+ "NIST-800-53-IA-5",
6407
+ "NIST-800-53-CM-6",
6408
+ "ISO-27001-2022-A.5.17",
6409
+ "NIS2-Art21-access-control"
6410
+ ],
6411
+ "real_requirement": "IA-5 authenticator management governs credentials the operator controls; a password compiled into the vendor's binary is outside that boundary entirely — there is no rotation interval, no complexity policy and no revocation path an operator can exercise. The real requirement is a procurement and attestation control: vendors must attest that no static shared secret exists in shipped firmware, and buyers must be able to verify it by extracting and scanning the image.",
6412
+ "lag_notes": "Credential-management controls are written for credentials the operator issues. A hard-coded vendor password satisfies none of their preconditions and is invisible to every password-policy audit, so an environment can pass IA-5 and A.5.17 in full while every appliance on the network shares one unchangeable password.",
6413
+ "last_verified": "2026-08-06"
6414
+ },
6415
+ "CWE-270": {
6416
+ "id": "CWE-270",
6417
+ "name": "Privilege Context Switching Error",
6418
+ "abstraction": "Base",
6419
+ "category": "Privilege Management",
6420
+ "description": "The product fails to manage privileges correctly while moving between contexts with different privilege levels or spheres of control. The dangerous shape is a partial transition: some component of the security context is switched and another is not, so an operation that appears to run as the unprivileged caller still carries privileged state — the pattern behind namespace and impersonation escapes where a capability set or a device map survives a context change.",
6421
+ "top_25_rank_2024": null,
6422
+ "top_25_rank_2025": null,
6423
+ "view_memberships": [
6424
+ "CWE-1000",
6425
+ "CWE-699",
6426
+ "CWE-1008"
6427
+ ],
6428
+ "related_attack_patterns_capec": [
6429
+ "CAPEC-17",
6430
+ "CAPEC-30",
6431
+ "CAPEC-35"
6432
+ ],
6433
+ "evidence_cves": [
6434
+ "CVE-2021-3493"
6435
+ ],
6436
+ "framework_controls_partially_addressing": [
6437
+ "NIST-800-53-AC-6",
6438
+ "NIST-800-53-AC-3",
6439
+ "ISO-27001-2022-A.8.2",
6440
+ "UK-CAF-B2"
6441
+ ],
6442
+ "real_requirement": "Least privilege assumes the privilege boundary holds; this weakness is the boundary itself failing mid-transition, so AC-6 cannot detect or contain it. What is required is kernel-level enforcement that a context switch is atomic across every element of the security context — credentials, capability set, namespace, device map — plus unprivileged-namespace restrictions (kernel.unprivileged_userns_clone=0, sysctl-enforced) where the product exposes one.",
6443
+ "lag_notes": "Privileged-access controls are written about who holds privilege, never about whether a transition between privilege contexts is atomic. An environment with textbook AC-6 and A.8.2 implementation is fully exposed, because the exploit begins from an ordinary unprivileged account by design.",
6444
+ "last_verified": "2026-08-06"
6445
+ },
6446
+ "CWE-311": {
6447
+ "id": "CWE-311",
6448
+ "name": "Missing Encryption of Sensitive Data",
6449
+ "abstraction": "Class",
6450
+ "category": "Cryptography",
6451
+ "description": "The product stores or transmits sensitive information without encrypting it. The recurring failure is not an absent cipher suite but a path that bypasses one — a management channel, a replication link or an internal API that predates the product's TLS support and stays in cleartext by default while the operator-facing configuration reports encryption as enabled.",
6452
+ "top_25_rank_2024": null,
6453
+ "top_25_rank_2025": null,
6454
+ "view_memberships": [
6455
+ "CWE-1000",
6456
+ "CWE-1003",
6457
+ "CWE-1008"
6458
+ ],
6459
+ "related_attack_patterns_capec": [
6460
+ "CAPEC-157",
6461
+ "CAPEC-158",
6462
+ "CAPEC-204",
6463
+ "CAPEC-31",
6464
+ "CAPEC-37",
6465
+ "CAPEC-383",
6466
+ "CAPEC-384",
6467
+ "CAPEC-385"
6468
+ ],
6469
+ "evidence_cves": [
6470
+ "CVE-2026-34486"
6471
+ ],
6472
+ "framework_controls_partially_addressing": [
6473
+ "NIST-800-53-SC-8",
6474
+ "NIST-800-53-SC-28",
6475
+ "ISO-27001-2022-A.8.24",
6476
+ "NIS2-Art21-cryptography",
6477
+ "AU-Essential-8-Restrict-Admin"
6478
+ ],
6479
+ "real_requirement": "SC-8 and A.8.24 are satisfied by a policy that says traffic is encrypted; neither requires evidence that every listener actually negotiates it. The test that distinguishes paper compliance from the real control is an on-the-wire one: enumerate the product's listening ports, capture each channel and confirm no plaintext credential or session token appears — including the internal and clustering channels the vendor documentation treats as trusted.",
6480
+ "lag_notes": "Cryptography controls are audited from configuration, and configuration reports the channels the product chose to expose. A cleartext internal channel is invisible to that audit, which is why this class keeps surfacing in products whose operators hold a current certification.",
6481
+ "last_verified": "2026-08-06"
6482
+ },
6483
+ "CWE-406": {
6484
+ "id": "CWE-406",
6485
+ "name": "Insufficient Control of Network Message Volume (Network Amplification)",
6486
+ "abstraction": "Class",
6487
+ "category": "Network",
6488
+ "description": "The product does not adequately monitor or bound the volume of traffic it transmits, so an actor can induce it to emit far more traffic than the request warranted. Exploitation costs the attacker almost nothing and spends the victim's egress bandwidth and reputation: the vulnerable host becomes the reflector, and the traffic that reaches the target carries the reflector's own source address.",
6489
+ "top_25_rank_2024": null,
6490
+ "top_25_rank_2025": null,
6491
+ "view_memberships": [
6492
+ "CWE-1000"
6493
+ ],
6494
+ "related_attack_patterns_capec": [
6495
+ "CAPEC-490",
6496
+ "CAPEC-486"
6497
+ ],
6498
+ "evidence_cves": [
6499
+ "CVE-2022-0028"
6500
+ ],
6501
+ "framework_controls_partially_addressing": [
6502
+ "NIST-800-53-SC-5",
6503
+ "NIST-800-53-SC-7",
6504
+ "ISO-27001-2022-A.8.20",
6505
+ "NIS2-Art21-business-continuity",
6506
+ "UK-CAF-B4"
6507
+ ],
6508
+ "real_requirement": "SC-5 denial-of-service protection is written to keep an organisation's own services available; it says nothing about the organisation becoming the source of someone else's outage. The control that matters here is egress-side: per-source rate limiting on any service that answers more bytes than it receives, BCP 38 anti-spoofing filtering at the network edge, and monitoring that alerts on outbound volume asymmetry rather than inbound.",
6509
+ "lag_notes": "Availability controls across NIST, ISO and NIS2 are uniformly inbound-facing. An organisation whose appliance is reflecting an attack suffers no availability impact of its own, so nothing in its control set fires — the harm lands entirely on a third party and is detected only when an upstream provider complains.",
6510
+ "last_verified": "2026-08-06"
6511
+ },
6512
+ "CWE-664": {
6513
+ "id": "CWE-664",
6514
+ "name": "Improper Control of a Resource Through its Lifetime",
6515
+ "abstraction": "Pillar",
6516
+ "category": "Resource Management",
6517
+ "description": "The product does not maintain correct control over a resource across creation, use and release. As a Pillar it is the root of the use-after-free, double-free, uninitialised-use and session-lifetime families; CNAs reach for it when the concrete lifecycle error is known to be real but the vendor has not published the detail needed to name a Base weakness.",
6518
+ "top_25_rank_2024": null,
6519
+ "top_25_rank_2025": null,
6520
+ "view_memberships": [
6521
+ "CWE-1000"
6522
+ ],
6523
+ "related_attack_patterns_capec": [
6524
+ "CAPEC-196",
6525
+ "CAPEC-21",
6526
+ "CAPEC-60",
6527
+ "CAPEC-61",
6528
+ "CAPEC-62"
6529
+ ],
6530
+ "evidence_cves": [
6531
+ "CVE-2022-27518"
6532
+ ],
6533
+ "framework_controls_partially_addressing": [
6534
+ "NIST-800-53-SI-2",
6535
+ "NIST-800-53-SC-4",
6536
+ "ISO-27001-2022-A.8.28",
6537
+ "ISO-27001-2022-A.5.15"
6538
+ ],
6539
+ "real_requirement": "A Pillar-level assignment carries an operational cost the frameworks do not price: with no Base weakness named, defenders cannot pattern-match the flaw against their own code or build a targeted detection, so remediation collapses to 'apply the vendor patch'. The requirement is disclosure quality — CNAs publishing a lifecycle bug should name the concrete weakness once exploitation has ceased, so downstream variant analysis becomes possible.",
6540
+ "lag_notes": "Vulnerability-management controls measure time-to-patch and are indifferent to whether the advisory says anything useful. An entry mapped only at Pillar level passes every A.8.8 and SI-2 process check while leaving defenders unable to hunt for the same pattern in adjacent code.",
6541
+ "last_verified": "2026-08-06"
6542
+ },
6543
+ "CWE-824": {
6544
+ "id": "CWE-824",
6545
+ "name": "Access of Uninitialized Pointer",
6546
+ "abstraction": "Base",
6547
+ "category": "Memory Safety",
6548
+ "description": "The product reads or writes through a pointer that was never initialised. The stored value is whatever the allocation happened to contain, so the access lands at an address the developer never chose — a read or write to arbitrary memory, or, when the pointer is used for an indirect call, transfer of control to an address an attacker who can shape the surrounding allocation gets to pick.",
6549
+ "top_25_rank_2024": null,
6550
+ "top_25_rank_2025": null,
6551
+ "view_memberships": [
6552
+ "CWE-1000",
6553
+ "CWE-699",
6554
+ "CWE-1003",
6555
+ "CWE-1305",
6556
+ "CWE-1340"
6557
+ ],
6558
+ "related_attack_patterns_capec": [],
6559
+ "evidence_cves": [
6560
+ "CVE-2022-21971"
6561
+ ],
6562
+ "framework_controls_partially_addressing": [
6563
+ "NIST-800-53-SI-16",
6564
+ "NIST-800-53-SI-2",
6565
+ "ISO-27001-2022-A.8.28",
6566
+ "UK-CAF-B4"
6567
+ ],
6568
+ "real_requirement": "SI-16 memory protection is read as 'enable the platform mitigations', and this weakness defeats that reading: ASLR does not help when the stale value is a heap address the attacker groomed, and Control Flow Guard constrains an indirect call only to valid call targets, not to the intended one. What closes it is memory-safe language adoption for new code plus MSAN/UBSAN in continuous fuzzing for legacy C, where an uninitialised read is caught at test time rather than exploited at runtime.",
6569
+ "lag_notes": "Memory-protection controls enumerate mitigations rather than requiring the class of bug be absent, so a fully hardened build with every mitigation enabled remains exploitable. No framework in scope requires uninitialised-memory sanitizers in the build pipeline.",
6570
+ "last_verified": "2026-08-06"
6571
+ },
6572
+ "CWE-1285": {
6573
+ "id": "CWE-1285",
6574
+ "name": "Improper Validation of Specified Index, Position, or Offset in Input",
6575
+ "abstraction": "Base",
6576
+ "category": "Validation",
6577
+ "description": "The product accepts an index, position or offset from input and uses it to select an element without confirming it falls inside the target structure. Signed inputs make it worse: validating only the upper bound leaves a negative value to index below the start of the array, which is how several kernel privilege escalations turned an ordinary syscall argument into an arbitrary write.",
6578
+ "top_25_rank_2024": null,
6579
+ "top_25_rank_2025": null,
6580
+ "view_memberships": [
6581
+ "CWE-1000",
6582
+ "CWE-699"
6583
+ ],
6584
+ "related_attack_patterns_capec": [],
6585
+ "evidence_cves": [
6586
+ "CVE-2013-2094"
6587
+ ],
6588
+ "framework_controls_partially_addressing": [
6589
+ "NIST-800-53-SI-10",
6590
+ "NIST-800-53-SI-16",
6591
+ "ISO-27001-2022-A.8.28",
6592
+ "AU-ISM-1546"
6593
+ ],
6594
+ "real_requirement": "SI-10 input validation is the control operators point at, and it is satisfied by a bounds check — including a check that only tests one end of the range. The requirement that actually holds is a two-sided one enforced structurally: index types that cannot be negative, checked indexing in the language rather than in the developer's memory, and fuzzing that drives negative and boundary values into every syscall and API argument used as an index.",
6595
+ "lag_notes": "Framework input-validation language never distinguishes a complete bounds check from a partial one, so code with a validated-but-one-sided index passes review and audit. The signed-index variant in particular has recurred across a decade of kernel CVEs without any control set naming it.",
6596
+ "last_verified": "2026-08-06"
6597
+ },
6598
+ "CWE-441": {
6599
+ "id": "CWE-441",
6600
+ "name": "Unintended Proxy or Intermediary (Confused Deputy)",
6601
+ "abstraction": "Class",
6602
+ "category": "Access Control",
6603
+ "description": "The product forwards a request from an upstream caller to an external actor without preserving the original source, so the request arrives carrying the product's own identity and reach rather than the caller's. Anything the product is trusted to do becomes reachable by whoever can get a request into it — the confused-deputy shape behind server-side request forgery, and behind internal servlets that will fetch or return whatever an unauthenticated caller names.",
6604
+ "top_25_rank_2024": null,
6605
+ "top_25_rank_2025": null,
6606
+ "view_memberships": [
6607
+ "CWE-1000",
6608
+ "CWE-1008",
6609
+ "CWE-1194"
6610
+ ],
6611
+ "related_attack_patterns_capec": [
6612
+ "CAPEC-219",
6613
+ "CAPEC-465"
6614
+ ],
6615
+ "evidence_cves": [
6616
+ "CVE-2022-36537"
6617
+ ],
6618
+ "framework_controls_partially_addressing": [
6619
+ "NIST-800-53-AC-4",
6620
+ "NIST-800-53-SC-7",
6621
+ "ISO-27001-2022-A.8.22",
6622
+ "NIS2-Art21-network-security"
6623
+ ],
6624
+ "real_requirement": "Boundary controls decide what may cross the perimeter, and the deputy is already inside it — AC-4 and SC-7 see a request the trusted component itself originated. What is required is identity propagation across the hop: the downstream component must authorise the ORIGINAL principal rather than the intermediary, and any component permitted to make outbound requests on a caller's behalf needs an explicit destination allowlist rather than a filter on where the request appears to come from.",
6625
+ "lag_notes": "Every network-boundary control in scope reasons about source and destination addresses. A confused deputy changes neither: the traffic is the trusted component making a request it is allowed to make. Segmentation, egress filtering and flow-control policy can all be fully implemented and none of them fires.",
6626
+ "last_verified": "2026-08-06"
6627
+ },
6628
+ "CWE-274": {
6629
+ "id": "CWE-274",
6630
+ "name": "Improper Handling of Insufficient Privileges",
6631
+ "abstraction": "Base",
6632
+ "category": "Privilege Management",
6633
+ "description": "The product does not correctly handle the case where it lacks the privilege to complete an operation. The security-relevant shape is a failure that is silently tolerated: a labelling, logging or marking step is denied, the product proceeds as though it had succeeded, and the artifact it produces is missing the protection the operator believes is attached to it.",
6634
+ "top_25_rank_2024": null,
6635
+ "top_25_rank_2025": null,
6636
+ "view_memberships": [
6637
+ "CWE-1000",
6638
+ "CWE-699",
6639
+ "CWE-1008"
6640
+ ],
6641
+ "related_attack_patterns_capec": [],
6642
+ "evidence_cves": [
6643
+ "CVE-2022-41049"
6644
+ ],
6645
+ "framework_controls_partially_addressing": [
6646
+ "NIST-800-53-SI-11",
6647
+ "NIST-800-53-AC-3",
6648
+ "ISO-27001-2022-A.8.28",
6649
+ "UK-CAF-B4"
6650
+ ],
6651
+ "real_requirement": "SI-11 asks that errors be handled, which a swallowed permission failure technically satisfies. The requirement that matters is fail-closed semantics on any operation that applies a security marking: if the marking cannot be written, the operation depending on it must not report success, and the failure must reach the operator rather than be absorbed.",
6652
+ "lag_notes": "Error-handling controls are audited for whether errors are caught, never for what the code does after catching one. A product that catches an access-denied result and continues passes every review while producing output that silently lacks its security attribute.",
6653
+ "last_verified": "2026-08-06"
6654
+ },
6655
+ "CWE-138": {
6656
+ "id": "CWE-138",
6657
+ "name": "Improper Neutralization of Special Elements",
6658
+ "abstraction": "Class",
6659
+ "category": "Injection",
6660
+ "description": "The product accepts input from an upstream component and passes it downstream without neutralizing elements the downstream component reads as control syntax rather than data. It is the parent shape of the injection family: the bytes are inert where they are validated and become syntax where they are used, so a value that passed one component's check changes meaning inside the next.",
6661
+ "top_25_rank_2024": null,
6662
+ "top_25_rank_2025": null,
6663
+ "view_memberships": [
6664
+ "CWE-1000",
6665
+ "CWE-1008"
6666
+ ],
6667
+ "related_attack_patterns_capec": [
6668
+ "CAPEC-105",
6669
+ "CAPEC-15",
6670
+ "CAPEC-34"
6671
+ ],
6672
+ "evidence_cves": [
6673
+ "CVE-2022-26352"
6674
+ ],
6675
+ "framework_controls_partially_addressing": [
6676
+ "NIST-800-53-SI-10",
6677
+ "NIST-800-53-SI-15",
6678
+ "ISO-27001-2022-A.8.28",
6679
+ "AU-ISM-1546"
6680
+ ],
6681
+ "real_requirement": "SI-10 validates input against the format the receiving component expects, which is the wrong boundary — the reinterpretation happens at the next hop. The requirement is contextual output encoding at each boundary the value crosses, plus parser-level separation of data from control (parameterised APIs, structured builders) so a value can never be promoted to syntax by concatenation.",
6682
+ "lag_notes": "Framework language treats input validation as a single gate at the system edge. Multi-hop products re-interpret the same value under several grammars, and no control in NIST, ISO or the ISM asks for an encoding decision at each of those transitions.",
6683
+ "last_verified": "2026-08-06"
6684
+ },
6685
+ "CWE-782": {
6686
+ "id": "CWE-782",
6687
+ "name": "Exposed IOCTL with Insufficient Access Control",
6688
+ "abstraction": "Variant",
6689
+ "category": "Access Control",
6690
+ "description": "A driver exposes privileged functionality through an IOCTL without enforcing access control on the caller. Where the exposed primitive is a physical-memory or MSR read/write, any process able to open the device gets a kernel read-write primitive with no memory-safety bug involved anywhere — the basis of bring-your-own-vulnerable-driver, in which a signed driver is installed deliberately for the primitive it hands out.",
6691
+ "top_25_rank_2024": null,
6692
+ "top_25_rank_2025": null,
6693
+ "view_memberships": [
6694
+ "CWE-1000",
6695
+ "CWE-1008"
6696
+ ],
6697
+ "related_attack_patterns_capec": [],
6698
+ "evidence_cves": [
6699
+ "CVE-2018-19320",
6700
+ "CVE-2018-19321",
6701
+ "CVE-2018-19323"
6702
+ ],
6703
+ "framework_controls_partially_addressing": [
6704
+ "NIST-800-53-SI-7",
6705
+ "NIST-800-53-CM-7",
6706
+ "ISO-27001-2022-A.8.19",
6707
+ "AU-Essential-8-App-Control",
6708
+ "UK-CAF-B4"
6709
+ ],
6710
+ "real_requirement": "Software-integrity and application-control policy answer whether a driver is validly signed, and a vulnerable driver is: the vendor signed it, the signature verifies, and code integrity admits it. What closes this is a blocklist enforced in the kernel — the Microsoft vulnerable-driver blocklist with HVCI, or an equivalent allowlist of driver hashes — together with a rule that a driver exposing a privilege-boundary IOCTL must itself check the caller's identity.",
6711
+ "lag_notes": "Application control and integrity verification are written around provenance, not capability. Every framework in scope passes a correctly signed driver that hands arbitrary physical-memory access to any local process, and none requires enumerating what a loaded driver exposes.",
6712
+ "last_verified": "2026-08-06"
6251
6713
  }
6252
6714
  }