Patch CVE-2025-55679: Windows Kernel Local Info Disclosure (High Priority)

Microsoft has published an advisory and a security update for CVE-2025-55679, a Windows Kernel information‑disclosure vulnerability that permits a local actor to obtain sensitive system memory under certain conditions — and administrators should treat it as a high-priority remediation for multi-user and shared hosts.

Background / Overview​

CVE-2025-55679 was recorded in the Microsoft Security Update Guide on October 14, 2025 and classified as a Windows Kernel memory information disclosure caused by improper input validation. Public vulnerability trackers list a CVSS v3.1 base score in the Medium range (5.1) with an attack vector of Local (requires local interaction) and a confidentiality impact rated high.
Microsoft’s Update Guide remains the canonical mapping between the CVE and the security update(s) — administrators should consult the Update Guide for the exact KB number(s) and the builds that receive the fix before automating any remediation across their estates. This advisory is deliberately terse about root-cause details (a common vendor practice for kernel info‑leaks), so public technical write‑ups are limited or absent at disclosure.
Why this matters now: information‑disclosure bugs in kernel components frequently act as reconnaissance primitives for follow‑on exploitation. Leaked kernel addresses, token fragments, or configuration state can materially reduce the cost and increase reliability of local privilege‑escalation chains, sandbox escapes, or post‑compromise lateral movement. Given that CVE-2025-55679 is accessible only from a local attacker context, the highest operational risk is to multi‑user systems (VDI/RDP hosts, shared desktops), developer build machines, and any host where untrusted code may run locally.

---

What Microsoft and public trackers say right now​

• Microsoft recorded CVE‑2025‑55679 in the Security Update Guide with the high‑level description: improper input validation in Windows Kernel allows an unauthorized attacker to disclose information locally. Administrators should use that MSRC entry to find the authoritative KB-to-build mapping for their OS SKUs.
• Independent public trackers mirror the vendor entry and show the CVSS v3.1 base score of 5.1 (Medium) with a confidentiality impact. The published vectors indicate local attack only and no confirmed public proof‑of‑concept or in‑the‑wild exploitation at disclosure time.
• Multiple community summaries and analyst write‑ups emphasize that Microsoft’s short advisory intentionally withholds deep technical details, so defenders must assume a realistic exploitation model for kernel leaks and prioritize patching and compensating controls accordingly.

These points are high‑confidence operational facts: the CVE is vendor‑recorded, patches have been released per the vendor, and the attack model is local information disclosure rather than remote code execution. Where public technical specifics (exact IOCTLs, routine names, or memory regions leaked) are missing, that is a conscious choice to limit exploitability at disclosure; those gaps are flagged and must be treated with caution.

---

Technical summary — what the vulnerability class usually looks like​

Because Microsoft’s advisory is short on implementation detail, analysts rely on established kernel‑mode information‑disclosure patterns to infer likely behaviors. Common root causes in this class include:

• Uninitialized or partially‑initialized buffers returned to user mode, exposing leftover kernel or process memory.
• Incorrect length/status reporting from driver IOCTLs or read/write handlers, where the driver reports more bytes than it populated and stale kernel memory is copied into user buffers.
• Insufficient parameter validation or bounds checks, enabling out‑of‑bounds reads that include neighboring kernel memory.
• Transient write windows (TOCTOU) where kernel code briefly writes sensitive pointers into a user buffer and then sanitizes them, but a racing usermode thread samples the buffer and captures the secret.

Practical exploitation of a kernel info‑leak is often straightforward once the vulnerable interface is known: a low‑privilege process repeatedly triggers the vulnerable path (e.g., an IOCTL or query), dumps returned buffers, and searches for recognizable pointers, token fragments, GUIDs, or session artifacts. Even small fragments of kernel memory can defeat KASLR or reveal structure layouts that are extremely useful for constructing reliable elevation‑of‑privilege exploits.
Note: The above inference is grounded in long‑observed patterns across Windows kernel advisories; for CVE‑2025‑55679 specifically Microsoft’s public text indicates improper input validation and local information disclosure, but does not publish the exact low‑level cause. Treat vendor messaging as authoritative for classification and remediation mapping; treat technical inferences as prudent defensive assumptions until Microsoft or third‑party researchers publish confirmatory analysis.

---

Affected systems, severity, and exploitable conditions​

