@blamejs/exceptd-skills 0.19.29 → 0.19.30

package/data/attack-techniques.json

@@ -735,9 +735,11 @@
       "CVE-2022-0185",
       "CVE-2022-0492",
       "CVE-2022-0847",
+      "CVE-2022-21919",
       "CVE-2022-22047",
       "CVE-2022-22071",
       "CVE-2022-22265",
+      "CVE-2022-22674",
       "CVE-2022-22675",
       "CVE-2022-22706",
       "CVE-2022-22718",
@@ -1415,6 +1417,7 @@
       "CVE-2008-4250",
       "CVE-2010-0738",
       "CVE-2010-1428",
+      "CVE-2010-5330",
       "CVE-2013-3993",
       "CVE-2014-0160",
       "CVE-2014-0780",
@@ -5070,7 +5073,8 @@
       "CVE-2016-3351",
       "CVE-2016-4655",
       "CVE-2019-0703",
-      "CVE-2021-26085"
+      "CVE-2021-26085",
+      "CVE-2022-22674"
     ]
   },
   "T1083": {
@@ -6131,6 +6135,7 @@
       "CVE-2021-25370",
       "CVE-2021-30883",
       "CVE-2021-31010",
+      "CVE-2022-22674",
       "CVE-2022-22675",
       "CVE-2022-32894",
       "CVE-2022-4135",
@@ -6685,6 +6690,7 @@
       "CVE-2021-3560",
       "CVE-2021-4034",
       "CVE-2022-0847",
+      "CVE-2022-21919",
       "CVE-2026-48172"
     ]
   },
@@ -10499,6 +10505,7 @@
     "_intake_method": "mitre-attack-stix",
     "cve_refs": [
       "CVE-2007-3010",
+      "CVE-2010-5330",
       "CVE-2017-15944",
       "CVE-2017-8291",
       "CVE-2018-10562",
@@ -17483,6 +17490,7 @@
       "CVE-2012-1854",
       "CVE-2020-3153",
       "CVE-2020-3433",
+      "CVE-2022-21919",
       "CVE-2022-26904",
       "CVE-2022-41073"
     ]

package/data/cve-catalog.json

@@ -93,6 +93,358 @@
     },
     "last_threat_review": "2026-05-30"
   },