• Affected components: Microsoft lists this as a Windows Kernel vulnerability; the vendor advisory is authoritative for which Windows releases and builds are affected. Administrators must consult the Update Guide entry for CVE‑2025‑55679 to extract the precise KB numbers for each SKU and build before deploying updates at scale.
• Attack vector: Local — attacker must have a process running on the target system or otherwise be able to interact locally with the vulnerable kernel interface.
• Privileges required: Public summaries indicate low or no elevated privileges are often sufficient for this class of leak; do not assume administrative access is required. A non‑privileged user or sandboxed process may be able to trigger the leak in many real‑world scenarios.
• CVSS & impact: Public trackers show a CVSS v3.1 base score around 5.1 (Medium) with confidentiality impact rated High, reflecting information disclosure without proven direct integrity or availability effects. The published vector string indicates Attack Complexity may be elevated in some cases (AC:H) but the practical exploitation complexity depends on the precise implementation.
• Exploitation evidence: At the time the advisory was published there was no public proof‑of‑concept and no widely reported in‑the‑wild exploitation. That reduces immediate mass‑exposure risk but is not proof of safety; historically, PoCs and weaponized exploits for kernel info‑leaks often follow public disclosure.

Operational takeaway: prioritize patching hosts where local access is probable (VDI, RDP hosts, developer/build systems, multi‑user lab machines). Treat unpatched shared systems as high‑value targets for attackers who already hold a foothold.

---

Immediate remediation and mitigation steps (practical playbook)​

The vendor fix is the authoritative remediation; implement it per your change control and test‑ring procedures. In parallel, apply compensating controls to reduce exposure while patching proceeds.

• Identify affected systems and map KBs
• Consult the Microsoft Security Update Guide entry for CVE‑2025‑55679 to get the exact KB identifiers and per‑SKU applicability. Confirm mapping in an interactive browser or the Microsoft Update Catalog before mass deployment.
• Patch (primary remediation)
• Test the Microsoft update(s) in a representative pilot ring that includes apps interacting with camera/driver subsystems or other kernel-level integrations relevant to your estate.
• Roll out the update urgently to prioritized systems: domain controllers and admin workstations are high priority, followed by VDI/RDP hosts, multi‑user servers, developer/build systems, and any endpoints that accept user‑provided binaries.
• Short‑term compensating controls (when immediate patching is impossible)
• Restrict local user access and tighten least privilege policies.
• Limit or block USB device use on high‑value hosts if device‑interaction is a plausible attack vector (for UVC/USB‑related leaks); use endpoint controls to enforce device allow‑lists.
• Enable Memory Integrity (HVCI) where hardware allows; enable Microsoft’s Vulnerable Driver Blocklist and enforce driver signing policies. These mitigate many attack paths that depend on loading or running unsigned / vulnerable kernel drivers.
• Use application control (WDAC or AppLocker) to prevent execution of untrusted or unknown binaries in user contexts.
• Detection and hunting (during rollout)
• Add EDR rules to detect unusual, repeated calls to kernel query APIs or high-frequency IOCTL invocations from non‑privileged processes. Hunt for processes that repeatedly call token/query routines or sample returned buffers.
• Monitor for indicators of post‑exploit behavior: unexpected privilege grants, token impersonation events, creation of services by low‑privilege accounts, and unusual driver loads. Retain full memory and EDR artifacts when an incident is suspected.
• Validate post‑patch
• Confirm successful installation of the KBs across the estate via your patch management tooling (WSUS/ConfigMgr/Intune) and through the Update Catalog fingerprints. Test that no driver rollbacks occurred and that camera/video stack functionality is intact where relevant.

---

Detection indicators & forensic guidance​

Because the vulnerability class exposes sensitive memory fragments rather than directly executing code, detection is necessarily behavioral:

• Watch for processes making repeated, high‑frequency device or kernel queries (e.g., repeated IOCTLs, frequent NtQueryInformationToken() or similar calls) that correlate with user processes that normally don’t exercise such interfaces.
• Look for anomalous token changes or unexpected privilege escalations in security telemetry; leaked kernel tokens or pointers are commonly used as primitives to facilitate token manipulation and privilege escalation.
• If exploitation is suspected, capture volatile memory (full RAM image) and preserve EDR logs immediately. Memory forensics can reveal kernel pointers, token manipulation, process memory that an attacker exfiltrated, or artifacts of race exploits.

Note: Because vendors typically avoid publishing detailed exploit recipes at disclosure, the earliest reliable detection indicators often come from vendor technical notes or independent research publishings — monitor reputable vendor and research feeds for follow‑on technical analysis and PoC disclosures.

---

Risk analysis — where the real danger lies​

• High‑risk environments: VDI/RDP multi‑user hosts, public kiosks, shared developer/build servers, and CI systems where untrusted code or many different users execute on the same kernel. In these settings a local info leak can quickly be turned into full‑host compromise when combined with other bugs.
• Moderate‑risk environments: single‑user desktops whose users may install untrusted software, or servers that host user‑submitted workloads. Attackers often use info leaks to speed lateral movement in enterprise breaches.
• Low‑immediate‑risk environments: isolated, air‑gapped systems with strict local execution controls and no untrusted local code paths. Still, if those systems host long‑lived credentials or keys, even low‑frequency leaks can be consequential.

Longer term, kernel info‑leaks are attractive to sophisticated attackers because they are reusable primitives: once an adversary has a reliable way to learn kernel layout or extract tokens, that capability can be reused across multiple campaigns and combined with new write primitives as they appear in the wild. The existence of CVE‑2025‑55679 therefore lowers the bar for local privilege escalation attacks on unpatched hosts.

---

Verification notes and what remains unconfirmed​

• Confirmed: Microsoft recorded CVE‑2025‑55679 in the Security Update Guide and has supplied a security update; public trackers mirror that classification as a Windows Kernel information disclosure and list a CVSS base score in the Medium range.
• Not confirmed / unverifiable from the public advisories at disclosure: the exact vulnerable routine, minimal exploit trigger (IOCTL ID, syscall name), and the precise kernel memory regions leaked. Microsoft’s short advisory intentionally omits technical details to reduce exploitability risk; treat these as unknown until further public research or vendor technical notes appear.
• No public PoC or reliable in‑the‑wild exploitation reports were visible at the time the vendor advisory was published, but historical precedent shows PoCs and weaponization may appear rapidly after disclosure. Treat the absence of PoCs as a lower—but not zero—immediate threat.

Because vendor pages can be delivered via dynamic, client‑side web apps, some third‑party mirrors may lag or omit KB mappings; administrators must therefore validate KB → build mappings in an interactive browser or by using the Microsoft Update Catalog.

---

Long‑term recommendations for hardening kernel attack surface​

• Maintain strict driver hygiene: enforce signed drivers only, maintain and apply the Microsoft Vulnerable Driver Blocklist, and use controlled driver deployment processes.
• Deploy Memory Integrity (HVCI) broadly where hardware permits; it raises the bar for kernel exploitation by enforcing control‑flow integrity at the hypervisor/firmware level.
• Use application control (WDAC/AppLocker) to reduce the chance of untrusted local binaries providing the foothold attackers need to chain into info‑leak exploitation.
• Segment multi‑tenant and multi‑user workloads: separate developer/build systems, VDI hosts, and shared lab machines from sensitive infrastructure and reduce the pool of users who can execute code on those hosts.
• Invest in robust EDR telemetry that captures kernel events, driver loads, and memory‑related anomalies so that any subsequent research publications or PoCs can be rapidly detected and investigated in your environment.

---

Final assessment and practical verdict​

CVE‑2025‑55679 is a vendor‑acknowledged, locally exploitable Windows Kernel information‑disclosure vulnerability with a medium CVSS score and a high confidentiality impact. The immediate operational imperative is simple and unchanged by nuance: patch promptly, validate KB mappings per SKU, and prioritize systems where local access is a realistic threat.
At the same time, defenders should not rely solely on the absence of public PoCs as evidence of safety. Kernel info‑leaks routinely serve as enablers for more severe attacks when combined with other bugs; implement compensating controls (HVCI, driver blocklists, application control) and tune telemetry for suspicious kernel‑level behavior while you deploy Microsoft’s fixes.
Administrators and security teams should treat the Microsoft Security Update Guide as the authoritative source for KB→build mappings and track independent analyst write‑ups for any follow‑on technical disclosures. Where public technical detail is missing, assume a conservative posture: assume the leak is actionable for attackers with local code execution and prioritize the patch accordingly.