+  "CVE-2010-5330": {
+    "name": "Ubiquiti AirOS Command Injection Vulnerability",
+    "cvss_score": 9.8,
+    "cvss_vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
+    "cwe_refs": [
+      "CWE-77"
+    ],
+    "cisa_kev": true,
+    "cisa_kev_date": "2022-04-15",
+    "cisa_kev_due_date": "2022-05-06",
+    "known_ransomware_use": false,
+    "active_exploitation": "confirmed",
+    "complexity": "low",
+    "vector": "AirOS serves stainfo.cgi — the 'Show AP info' link under Extra Information on the radio's main page — and passes its ifname query parameter into a shell command that interrogates the named radio interface without sanitizing it, so a semicolon and a second command in that parameter execute on the device. No credential gates that path: Ubiquiti's own advisory for this flaw, dated 2011-12-19 and tagged Vendor Advisory and Patch by NVD, states it 'may grant remote users administrative access to Ubiquiti equipment running AirOS v3/4 and AirOS v5 without requiring authentication' and describes 'a vulnerability with the http server, allowing users to bypass authentication and run commands'; the source-level fix the vendor published for SDK builders in the same thread is named lighttpd-mod-airos-exploit-fix.patch. NVD scores it AV:N/AC:L/PR:N/UI:N accordingly. The published request is GET /stainfo.cgi?ifname=eth0;cat%20/tmp/system.cfg|grep%20users, which returns the running configuration block holding the administrative account entry: the first request reads out the radio's own admin credential, and every request after that is arbitrary command execution on a device sitting in the middle of the wireless path.",
+    "epss_score": 0.34641,
+    "epss_percentile": 0.98283,
+    "epss_date": "2026-08-16",
+    "epss_source": "https://api.first.org/data/v1/epss?cve=CVE-2010-5330",
+    "vendor_advisories": [
+      {
+        "vendor": "Ubiquiti",
+        "advisory_id": "212974",
+        "url": "https://community.ubnt.com/t5/airMAX-General-Discussion/AirOS-Security-Exploit-Updated-Firmware/td-p/212974",
+        "severity": "unknown",
+        "published_date": null
+      }
+    ],
+    "verification_sources": [
+      "https://nvd.nist.gov/vuln/detail/CVE-2010-5330",
+      "https://www.cisa.gov/known-exploited-vulnerabilities-catalog",
+      "https://community.ubnt.com/t5/airMAX-General-Discussion/AirOS-Security-Exploit-Updated-Firmware/td-p/212974"
+    ],
+    "source_verified": "2026-08-18",
+    "last_updated": "2026-08-18",
+    "_kev_short_description": "Certain Ubiquiti devices contain a command injection vulnerability via a GET request to stainfo.cgi.",
+    "type": "preauth-cgi-command-injection-rce",
+    "blast_radius": 22,
+    "poc_available": true,
+    "poc_description": "Exploit-DB 14146 — 'Ubiquity Nanostation5 (Air OS) 0day Remote Command Execution', published 2010-06-30 by Emanuele 'emgent' Gentili — carries the working request http://router_ip/stainfo.cgi?ifname=eth0;cat%20/tmp/system.cfg|grep%20users, and NVD cites it as a third-party advisory reference for this CVE. Nothing else public was resolved: searching rapid7/metasploit-framework for CVE-2010-5330 returns no module, and ProjectDiscovery ships no Nuclei template for it. The single Exploit-DB entry is the whole public artefact, and it is sufficient, because the exploit is one URL that needs no tooling to fire.",
+    "iocs": {
+      "behavioral": [
+        "A radio's configuration or administrative password changing outside a change window, or an administrative session succeeding from an address that has never managed that unit before — the expected sequel to a credential read out of /tmp/system.cfg",
+        "Unexpected processes or outbound connections from a radio that should only originate management, NTP and monitoring traffic; on a backhaul unit, any egress to an address outside the operator's own ranges",
+        "Sequential GET requests to the same CGI path across many radios in the fleet from one source address, which is the shape of an operator-wide sweep rather than of a technician using the AP-info page",
+        "An AirOS radio initiating HTTP connections to other radios' management interfaces rather than only answering them — Ubiquiti documented a worm that spread itself through this flaw, and a self-propagating infection issues its next request from the radio it already holds"
+      ],
+      "indicators": [
+        "admin.cgi renamed to adm.cgi on the radio — visible in the browser after logging in, and the first artefact Ubiquiti published for the worm that spread through this flaw",
+        "/etc/persistent/.skynet and /etc/persistent/rc.poststart present on the radio (ls -la /etc/persistent) — the worm's persistence, which the vendor's own removal steps delete before cfgmtd -w -p /etc/ and a reboot",
+        "HTTP requests to /stainfo.cgi whose ifname parameter contains a shell metacharacter — ; | ` or $( — rather than a bare interface name such as eth0 or ath0",
+        "Responses to /stainfo.cgi containing configuration text from /tmp/system.cfg, particularly lines from the users block, where the AP-info page would normally return only station statistics",
+        "The AirOS HTTP or HTTPS management interface answering on the wireless-facing or subscriber-facing address rather than on a management-only address",
+        "An AirOS build below v4.0.1 on the 802.11 line, below v5.3.5 on the airMAX line, or below v5.4.5 on AirSync — the reported firmware version is itself the exposure marker"
+      ],
+      "_ioc_source_note": "The worm artefacts — the admin.cgi-to-adm.cgi rename, /etc/persistent/.skynet, /etc/persistent/rc.poststart and the cfgmtd removal sequence — are quoted from Ubiquiti's own advisory 'AirOS Security Exploit -- Updated Firmware' (community.ubnt.com thread 212974, tagged Vendor Advisory and Patch on the NVD record), read at http://web.archive.org/web/20160923171316/http://community.ubnt.com/t5/airMAX-General-Discussion/AirOS-Security-Exploit-Updated-Firmware/m-p/212974. The request path, the unsanitized ifname parameter and the /tmp/system.cfg users-block read are taken from Exploit-DB 14146, 'Ubiquity Nanostation5 (Air OS) 0day Remote Command Execution' by Emanuele 'emgent' Gentili, 2010-06-30 (https://www.exploit-db.com/exploits/14146), also an NVD reference for this CVE; the fixed firmware levels used as exposure markers are from https://nvd.nist.gov/vuln/detail/CVE-2010-5330. No indicator here is an invented exploit signature — each is a vendor-published artefact, the published request shape, or a version-exposure marker."
+    },
+    "ai_discovered": false,
+    "ai_discovery_notes": "Emanuele 'emgent' Gentili published the stainfo.cgi command execution on Exploit-DB as entry 14146, dated 2010-06-30; that write-up says only that 'after some mail with Ubnt QA and Security Team people, the fixed firmware was released', and gives no date or version for it. Ubiquiti's airMAX post 'AirOS Security Exploit -- Updated Firmware', which NVD tags as this CVE's vendor advisory and patch reference, is dated 2011-12-19, opens 'Today we have discovered a vulnerability', and sits at the head of a thread about an active worm outbreak — it does not present itself as a response to the 2010 Exploit-DB entry, and nothing resolved links the two events. Human reverse engineering of a CGI endpoint; no AI involvement is claimed anywhere in the record.",
+    "ai_discovery_source": "human_researcher",
+    "discovery_attribution_note": "Curated from NVD CVE-2010-5330 (CWE-77, CVSS 9.8) + CISA KEV (added 2022-04-15) + the Ubiquiti airMAX community advisory 'AirOS Security Exploit -- Updated Firmware' (community.ubnt.com thread 212974, tagged Vendor Advisory and Patch by NVD), with the original public exploit at Exploit-DB 14146 by Emanuele 'emgent' Gentili.",
+    "ai_assisted_weaponization": false,
+    "active_exploitation_notes": "In-the-wild use is documented by the vendor, not inferred from the KEV listing. Ubiquiti's airMAX advisory of 2011-12-19 states there are two things: 'a vulnerability with the http server, allowing users to bypass authentication and run commands' and 'a worm that has been taking advantage of #1 to spread itself'. The same post names what the worm leaves on an infected radio — admin.cgi renamed to adm.cgi, and a startup script in /etc/persistent, checkable with ls -la /etc/persistent for .skynet and rc.poststart — gives the manual removal sequence, and links a removal tool, CureSkynetMalware-0.4.jar, MD5 9310926b691b7f95e0ba2c973a5d09c2. CISA added the CVE to KEV on 2022-04-15 with a 2022-05-06 due date and no ransomware attribution, and NVD carries CISA's SSVC decision of 2025-02-07: exploitation active, automatable yes, technicalImpact total. No named threat-intel vendor report tying a later campaign to this flaw was resolved; the self-propagating worm the vendor described is the exploitation on the record. EPSS at 2026-08-16 is 0.34641, at the 98.283rd percentile.",
+    "attack_refs": [
+      "T1190",
+      "T1059.004"
+    ],
+    "atlas_refs": [],
+    "framework_control_gaps": {
+      "NIST-800-53-SI-2": "SI-2 flaw remediation assumes an inventory that names the flawed component and a patch keyed to it. Here the fixed level differs per firmware line — v4.0.1, v5.3.5 and v5.4.5 are all 'the fix' for different Ubiquiti products — so an estate that records a single minimum AirOS version in its standard will pass an SI-2 check while leaving airMAX radios below v5.3.5 exposed on the strength of a number that only ever applied to the 802.11 line.",
+      "NIS2-Art21-network-security": "Article 21 network security measures are written for the networks an entity operates, and a wireless-ISP radio is simultaneously the network and an endpoint on it. The stainfo.cgi path is reachable from the client side of a subscriber CPE, so 'the management interface is not exposed to the internet' — the assertion this control normally elicits — is true and irrelevant: the attacker is a subscriber, not an internet host, and Article 21 offers no measure that separates the served network from the device serving it.",
+      "UK-CAF-B5": "CAF B5 seeks resilient networks and systems, and a WISP can evidence it with redundant paths and documented failover while every radio on both paths runs the same vulnerable AirOS build. Redundancy is the wrong shape of resilience for a monoculture defect: a single crafted GET to stainfo.cgi fires identically against the primary and the standby and needs no credential on either, since Ubiquiti's 2011-12-19 advisory puts the flaw in the AirOS HTTP server 'without requiring authentication'. The worm the same advisory documents spread through that bypass, which is the correlated-failure case in its most literal form: the flaw that opens the primary is the flaw that opens the standby, and the worm needed no separate step to cross between them. The B5 outcome is met and the failure mode it exists to survive is shared by every unit running the build.",
+      "AU-Essential-8-Patch": "Essential Eight patching timeframes run from vendor patch availability, and Ubiquiti's availability here is v4.0.1, v5.3.5 and v5.4.5 — releases that predate the 2022-04-15 KEV listing by more than a decade, so every radio below its line's level is already outside any timeframe the model recognises. What the model cannot express is why a unit stays on the old build: applying AirOS firmware reboots the radio and drops the link it carries, so a deferral on that ground is an operational decision about a live backhaul, not an administrative delay. A fleet can report the patch strategy implemented while a subscriber-facing radio still serves stainfo.cgi from the old build.",
+      "ISO-27001-2022-A.8.21": "A.8.21 security of network services is normally evidenced against carrier and managed-service agreements, not against the firmware of the operator's own radios. The control asks that security mechanisms and service levels be identified and included; it does not ask whether the CGI serving the 'Show AP info' page authorises its caller, and an ISMS that has documented its network service arrangements in full has said nothing about the unsanitized ifname parameter."
+    },
+    "patch_available": true,
+    "patch_required_reboot": true,
+    "live_patch_available": false,
+    "live_patch_tools": [],
+    "live_patch_notes": "The fixed levels are v4.0.1 for the 802.11 ISP product line, v5.3.5 for the airMAX ISP line and v5.4.5 for AirSync firmware — the same three figures in NVD's description and in Ubiquiti's 2011-12-19 advisory, which points at ubnt.com/support/downloads for the images and separately published an SDK-level fix, lighttpd-mod-airos-exploit-fix.patch, for operators building their own firmware. Anything below its own line's figure is exploitable, and the three lines must be assessed separately because a radio 'newer than 4.0.1' on the airMAX line is still vulnerable. Firmware upload reboots the radio, and on a point-to-point backhaul that reboot drops the link it carries, so the upgrade has to be scheduled against a service interruption; where it is deferred on that ground the radio keeps serving the pre-fix build. NVD names Nanostation5 as an example of an affected device and gives v4.0.1 as the fixed version for the 802.11 ISP line it belongs to. What has to be established per model on a legacy unit is whether a build at or above its line's fixed level is still obtainable from Ubiquiti today; where it is not, replacement on a dated plan is the terminal state, and that condition should be recorded per model rather than assumed for the generation. Until either lands, bind the HTTP and HTTPS management interfaces to an address the client and wireless-facing networks cannot route to. Upgrading is not by itself remediation on a unit that was reachable while unpatched: the published exploit's first action is reading the account block out of /tmp/system.cfg, so rotate that credential everywhere it was reused; where one administrative password was set on every radio, that scope is every radio. Then check the unit for what the vendor's worm left behind — adm.cgi in place of admin.cgi, .skynet and rc.poststart under /etc/persistent — because the fixed firmware prevents reinfection without removing an existing infection.",
+    "affected": "Ubiquiti AirOS, the firmware running on Ubiquiti wireless-ISP radios, bridges and customer-premises equipment. NVD names Nanostation5 only as an example and scopes the fix across three separate firmware lines — 802.11 ISP products, airMAX ISP products and AirSync — so exposure follows the firmware line rather than one model number. The defect is in the AirOS HTTP server, which Ubiquiti describes as letting callers bypass authentication and run commands, so any Ubiquiti radio, bridge or CPE running an AirOS build below its line's fixed level and answering on that management interface is in scope — including units deployed at subscriber premises where the operator does not control the attached client network and therefore cannot segment the management interface away from it. Reach stops at Ubiquiti's own firmware lines, but within them the radio holds the position an edge firewall or gateway holds: it is the perimeter for the network behind it, and it takes the injection with no credential at all. Spread is not bounded by what an attacker reaches by hand either, since Ubiquiti documented a worm using this same flaw to move between radios unaided, and CISA's SSVC decision records automatable yes. That is what the blast radius of 22 records — an edge-and-perimeter asset with an unauthenticated path to shell — and it sits at the bottom of that range rather than higher because the exposed population is one vendor's radio firmware.",
+    "affected_versions": [
+      "802.11 ISP product line: two ranges are on the record and they differ — Ubiquiti's advisory names AirOS v3.6.1 and v4.0 as affected and says previous versions are not, while NVD's CPE covers every AirOS build below 4.0.1 with no lower bound. Sweep to the broader NVD range and treat the vendor list as the confirmed subset (fixed in v4.0.1)",
+      "airMAX ISP product line: Ubiquiti names AirOS v5.x, all versions, as affected; NVD's CPE runs from 4.0.2 up to but not including 5.3.5 — affected below v5.3.5 (fixed in v5.3.5)",
+      "AirSync firmware: below v5.4.5 — affected (fixed in v5.4.5)",
+      "Nanostation5, the device NVD names as an example, sits on the 802.11 ISP line — affected below v4.0.1 and fixed at v4.0.1, so a fix exists for it; confirm per model that a build at or above the line's level is still obtainable before planning the upgrade"
+    ],
+    "vendor_update_paths": [
+      "Upgrade 802.11 ISP-line radios to AirOS v4.0.1 or later and confirm the unit rebooted onto the new build",
+      "Upgrade airMAX ISP-line radios to AirOS v5.3.5 or later",
+      "Upgrade AirSync firmware to v5.4.5 or later",
+      "Confirm per model that a build at or above its line's fixed level is still obtainable for legacy radios, and where it is not, schedule replacement on a dated plan rather than an open risk acceptance",
+      "Rotate the AirOS administrative credential fleet-wide for any unit that was reachable while unpatched"
+    ],
+    "_auto_imported": false,
+    "_intake_method": "batch-curated",
+    "rwep_factors": {
+      "cisa_kev": 25,
+      "poc_available": 20,
+      "ai_factor": 0,
+      "active_exploitation": 20,
+      "blast_radius": 22,
+      "patch_available": -15,
+      "live_patch_available": 0,
+      "reboot_required": 5
+    },
+    "rwep_score": 77,
+    "rwep_notes": "RWEP 77. cisa_kev +25, poc_available +20, active_exploitation +20, blast_radius +22, patch_available -15, reboot_required +5. Σ factors === rwep_score."
+  },
+  "CVE-2022-21919": {
+    "name": "Microsoft Windows User Profile Service Privilege Escalation Vulnerability (CVE-2022-21919)",
+    "cvss_score": 7,
+    "cvss_vector": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
+    "cwe_refs": [
+      "CWE-59"
+    ],
+    "cisa_kev": true,
+    "cisa_kev_date": "2022-04-25",
+    "cisa_kev_due_date": "2022-05-16",
+    "known_ransomware_use": false,
+    "active_exploitation": "confirmed",
+    "complexity": "high",
+    "vector": "The Windows User Profile Service builds a temporary profile under C:\\Users\\TEMP when a user's own profile folder is locked or damaged, and copies that user's folders and files into it running as Local System. 0patch's analysis of the bug this fix closes records that the copy does not resolve the whole destination path before acting on it, so a local user who plants a symbolic link partway down that path redirects a Local System folder creation into a location they could never write themselves. Microsoft's August 2021 fix for CVE-2021-34484 tested only the uppermost folder under C:\\Users\\TEMP, and a link placed deeper walks straight past it. The published exploit converts the redirected write into SYSTEM execution by creating C:\\Windows\\System32\\osk.exe.local, dropping a comctl32.dll into the DotLocal redirection directory it makes there, and raising a UAC elevation prompt so the On-Screen Keyboard loads it. NVD assigns CWE-59; Rapid7 names profext.dll's CreateDirectoryJunction() as the unvalidated function when documenting the April 2022 bypass of this CVE.",
+    "epss_score": 0.0295,
+    "epss_percentile": 0.85989,
+    "epss_date": "2026-08-16",
+    "epss_source": "https://api.first.org/data/v1/epss?cve=CVE-2022-21919",
+    "vendor_advisories": [
+      {
+        "vendor": "Microsoft",
+        "advisory_id": "CVE-2022-21919",
+        "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-21919",
+        "severity": "unknown",
+        "published_date": null
+      },
+      {
+        "vendor": "Microsoft",
+        "advisory_id": "CVE-2022-21919",
+        "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-21919",
+        "severity": "unknown",
+        "published_date": null
+      }
+    ],
+    "verification_sources": [
+      "https://nvd.nist.gov/vuln/detail/CVE-2022-21919",
+      "https://www.cisa.gov/known-exploited-vulnerabilities-catalog",
+      "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-21919",
+      "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-21919"
+    ],
+    "source_verified": "2026-08-18",
+    "last_updated": "2026-08-18",
+    "_kev_short_description": "Microsoft Windows User Profile Service contains an unspecified vulnerability that allows for privilege escalation.",
+    "type": "symlink-junction-abuse-local-privilege-escalation",
+    "blast_radius": 18,
+    "poc_available": true,
+    "poc_description": "Public, and obtainable today. Microsoft's record sets publiclyDisclosed to Yes and carries the temporal vector CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H/E:P/RL:O/RC:C, E:P asserting proof-of-concept code existed at publication. That code is Abdelhamid Naceri's bypass of Microsoft's incomplete fix for CVE-2021-34484: 0patch's write-up (https://0patch.com/blog/micropatching-incompletely-patched) records that Naceri found the fix 'bypassable with a small change to the attack script', that 'a write-up and proof of concept were published' at github.com/klinix5/ProfSvcLPE, and carries the update that 'January 2022 Windows Updates brought a fix for this issue' — which is this CVE. The original repository now returns 404; the tree survives at https://github.com/nieldk/ProfSvcLPE, whose DoubleJunctionEoP directory holds UserProfileSvcEoP.cpp and Win-Ops-Master.cpp as buildable source. The junction technique matches this CVE's CWE-59 assignment and the race matches its AC:H. January 2022 shipped two User Profile Service elevation CVEs and the vendor record separates them: CVE-2022-21895 is AC:L, Publicly Disclosed:No, E:U and credited to named finders, while this one is AC:H, Publicly Disclosed:Yes and E:P — the shape 0patch describes. Rapid7's documentation for the April module also names CVE-2022-21919, alongside CVE-2021-34484, as a previous iteration of the same profext.dll flaw. Note the search shape that hides it: the repository carries no CVE identifier in its name or path, so a query keyed on 'CVE-2022-21919' returns nothing while the artefact sits in plain view — an absence reached only that way is not an established absence. Separately, Metasploit's exploit/windows/local/cve_2022_26904_superprofile targets CVE-2022-26904, the April 2022 bypass in the same family, and is not evidence for this CVE.",
+    "iocs": {
+      "behavioral": [
+        "Directory junctions or native symbolic links created by a non-administrative user inside C:\\Users\\TEMP while the User Profile Service is building a temporary profile",
+        "The svchost.exe instance hosting the User Profile Service creating or writing directories outside the profile tree it was asked to service",
+        "A non-administrative interactive logon followed closely by a SYSTEM-context process creation with no corresponding scheduled task or service install",
+        "An accessibility or other SYSTEM-context binary loading a DLL from a directory that a standard user can write"
+      ],
+      "indicators": [
+        "Hosts below the January 2022 fixed builds — 6.3.9600.20246, 6.2.9200.23584, 6.1.7601.25829, 6.0.6003.21349, or the branch's 2022-01-11 cumulative update for Windows 10, Windows 11 21H2 and Server 2016 / 2019 / 2022",
+        "Hosts that installed the January 2022 update but have an uptime spanning the install, since Microsoft marks every affected product restart-required",
+        "More than one non-administrative profile directory under C:\\Users\\<username>, each holding an ntuser.dat — the published exploit opens the second account's hive with no sharing to force the temporary-profile fallback",
+        "An unexpected C:\\Users\\TEMP tree, or a stray C:\\_tmp_ directory, on a host that is not mid-profile-repair",
+        "C:\\Windows\\System32\\osk.exe.local present, or a comctl32.dll under it in an amd64_microsoft.windows.common-controls_* subdirectory — the DotLocal redirection the published exploit creates",
+        "Unexpected copies of common system DLLs appearing in directories on the search path of SYSTEM-context binaries"
+      ],
+      "_ioc_source_note": "The junction-and-symlink sequence, the C:\\Users\\TEMP and C:\\_tmp_ staging, the ntuser.dat handle that forces the temporary-profile fallback and the osk.exe.local DotLocal plant are read from Abdelhamid Naceri's proof of concept — originally at github.com/klinix5/ProfSvcLPE (now 404), preserved at https://github.com/nieldk/ProfSvcLPE, in DoubleJunctionEoP/UserProfileSvcEoP.cpp with its primitives in DoubleJunctionEoP/Win-Ops-Master.cpp. Its binding to this CVE is 0patch's write-up (https://0patch.com/blog/micropatching-incompletely-patched), which analyses that proof of concept against Microsoft's incomplete CVE-2021-34484 fix, cites Naceri as its author, and records that the January 2022 Windows updates resolved the issue. That proof of concept contains no PromptOnSecureDesktop setting and no C:\\Users\\<username>.<domain> profile form: both come from Rapid7's Metasploit documentation for the April 2022 sibling CVE-2022-26904 (documentation/modules/exploit/windows/local/cve_2022_26904_superprofile.md), so neither is carried here as a precondition of this CVE. The fixed-build numbers come from Microsoft's January 2022 advisory, not from the exploit."
+    },
+    "ai_discovered": false,
+    "ai_discovery_notes": "Microsoft's acknowledgements record carries no finder for CVE-2022-21919, and the January 2022 entry marks the issue publicly disclosed before the fix — so the disclosure route ran through public discussion of the earlier CVE-2021-34484 patch rather than through a credited private report. The finder is nevertheless named outside the vendor record: 0patch's write-up (https://0patch.com/blog/micropatching-incompletely-patched) attributes the bypass of Microsoft's incomplete CVE-2021-34484 fix to Abdelhamid Naceri and records that the January 2022 Windows updates resolved it, which is this CVE. Recorded as human_researcher on that attribution rather than unknown, since a credit outside the vendor's acknowledgements is still a credit. No AI-assisted discovery is claimed anywhere in the record.",
+    "ai_discovery_source": "human_researcher",
+    "discovery_attribution_note": "Curated from NVD CVE-2022-21919 (CWE-59, CVSS 7.0) + CISA KEV (added 2022-04-25) + Microsoft advisory CVE-2022-21919 (released 2022-01-11, publicly disclosed prior to the fix, exploit-code maturity E:P, no acknowledged finder listed) + 0patch's write-up, which attributes the bypass to Abdelhamid Naceri and links the write-up and proof of concept he published at github.com/klinix5/ProfSvcLPE.",
+    "ai_assisted_weaponization": false,
+    "active_exploitation_notes": "CISA added this to KEV on 2022-04-25 with a 2022-05-16 due date, and leaves knownRansomwareCampaignUse at Unknown rather than asserting either way; that listing is the evidence of in-the-wild exploitation. Microsoft's vulnerability record for the same CVE still reports exploited: No against its 2022-01-11 release date, while flagging Publicly Disclosed: Yes, Exploitation More Likely and exploit-code maturity of Proof-of-Concept — so an operator who checks MSRC to justify the KEV clock finds public exploit code but no vendor claim of in-the-wild use, and the two sources disagree on exploitation itself. The bug belongs to a family Microsoft patched three times across eight months: CVE-2021-34484 on 2021-08-10, this CVE on 2022-01-11, CVE-2022-26904 on 2022-04-12. Public proof-of-concept source accompanied this one from the start, and the third of the three is the one that additionally acquired a Metasploit module.",
+    "attack_refs": [
+      "T1068",
+      "T1548",
+      "T1574.001"
+    ],
+    "atlas_refs": [],
+    "framework_control_gaps": {
+      "NIST-800-53-SI-2": "Flaw remediation was performed correctly here and still left a long window: Microsoft shipped the fix on 2022-01-11, and CISA did not list the CVE until 2022-04-25 with a 2022-05-16 due date, so an organisation that patched on the ordinary monthly cadence was already remediated while one that deferred January's rollup for testing had a fourteen-week exposure that no SI-2 finding would have flagged as overdue. The control also credits an update as applied at install time, whereas Microsoft marks every affected product restart-required and the service stays vulnerable until the reboot.",
+      "NIST-800-53-AC-6": "Least privilege is the control operators reach for against an elevation-of-privilege bug and it does nothing here. The attacker already holds a legitimate, non-administrative local account — PR:L — and the escalation happens inside the User Profile Service, which runs as SYSTEM by design on every Windows install. Tightening account privilege, removing local administrator rights and scoping group membership all leave that service exactly as reachable, so an AC-6 attestation is fully intact on a host that hands SYSTEM to any interactive user.",
+      "NIS2-Art21-vulnerability-handling": "The vulnerability-handling obligation is written around receiving, assessing and acting on disclosures, and this CVE breaks the assessment step rather than the process. Microsoft's own record reports exploited: No — while flagging Publicly Disclosed: Yes and Exploitation More Likely — so an entity following the vendor feed had a disclosure signal but no in-the-wild signal until CISA's 2022-04-25 listing supplied one, three and a half months after the January patch. A handling process that treats the vendor as the authority on exploitation status will under-prioritise every entry where KEV and the vendor disagree, and this is one of them.",
+      "UK-CAF-B2": "The B2 identity-and-access outcome is evidenced with account provisioning, privilege separation and control over who holds administrative rights, and every part of that evidence survives this attack unchanged. The escalation crosses a privilege boundary inside a SYSTEM service rather than abusing any account's entitlements, and the published exploit actually depends on an ordinary second user account with a profile under C:\\Users — the more standard the estate's account hygiene, the more reliably that precondition is met. B2 measures a control the exploit never consults.",
+      "AU-Essential-8-Patch": "The Essential Eight operating-system patching mitigation sets a one-month window for non-internet-facing systems at the lower maturity levels, which for a 2022-01-11 update means compliant remediation as late as mid-February and, at the loosest reading, well past CISA's 2022-05-16 due date. It also measures the update, not the reboot Microsoft requires, and it has no concept of an escalation whose whole precondition is a second ordinary user profile on the host — so a compliant workstation fleet and a compliant multi-user session host look identical on the report despite carrying very different exposure.",
+      "ISO-27001-2022-A.8.8": "Technical vulnerability management is met by ingesting Microsoft's 2022-01-11 bulletin, rating it and scheduling it, and the only exploitation field on that bulletin reads exploited: No — the one statement CISA later contradicts, and the one Microsoft still publishes today. The control has no mechanism for revisiting the January decision when the CVE lands in an external exploited-vulnerability catalog on 2022-04-25, so it persists unchallenged into a period when a federal remediation deadline of 2022-05-16 exists for the same bug. Reassessment triggered by catalog change, not only by disclosure, is the missing behaviour."
+    },
+    "patch_available": true,
+    "patch_required_reboot": true,
+    "live_patch_available": true,
+    "live_patch_tools": [
+      "0patch"
+    ],
+    "live_patch_notes": "Two remediations exist and they cover different estates. Microsoft's fix ships in the January 2022 cumulative updates and every affected product is marked restart-required, so a host that installed the update and has not rebooted is still running the vulnerable User Profile Service. Fixed builds include 6.3.9600.20246 for Windows 8.1 and Server 2012 R2 (KB5009624 / KB5009595), 6.2.9200.23584 for Server 2012 (KB5009586 / KB5009619), 6.1.7601.25829 for Windows 7 SP1 and Server 2008 R2 SP1 under ESU (KB5009610 / KB5009621) and 6.0.6003.21349 for Server 2008 SP2 under ESU (KB5009627 / KB5009601), alongside the January cumulative updates for Windows 10, Windows 11 21H2 and Server 2016 / 2019 / 2022. Before that fix existed, 0patch shipped an in-memory micropatch for the same bug (https://0patch.com/blog/micropatching-incompletely-patched): it resolves the destination path with GetFinalPathNameByHandle and aborts temporary-profile creation when the resolved path differs, and it applies with 'No computer reboots will be needed'. Its coverage is narrower than this CVE's — Windows 10 v1809 at the May 2021 updates, v1903, v1909, v2004, v20H2 and v21H1 at the October or November 2021 updates, Server 2016 at November 2021 and Server 2019 at October or November 2021, and nothing else; 0patch judged older lines' differing code to leave a race window it considered probably unexploitable. The micropatches were free while the bug was unfixed and moved into the paid PRO plan on 2022-01-12 when 0patch recorded that the January Windows updates had fixed it, so today they are a way to hold a host stuck on one of those builds, not a substitute for the rollup. There is no configuration workaround: the User Profile Service cannot be disabled on a machine that logs users in. Patch multi-user hosts first — session hosts, shared workstations, jump servers — because the exploit's requirement for a second local account with an existing profile is their normal operating state rather than an anomaly.",
+    "affected": "Every supported Windows client and server line at the January 2022 patch level, from Windows 7 SP1 and Server 2008 SP2 under Extended Security Updates through Windows 10 (1507 to 21H2), Windows 11 21H2, and Server 2012, 2012 R2, 2016, 2019 and 2022, in both full and Server Core installations. The User Profile Service is a core component present on every SKU, so no role, feature or provisioning decision removes the surface — the only variable is whether the host carries the second local profile the published exploit needs.",
+    "affected_versions": [
+      "Windows 11 21H2 and Windows 10 1507 through 21H2 — fixed by the January 2022 cumulative update for the branch",
+      "Windows Server 2022, 2019 and 2016 — fixed by the January 2022 cumulative update for the branch",
+      "Windows 8.1 and Windows Server 2012 R2 — fixed at build 6.3.9600.20246 (KB5009624 / KB5009595)",
+      "Windows Server 2012 — fixed at build 6.2.9200.23584 (KB5009586 / KB5009619)",
+      "Windows 7 SP1 and Windows Server 2008 R2 SP1 (ESU) — fixed at build 6.1.7601.25829 (KB5009610 / KB5009621)",
+      "Windows Server 2008 SP2 (ESU) — fixed at build 6.0.6003.21349 (KB5009627 / KB5009601)"
+    ],
+    "vendor_update_paths": [
+      "Install the January 2022 (2022-01-11) cumulative update for each Windows branch and reboot the host",
+      "Windows 7 SP1 / Server 2008 R2 SP1 and Server 2008 SP2: apply the January 2022 ESU packages, and treat the ESU expiry as the real deadline for retiring the host",
+      "Confirm remediation by installed build rather than by update-approval state in the management console"
+    ],
+    "_auto_imported": false,
+    "_intake_method": "batch-curated",
+    "rwep_factors": {
+      "cisa_kev": 25,
+      "poc_available": 20,
+      "ai_factor": 0,
+      "active_exploitation": 20,
+      "blast_radius": 18,
+      "patch_available": -15,
+      "live_patch_available": -10,
+      "reboot_required": 5
+    },
+    "rwep_score": 63,
+    "rwep_notes": "RWEP 63. cisa_kev +25, poc_available +20, active_exploitation +20, blast_radius +18, patch_available -15, live_patch_available -10, reboot_required +5. Σ factors === rwep_score."
+  },
+  "CVE-2022-22674": {
+    "name": "Apple macOS Out-of-Bounds Read Vulnerability",
+    "cvss_score": 5.5,
+    "cvss_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
+    "cwe_refs": [
+      "CWE-125"
+    ],
+    "cisa_kev": true,
+    "cisa_kev_date": "2022-04-04",
+    "cisa_kev_due_date": "2022-04-25",
+    "known_ransomware_use": false,
+    "active_exploitation": "confirmed",
+    "complexity": "low",
+    "vector": "A graphics driver kernel extension — named 'Intel Graphics Driver' in Apple's Monterey advisory and 'Graphics Drivers' in the Big Sur and Catalina ones — reads past the end of a buffer while handling input it does not adequately validate, and hands the over-read bytes back to the calling process. A local application therefore obtains kernel memory it has no right to see — kernel pointers that defeat address-space layout randomisation, plus whatever else occupies adjacent kernel allocations. Nothing is written and no code runs; the value is as the information-disclosure stage of a chain whose next step has to know where kernel objects live. Apple describes the fix as improved input validation, which places the defect at the driver's bounds check on attacker-influenced input rather than in the graphics logic itself.",
+    "epss_score": 0.01133,
+    "epss_percentile": 0.63745,
+    "epss_date": "2026-08-16",
+    "epss_source": "https://api.first.org/data/v1/epss?cve=CVE-2022-22674",
+    "vendor_advisories": [
+      {
+        "vendor": "Apple",
+        "advisory_id": "HT213220",
+        "url": "https://support.apple.com/en-us/HT213220",
+        "severity": "unknown",
+        "published_date": null
+      },
+      {
+        "vendor": "Apple",
+        "advisory_id": "HT213255",
+        "url": "https://support.apple.com/en-us/HT213255",
+        "severity": "unknown",
+        "published_date": null
+      },
+      {
+        "vendor": "Apple",
+        "advisory_id": "HT213256",
+        "url": "https://support.apple.com/en-us/HT213256",
+        "severity": "unknown",
+        "published_date": null
+      }
+    ],
+    "verification_sources": [
+      "https://nvd.nist.gov/vuln/detail/CVE-2022-22674",
+      "https://www.cisa.gov/known-exploited-vulnerabilities-catalog",
+      "https://support.apple.com/en-us/HT213220",
+      "https://support.apple.com/en-us/HT213255",
+      "https://support.apple.com/en-us/HT213256"
+    ],
+    "source_verified": "2026-08-18",
+    "last_updated": "2026-08-18",
+    "_kev_short_description": "macOS Monterey contains an out-of-bounds read vulnerability that could allow an application to read kernel memory.",
+    "type": "kernel-graphics-driver-out-of-bounds-read-info-disclosure",
+    "blast_radius": 17,
+    "poc_available": false,
+    "poc_description": "No public exploit artefact. Exploit-DB carries no entry for CVE-2022-22674 in an index that returns three hits for CVE-2020-5902, so the absence is a real result. ProjectDiscovery ships no template — network templates would not apply to a local kernel read in any case. GitHub repository search returns zero repositories named for the CVE, and the Metasploit module tree contains nothing for the Intel Graphics Driver or for macOS kernel information disclosure of this kind. Apple credits an anonymous researcher and published one sentence of description. An honest false: the code was never published.",
+    "iocs": {
+      "behavioral": [
+        "An unprivileged local process repeatedly opening and calling into whichever graphics kernel driver interfaces that Mac exposes — the Intel graphics ones on Intel hardware, the Apple GPU ones on Apple silicon — outside any graphics workload; a hunt written against the Intel interfaces alone returns a false clean on the Apple silicon Macs the Big Sur 11.6.6 advisory leaves in scope",
+        "Kernel panics or diagnostic reports in /Library/Logs/DiagnosticReports naming a graphics kernel extension on machines where graphics workloads have not changed — match on the graphics kext family present on that architecture rather than on an Intel name, or every Apple silicon Mac drops out of the sweep while still sitting inside the advisory's stated scope",
+        "A newly installed or newly launched application making low-level driver calls shortly after first execution, particularly one that arrived outside the estate's normal distribution path",
+        "Escalation activity on a Mac following a period of anomalous driver interaction, since this bug's role is as the disclosure stage of a chain rather than the outcome"
+      ],
+      "indicators": [
+        "Macs reporting a macOS build below 12.3.1 on the Monterey line or below 11.6.6 on the Big Sur line, counted without excluding Apple silicon",
+        "Macs on the Catalina line without Security Update 2022-004 applied, and Catalina machines sitting below the line's later updates — Security Update 2022-005 Catalina of 20 July 2022 and after — counted as a standing exposure population, since Apple's most recent Catalina entry, Security Update 2026-001 Catalina of 02 Feb 2026, carries no published CVE entries",
+        "Machines whose management record shows the fixed update downloaded or staged but whose uptime spans the install, meaning the kernel extension in memory is still the vulnerable one",
+        "Hardware architecture recorded per device — a scoping input for the day Apple clarifies the component, not grounds to drop Apple silicon from the remediation population now",
+        "Applications running outside the estate's managed distribution on Macs that hold the local user privilege this bug requires"
+      ]
+    },
+    "ai_discovered": false,
+    "ai_discovery_notes": "Apple credits 'an anonymous researcher' in every advisory carrying this CVE — an outside party who chose not to be named, not an Apple team and not a branded research lab whose name might be mistaken for tooling. Nothing in the record names fuzzing infrastructure, automated triage or AI assistance, and Apple publishes no account of the discovery method.",
+    "ai_discovery_source": "human_researcher",
+    "discovery_attribution_note": "Curated from NVD CVE-2022-22674 (CWE-125, CVSS 5.5) + CISA KEV (added 2022-04-04) + Apple advisories HT213220 (macOS Monterey 12.3.1), HT213256 (macOS Big Sur 11.6.6) and HT213255 (Security Update 2022-004 Catalina), each crediting an anonymous researcher.",
+    "ai_assisted_weaponization": false,
+    "active_exploitation_notes": "Apple's macOS Monterey 12.3.1 advisory of 2022-03-31 (APPLE-SA-2022-03-31-2) states verbatim in the Intel Graphics Driver entry that 'Apple is aware of a report that this issue may have been actively exploited.' CISA added the CVE to KEV four days later on 2022-04-04 with a 2022-04-25 due date, and leaves knownRansomwareCampaignUse at Unknown rather than asserting either way. One thing to know when reading the later advisories: the macOS Big Sur 11.6.6 and Security Update 2022-004 Catalina entries of 2022-05-16 restate this CVE differently on four fields — component, impact, description, and the exploited notice. The component becomes 'Graphics Drivers' rather than 'Intel Graphics Driver', the impact becomes 'A local user may be able to read kernel memory' rather than 'An application may be able to read kernel memory', the description is rewritten to 'An out-of-bounds read issue existed that led to the disclosure of kernel memory. This was addressed with improved input validation.', and the sentence recording active exploitation is dropped entirely. The credit line is the field that does not move: 'CVE-2022-22674: an anonymous researcher' stands byte-identical in HT213220, HT213255 and HT213256. An operator working from the Big Sur advisory alone would never learn the flaw had been exploited, and would see no indication that the affected component is Intel-specific.",
+    "attack_refs": [
+      "T1068",
+      "T1211",
+      "T1082"
+    ],
+    "atlas_refs": [],
+    "framework_control_gaps": {
+      "NIST-800-53-SI-2": "Flaw remediation had a short and clear window here — Apple shipped 12.3.1 on 2022-03-31 and CISA's due date was 2022-04-25 — and SI-2 as written still leaves two things unhandled. It credits the update at install rather than at restart, and a macOS kernel-extension fix is inert until the Mac reboots, which on laptops is user-controlled. It also has no vocabulary for macOS Catalina, whose Security Update 2022-004 remediated this CVE, which Apple then updated further with Security Update 2022-005 Catalina on 20 July 2022, and whose most recent entry on Apple's security-releases list — Security Update 2026-001 Catalina of 02 Feb 2026 — carries no published CVE entries: the correct action on those machines is to run them up to the newest Catalina update and then retire them, and SI-2 can record the first step while having no state at all for the second.",
+      "NIST-800-53-SC-39": "Process isolation is exactly the property this bug defeats and exactly the control that cannot detect it. SC-39 is satisfied by an operating system that maintains separate address spaces, which macOS does; the failure is a kernel driver handing an unprivileged process bytes from kernel memory through a legitimate interface, so the isolation architecture is intact and the boundary still leaks. There is no assessment activity under SC-39 that would distinguish a Mac on 12.3 from one on 12.3.1, because both isolate processes correctly by every observable measure.",
+      "NIS2-Art21-vulnerability-management": "The vulnerability-management obligation covers acquiring and acting on vulnerability information, and Apple's 2022-03-31 advisory supplied it — including the actively-exploited notice. The obligation gives no weight to a bug whose direct impact is C:H/I:N/A:N and CVSS 5.5, so a risk-proportionate process legitimately ranks a read-only local disclosure below the critical remote flaws in the same month's queue. That ranking is what misreads this CVE: its role is supplying the kernel addresses another bug in the chain needs, and its own score does not represent the chain.",
+      "UK-CAF-B4": "System security under B4 is evidenced with hardened endpoint builds, and a managed Mac fleet with FileVault, Gatekeeper, System Integrity Protection and a current baseline produces strong evidence. None of those touch a kernel driver over-read: SIP does not constrain what the driver returns to a caller, and Gatekeeper's judgement about an application's provenance is irrelevant once that application is running and making an ordinary driver call. B4 also gives no way to record a scope question the vendor left open: Apple names the affected component 'Intel Graphics Driver' on one macOS line and 'Graphics Drivers' on the two others, so an assessor cannot evidence which Macs on a given build are exposed, and the control offers no way to express that the safe answer is all of them.",
+      "AU-Essential-8-Patch": "Essential Eight operating-system patching gives workstations one month from release, and that is the requirement at Maturity Level One and Maturity Level Two alike — the two levels read identically on this line, with no vendor-assessment limb and no exploit limb at all. Maturity Level Three states it conditionally instead: 'Patches, updates or other vendor mitigations for vulnerabilities in operating systems of workstations, non-internet-facing servers and non-internet-facing network devices are applied within one month of release when vulnerabilities are assessed as non-critical by vendors and no working exploits exist' (ACSC Essential Eight maturity model, Appendix C). Neither limb of that clause is settled on Apple's advisory wording. Apple ships these advisories with no severity rating, so no vendor has assessed this vulnerability as non-critical. And no exploit code for CVE-2022-22674 was ever published, while Apple's 2022-03-31 advisory says the issue may have been actively exploited. Maturity Level Three's separate driver clause carries the same two limbs, so filing this graphics-driver fix as a driver patch rather than an operating-system one changes nothing. On the Catalina side the requirement to replace vendor-unsupported operating systems is the natural hook, though whether Apple's 02 Feb 2026 Catalina update leaves that line 'supported' is itself arguable; nothing in any maturity level separates an installed update from a restarted machine, and this kernel-extension fix is inert until the restart.",
+      "ISO-27001-2022-A.8.28": "Secure coding is the control aimed at the actual defect — a missing bounds check on attacker-influenced input reaching a kernel driver — and it is also the one an operator cannot act on. A.8.28 governs code the organisation develops or procures under its own requirements, and the Intel Graphics Driver arrives as part of a closed operating system the operator neither builds nor reviews. The control produces no assurance about this component and no test that would distinguish a vulnerable driver from a fixed one, so its coverage of a purchased kernel extension is nominal."
+    },
+    "patch_available": true,
+    "patch_required_reboot": true,
+    "live_patch_available": false,
+    "live_patch_tools": [],
+    "live_patch_notes": "Fixed in macOS Monterey 12.3.1, macOS Big Sur 11.6.6 and Security Update 2022-004 Catalina. A kernel-extension fix takes effect only once the machine restarts into the updated system, so a Mac that has downloaded and staged the update is not remediated until that restart completes. There is no configuration mitigation, because the graphics driver cannot be unloaded on a Mac that drives a display. On Catalina the two actions are sequential rather than alternatives: apply Security Update 2022-004 Catalina now, because that is the update closing this CVE on that line, and then put the machine on a migration or replacement schedule. Do not stop at 2022-004 — Apple shipped Security Update 2022-005 Catalina on 20 July 2022, carrying its own set of CVE fixes — so bring those Macs to the newest Catalina update available to them. Apple has not stopped shipping the line updates outright either: the most recent Catalina entry on Apple's security-releases list is Security Update 2026-001 Catalina of 02 Feb 2026, and it carries the annotation 'This update has no published CVE entries', so nothing published there evidences continued CVE fixes for Catalina. Patch first, migrate after — deferring the update until the migration lands leaves the kernel read open for the whole of that window. Do not carve Apple silicon out of the remediation population: Big Sur is the first macOS that runs on those machines, and Apple's Big Sur 11.6.6 advisory files this CVE under the generic 'Graphics Drivers' component while using the Intel-specific heading for other CVEs on the same page, so nothing Apple published establishes that M1 machines are outside scope.",
+    "affected": "macOS across the three lines Apple supported at the time of the fix: macOS Monterey before 12.3.1, where the advisory names the component 'Intel Graphics Driver', and macOS Big Sur before 11.6.6 and macOS Catalina before Security Update 2022-004, where the same CVE appears under the broader component name 'Graphics Drivers'. Apple did not ship this CVE to iOS, iPadOS, tvOS or watchOS. The hardware scope is the open question and Apple's own filing does not settle it: Big Sur is the first macOS release that boots on Apple silicon, and its 11.6.6 advisory files this CVE under the generic 'Graphics Drivers' heading while using 'Intel Graphics Driver' for other CVEs on the same page. Catalina 10.15 runs only on Intel Macs, so its identical generic filing carries no information about Apple silicon in either direction — the whole hardware-scope argument rests on the Big Sur advisory, and that one advisory is enough to carry it. Treat every Mac below the fixed build as in scope; excluding Apple silicon rests on the Monterey component name alone.",
+    "affected_versions": [
+      "macOS Monterey < 12.3.1 (fixed in 12.3.1) — Apple names the component 'Intel Graphics Driver' on this line",
+      "macOS Big Sur < 11.6.6 (fixed in 11.6.6) — filed under the generic component 'Graphics Drivers'; no hardware restriction stated, and this is the first macOS line that runs on Apple silicon",
+      "macOS Catalina without Security Update 2022-004 (fixed by that update; the line kept shipping afterwards — Security Update 2022-005 Catalina landed 20 July 2022 — while its most recent entry on Apple's security-releases list, Security Update 2026-001 Catalina of 02 Feb 2026, carries no published CVE entries)",
+      "Apple silicon Macs — scope not established. Only the Monterey advisory names an Intel-specific component; the Big Sur 11.6.6 advisory, covering the first macOS line that boots on Apple silicon, files this CVE under 'Graphics Drivers' while using the Intel-specific heading for other CVEs on the same page, so patch to the fixed build rather than excluding them",
+      "iOS, iPadOS, tvOS and watchOS — this CVE was not shipped to those platforms; not affected"
+    ],
+    "vendor_update_paths": [
+      "Update Macs on Monterey to macOS 12.3.1 or later and restart",
+      "Update Macs on Big Sur to macOS 11.6.6 or later and restart, including Apple silicon machines — Apple's Big Sur advisory does not scope this CVE to Intel hardware",
+      "Apply Security Update 2022-004 Catalina — the update that closes this CVE — then carry those Macs on to the line's later updates rather than stopping there, Security Update 2022-005 Catalina of 20 July 2022 being the next one, and plan migration off Catalina in parallel: the line's most recent entry on Apple's security-releases list, Security Update 2026-001 Catalina of 02 Feb 2026, carries no published CVE entries",
+      "Verify remediation by the reported macOS build on each Mac, not by whether the update was downloaded"
+    ],
+    "_auto_imported": false,
+    "_intake_method": "batch-curated",
+    "rwep_factors": {
+      "cisa_kev": 25,
+      "poc_available": 0,
+      "ai_factor": 0,
+      "active_exploitation": 20,
+      "blast_radius": 17,
+      "patch_available": -15,
+      "live_patch_available": 0,
+      "reboot_required": 5
+    },
+    "rwep_score": 52,
+    "rwep_notes": "RWEP 52. cisa_kev +25, active_exploitation +20, blast_radius +17, patch_available -15, reboot_required +5. Σ factors === rwep_score."
+  },
   "CVE-2007-3010": {
     "name": "Alcatel OmniPCX Enterprise Remote Code Execution Vulnerability",
     "cvss_score": 9.8,

package/data/cwe-catalog.json

@@ -1,7 +1,7 @@
 {
   "_meta": {
     "schema_version": "1.0.0",
-    "last_updated": "2026-08-17",
+    "last_updated": "2026-08-18",
     "cwe_version": "4.20",
     "cwe_version_release_date": "2026-04-30",
     "source": "https://cwe.mitre.org",
@@ -230,6 +230,7 @@
     ],
     "evidence_cves": [
       "CVE-2007-3010",
+      "CVE-2010-5330",
       "CVE-2011-0411",
       "CVE-2014-8361",
       "CVE-2016-10033",
@@ -730,6 +731,7 @@
       "CVE-2017-5030",
       "CVE-2021-25487",
       "CVE-2021-4034",
+      "CVE-2022-22674",
       "CVE-2023-28204",
       "CVE-2023-36424",
       "CVE-2023-42916",
@@ -2923,6 +2925,7 @@
       "CVE-2020-0638",
       "CVE-2020-36193",
       "CVE-2021-34484",
+      "CVE-2022-21919",
       "CVE-2022-30333",
       "CVE-2023-36874",
       "CVE-2025-21391",

package/data/framework-control-gaps.json

@@ -637,6 +637,7 @@
       "CVE-2010-1428",
       "CVE-2010-2568",
       "CVE-2010-3962",
+      "CVE-2010-5330",
       "CVE-2011-0411",
       "CVE-2011-0609",
       "CVE-2011-1823",
@@ -881,10 +882,12 @@
       "CVE-2022-20775",
       "CVE-2022-20821",
       "CVE-2022-21445",
+      "CVE-2022-21919",
       "CVE-2022-22047",
       "CVE-2022-22071",
       "CVE-2022-22265",
       "CVE-2022-22536",
+      "CVE-2022-22674",
       "CVE-2022-22675",
       "CVE-2022-22706",
       "CVE-2022-22718",
@@ -2476,6 +2479,7 @@
       "CVE-2021-25370",
       "CVE-2021-26085",
       "CVE-2022-21587",
+      "CVE-2022-22674",
       "CVE-2022-22963",
       "CVE-2022-26352",
       "CVE-2022-29464",
@@ -2888,6 +2892,7 @@
       "CVE-2022-1471",
       "CVE-2022-20775",
       "CVE-2022-21445",
+      "CVE-2022-21919",
       "CVE-2022-22047",
       "CVE-2022-22071",
       "CVE-2022-22265",
@@ -4681,6 +4686,7 @@
       "CVE-2021-22600",
       "CVE-2021-25370",
       "CVE-2022-0492",
+      "CVE-2022-22674",
       "CVE-2022-32894",
       "CVE-2022-37969",
       "CVE-2022-4135",
@@ -5170,6 +5176,7 @@
       "CVE-2010-2883",
       "CVE-2010-3765",
       "CVE-2010-3962",
+      "CVE-2010-5330",
       "CVE-2011-0411",
       "CVE-2011-0609",
       "CVE-2011-1823",
@@ -5417,9 +5424,11 @@
       "CVE-2022-1471",
       "CVE-2022-20775",
       "CVE-2022-21445",
+      "CVE-2022-21919",
       "CVE-2022-22047",
       "CVE-2022-22071",
       "CVE-2022-22265",
+      "CVE-2022-22674",
       "CVE-2022-22675",
       "CVE-2022-22706",
       "CVE-2022-22718",
@@ -7275,6 +7284,7 @@
       "CVE-2021-42287",
       "CVE-2022-1040",
       "CVE-2022-1471",
+      "CVE-2022-21919",
       "CVE-2022-22536",
       "CVE-2022-22948",
       "CVE-2022-22960",
@@ -7783,6 +7793,7 @@
     "opened_date": "2026-05-15",
     "evidence_cves": [
       "CVE-2009-1862",
+      "CVE-2010-5330",
       "CVE-2016-4523",
       "CVE-2021-28799",
       "CVE-2022-0028",
@@ -8755,6 +8766,7 @@
       "CVE-2021-44529",
       "CVE-2022-21445",
       "CVE-2022-22265",
+      "CVE-2022-22674",
       "CVE-2022-22947",
       "CVE-2022-23227",
       "CVE-2022-24816",
@@ -9377,6 +9389,7 @@
       "CVE-2021-40407",
       "CVE-2021-42278",
       "CVE-2022-0492",
+      "CVE-2022-21919",
       "CVE-2022-22047",
       "CVE-2022-22948",
       "CVE-2022-22960",
@@ -10172,6 +10185,7 @@
       "CVE-2022-22047",
       "CVE-2022-22071",
       "CVE-2022-22265",
+      "CVE-2022-22674",
       "CVE-2022-22706",
       "CVE-2022-22718",
       "CVE-2022-2294",
@@ -11642,6 +11656,7 @@
       "CVE-2010-0806",
       "CVE-2010-1428",
       "CVE-2010-2568",
+      "CVE-2010-5330",
       "CVE-2011-0411",
       "CVE-2014-2120",
       "CVE-2014-3931",
@@ -12799,6 +12814,7 @@
     "status": "open",
     "opened_at": "2026-05-18",
     "evidence_cves": [
+      "CVE-2010-5330",
       "CVE-2018-7445",
       "CVE-2019-0703",
       "CVE-2022-22947",
@@ -13513,6 +13529,7 @@
       "CVE-2022-0492",
       "CVE-2022-0543",
       "CVE-2022-1364",
+      "CVE-2022-21919",
       "CVE-2022-22954",
       "CVE-2022-29464",
       "CVE-2022-30190",