---

CVE‑2025‑55679 is a reminder that even “information‑disclosure” vulnerabilities in kernel code can be high‑impact because they change attacker economics: what was once a fragile, timing‑dependent exploit suddenly becomes a reliable building block for privilege escalation when small memory fragments are consistently obtainable. The operational answer is straightforward — confirm the Microsoft KBs for your builds, test the update in a pilot ring, and push the vendor fix to prioritized hosts without delay while applying the recommended compensating controls.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center

 

[ChatGPT]

Microsoft has published a security advisory and an accompanying update for CVE-2025-55679, a Windows Kernel information disclosure vulnerability that allows a local actor to obtain sensitive kernel memory under specific conditions — administrators should treat it as an urgent remediation item for multi-user and shared hosts.

Background​

CVE-2025-55679 is recorded in the Microsoft Security Update Guide as a Windows Kernel — Memory Information Disclosure issue caused by improper input validation, and Microsoft has released updates that address the defect. Public vulnerability trackers and community synopses mirror Microsoft’s classification and list a CVSS v3.1 base score of 5.1 (Medium) with a confidentiality impact rated high and an attack vector of Local (the attacker must run code or otherwise interact locally with the vulnerable interface).
This advisory is deliberately terse on low-level technical specifics — a common vendor practice for kernel information‑leak bugs — so public technical write-ups and proof‑of‑concept (PoC) code are limited or absent at disclosure time. Defenders must therefore combine the vendor’s canonical guidance with conservative operational assumptions about how kernel info leaks are typically exploited.

---

Why this matters: the operational threat model​

Information‑disclosure vulnerabilities in the kernel are often understudied by non-specialists because they do not immediately provide remote code execution. That framing understates their real-world danger. Kernel memory leaks are reconnaissance primitives that can dramatically lower the effort needed to build reliable local privilege escalation, sandbox escapes, or targeted post‑compromise activity.

• Small fragments of kernel memory — pointers, token fragments, GUIDs, or configuration state — can defeat Kernel Address Space Layout Randomization (KASLR) and reveal internal object layouts that make subsequent exploitation far more deterministic.
• Once an attacker reliably recovers kernel layout or token artifacts from a local process, they can combine that information with other local bugs, unsigned drivers, or misconfigurations to escalate privileges to SYSTEM or escape sandboxes.

Practical high‑risk targets include:

• Multi‑user desktops, Terminal Server/RDS/VDI hosts, and kiosks where multiple accounts (including untrusted users) can run code locally.
• Developer build machines and workstations that host untrusted or third‑party toolchains.
• Machines that accept untrusted devices (USB peripherals, webcams) or where local processes routinely call kernel interfaces (media subsystems, cloud file mini-filters). fileciteturn0file10turn0file13

---

What Microsoft and public trackers say (verification)​

Microsoft’s Security Update Guide is the authoritative source for the CVE description, affected SKUs, and the mapping from CVE → KB(s) → OS builds; administrators should always consult it to extract the exact update package(s) they must deploy.
Independent vulnerability mirrors and community summaries reproduce the vendor’s high-level description and operational advice and list the same numeric CVSS rating and local attack vector. Those independent entries corroborate the vendor messaging while highlighting that vendor advisories intentionally withhold exploitation-level detail. fileciteturn0file0turn0file1
Notable, high-confidence facts:

• Existence: Confirmed (Microsoft recorded CVE‑2025‑55679 in the Security Update Guide and released updates).
• Attack vector: Local only — attacker must be able to run code or call the vulnerable kernel interface on the host.
• Public exploit status: No widely published PoC or confirmed in‑the‑wild exploitation at disclosure time, but absence of PoC is not proof of safety.

If your patch automation or ticketing references third‑party CVE mirrors, verify the KB mapping against Microsoft’s Security Update Guide or the Microsoft Update Catalog before declaring systems remediated; inconsistent CVE→KB mappings are a common operational error during rapid rollouts.

---

Technical context — what we can infer without vendor detail​

Microsoft’s public text cites improper input validation in kernel code as the root classification. When vendors publish such terse descriptions for kernel info‑leaks, defenders infer likely technical patterns from historical, well‑documented classes of kernel information disclosures:

• Uninitialized or partially initialized buffers returned to user mode, exposing leftover kernel memory.
• IOCTL or read/write handlers that report a larger buffer length than was filled, causing stale kernel bytes to be copied to user buffers.
• Insufficient parameter validation or bounds checks enabling out‑of‑bounds reads that include adjacent kernel memory.
• Transient TOCTOU windows where the kernel writes a secret into a buffer and later zeroes it, but a racing usermode thread reads the buffer in between. fileciteturn0file1turn0file6

These are inference patterns grounded in past advisories and public analysis — they are not vendor-confirmed specifics for CVE‑2025‑55679. Where Microsoft does not name a driver, IOCTL, or routine, those details must be treated as unverified until Microsoft or external researchers publish them.

---

Realistic exploitation paths and attacker economics​

A compact, realistic attack chain that starts from a kernel info‑leak looks like this:

• Attacker obtains a local foothold (malicious app, compromised account, malicious USB device, sandbox escape).
• The attacker triggers the vulnerable kernel interface repeatedly (IOCTL, API call, device interaction) to collect output buffers.
• The attacker scans returned buffers for recognizable patterns — kernel addresses, token structures, GUIDs, or cryptographic artifacts — and uses them to defeat KASLR or craft targeted payloads.
• With kernel layout and token fragments known, the attacker combines the information with a local write primitive, vulnerable driver, or logic flaw to escalate privileges to SYSTEM. fileciteturn0file2turn0file6

Even if the leak alone does not directly yield top‑level secrets, it changes attacker economics — exploits that once required extensive heap grooming or fragile timing can become far more reliable and automatable once memory layout is known.

---

Patch, mitigate, and detect — prioritized operational playbook​

Patching is primary: map CVE‑2025‑55679 to its vendor KB(s) using the Microsoft Security Update Guide and deploy the updates according to standard staged rollout practices (pilot → canary → full). Test compatibility on representative hosts before broad deployment to avoid surprise regressions.
Where immediate patching is not possible, apply compensating controls and detection hardening:

• Enable and enforce HVCI / Memory Integrity where supported; it raises the cost of kernel tampering and can block unsigned kernel components.
• Use the Microsoft Vulnerable Driver Blocklist to prevent known‑bad or unsigned drivers from loading.
• Prioritize patching and tightened controls for VDI/RDP hosts, admin workstations, build servers, and shared machines that accept untrusted code.
• Restrict interactive logons and reduce the exposure surface for hosts that do not need GUI or device attachments.

Detection and hunting suggestions:

• Search EDR telemetry for repeated calls to uncommon IOCTLs, anomalous use of driver device objects, or high-frequency queries that attempt to enumerate kernel memory.
• Monitor for dwm.exe crash clusters, unsigned kernel module loads, or sudden DLL/driver injections into processes that handle device or media stacks; these are known indicators in kernel‑mode issues tied to graphics/audio/video subsystems. fileciteturn0file3turn0file10
• Hunt for unexpected kernel pointers or GUIDs appearing in user‑space logs, debug output, crash dumps, or application diagnostics. Even partial pointer leaks are actionable intelligence for attackers.

Patch deployment checklist (recommended):

• Query Microsoft Security Update Guide for CVE‑2025‑55679 and extract KB number(s) for every OS SKU in your estate.
• Test the specific update(s) in a pilot ring (24–72 hours recommended for server roles).
• Validate driver and GPU compatibility on canary devices (driver regressions commonly appear after kernel updates).
• Roll out via WSUS/ConfigMgr/Intune with compliance reporting and rollback plans.

---

Detection recipes and evidence to collect​

When hunting for exploitation attempts or verifying a remediation window, collect and analyze the following artifacts:

• Kernel memory dumps and crash dumps captured during suspicious activity; search for leaked pointers or token structures.
• EDR traces that show high-frequency IOCTL invocations to lesser-known drivers or repeated calls to documented kernel interfaces shortly before an escalation attempt.
• Event logs showing unsigned or unexpected driver loads and device attach/detach events that coincide with anomalous user processes.
• Network telemetry that could indicate lateral movement after a local privilege gain (new SMB sessions, abnormal RPC calls). While the flaw itself is local, its aftermath is often lateral movement.

If any suspicious traces are found, preserve full forensic evidence: full memory images, EDR captures, and a timeline of user activity. Treat potential exploit evidence as high priority for incident response teams because kernel info leaks are frequently used as stepping stones to escalate privileges and achieve persistence.

---

Strengths of Microsoft’s disclosure and where it falls short​

Strengths:

• Microsoft acknowledged the CVE in the Security Update Guide and shipped fixes, which is the most important step for defenders: the vendor-provided patch is the canonical remediation path.
• The advisory’s brevity is defensible from a risk‑management standpoint: withholding deep exploit detail reduces the immediate weaponization risk while administrators deploy fixes.

Limitations and operational gaps:

• The lack of low-level technical detail (driver names, IOCTLs, buffer behaviors) forces defenders to rely on inference and conservative countermeasures rather than targeted detection signatures. This increases operational workload and the risk of missed telemetry in the wild.
• Public CVE mirrors sometimes show discrepancies in CVSS scoring or affected builds; relying on those mirrors without confirming against the Security Update Guide can lead to incomplete remediation. Administrators must verify KB mappings directly from Microsoft.

---

Risk assessment and prioritization guidance​

CVE‑2025‑55679’s numeric CVSS base score of 5.1 (Medium) understates the situational risk in many environments because the real impact depends heavily on where local code execution is possible.

• High priority to patch: RDS/VDI hosts, developer workstations, shared desktops, build servers, and systems that accept USB or webcam devices. These hosts have realistic local attack surfaces and, if left unpatched, allow adversaries to rapidly chain the info leak into privilege escalation. fileciteturn0file10turn0file13
• Moderate priority: Standalone endpoints that do not accept untrusted code or devices and that sit behind strong perimeter defenses. Still patch promptly, but prioritize the high‑exposure classes first.
• Low priority: Isolated air‑gapped systems with no accountable local access. Even here, apply updates during the next maintenance window to close the attack window.

Operationally, treat absence of public PoC as temporary relief, not as clearance to delay patching. Historically, kernel info leaks are weaponized quickly once researchers publish exploit details or reverse‑engineers find the vulnerable interface.

---

Unverified claims and cautionary notes​

• Any specific claims about exact IOCTL numbers, driver filenames, or routine names related to CVE‑2025‑55679 are unverified unless published by Microsoft or an independent researcher who demonstrates the vulnerability. Public advisories for this CVE do not include those low‑level identifiers at disclosure. Treat unlabelled technical specifics from forums or social posts as unconfirmed until corroborated. fileciteturn0file1turn0file11
• The CVSS score and attack vector reported by third‑party mirrors match Microsoft’s high‑level classification; however, CVSS alone can fail to capture the operational urgency in environments where local access is common (VDI, multi‑tenant hosts). Always combine the numeric score with asset‑specific threat modeling. fileciteturn0file0turn0file18

---

Final assessment — practical verdict for administrators​

CVE‑2025‑55679 is a vendor‑acknowledged, locally exploitable Windows Kernel information‑disclosure vulnerability that requires immediate attention in environments where local code execution or device interaction is plausible. Microsoft’s security update is the authoritative remediation; map the CVE to the vendor KB(s) for your exact build and deploy updates using a tested, staged rollout.
Short tactical checklist:

• Confirm the KB(s) for CVE‑2025‑55679 in the Microsoft Security Update Guide and schedule patching for prioritized hosts first.
• Where patching will be delayed, enable HVCI, enforce the Vulnerable Driver Blocklist, and limit interactive logons on exposed hosts. fileciteturn0file11turn0file2
• Run focused EDR hunts for repeated IOCTL usage, dwm.exe crash clusters, unsigned driver loads, and any anomalous kernel pointer disclosures. Preserve forensic evidence for suspected exploitation. fileciteturn0file3turn0file2

The practical truth: information‑disclosure bugs in kernel components are often the reconnaissance phase of more severe attacks. Treat this CVE as confirmed and actionable — patch promptly, harden compensating controls, and tune detection to reduce the window of opportunity for adversaries to weaponize leaked kernel state. fileciteturn0file2turn0file10

---

CVE‑2025‑55679 represents a timely reminder that even vulnerabilities classified as information disclosure merit high operational priority when they affect kernel‑mode code. The vendor‑published fix is the single most effective remediation; rapid, validated deployment combined with the compensating controls and detection measures outlined above will materially reduce organizational risk. fileciteturn0file10turn0file1

---

Source: MSRC Security Update Guide - Microsoft Security Response Center