CVE-2022-21971 Exploit & Patch: Windows Runtime RCE Guide

If your vulnerability scanner just flagged CVE 2022 21971, you're probably staring at a list of Windows cumulative updates and wondering whether this one deserves special attention. It does. This vulnerability sits in the Windows Runtime layer, carries a remote code execution label, and shows up in the CISA Known Exploited Vulnerabilities Catalog. That last part matters. Exploitation has been confirmed in the field, and a public proof-of-concept makes the barrier to weaponization far lower than most organizations realize.

This guide consolidates what IT administrators, security analysts, and compliance teams actually need: what the bug is, which systems are exposed, how the attack chain works, and the fastest path to remediation. After fifteen years in vulnerability management and incident response, I've seen teams burn hours hopping between fragmented CVE pages, vendor bulletins, and threat reports. This is the consolidated answer I wish I could hand them when something like this lands.

What Is CVE-2022-21971? Inside the Windows Runtime Remote Code Execution Bug

Root Cause: An Uninitialized Pointer in prauthproviders

At its core, CVE-2022-21971 is a memory corruption flaw. The vulnerable code sits in a Windows Runtime component called prauthproviders, which handles authentication provider interactions within the broader Windows Runtime environment. When this component mishandles an uninitialized pointer, it can read or write to memory that was never properly set up—and that opens the door to attacker-controlled code execution.

Different references describe the problem in different words, which confuses a lot of readers. NVD and Rapid7 classify it under CWE-908, the "Access of Uninitialized Pointer" family. Microsoft's advisory phrases it as a "Windows Runtime Remote Code Execution Vulnerability." Both are describing the same underlying weakness; they're just using different taxonomies. When your vulnerability scanner reports one label and a threat intel feed reports the other, don't assume you're looking at two distinct bugs.

For a plain-language analogy: imagine handing a courier a delivery label that was never filled in. The courier doesn't know where to go, so they choose any address they happen to pull from a stack of old labels. If an attacker can seed that stack with their own address, they control where the package ends up. In memory-corruption terms, an attacker influences what's sitting in that uninitialized memory space to redirect execution flow toward their own payload.

Attack Vector and Exploitation Chain in WordPad and Office Word

The exploitation path documented in public research follows a familiar document-delivery chain. An attacker crafts a malicious document—in the tested cases, files opened through WordPad or Microsoft Word 2019—and delivers it to a target through normal distribution routes: phishing email, web downloads, or shared drives. When the victim opens the file, the application interacts with the Windows Runtime's prauthproviders component. That interaction triggers the uninitialized pointer condition, producing memory corruption that lets the attacker execute arbitrary code in the context of the currently logged-in user.

One critical nuance: this isn't a zero-click, no-interaction exploit. The CVSS v3.1 vector—CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H—yields a base score of 7.8 High precisely because local file access and user interaction are required. The WordPad path documented in the public PoC also involves a one-click confirmation before code execution proceeds. I've seen messaging around this vulnerability bounce between "critical remote exploit" and "requires clicking a file," and the truth sits in the middle.

For defenders weighing the "remote" label: an attacker sitting in another country can absolutely deliver a malicious file over the network. The user opens it, and code executes. The user-interaction requirement adds friction, but anyone who has seen a convincing phishing email knows that friction isn't a reliable defense. In the incident response engagements I've led, document-delivered malware clears that bar far more often than most executives expect.

Which Windows Versions Are Affected by CVE-2022-21971? A Complete Inventory

Affected Products at a Glance: Windows 10 Through Windows Server 2022

The vulnerable component isn't quarantined to a single Windows generation. Because prauthproviders is shared across the Windows Runtime, the issue ripples through nearly every mainstream desktop and server release supported at disclosure. The February 2022 Patch Tuesday cumulative updates addressed it across these product families:

Why Home and Enterprise Windows Systems Are Equally in Scope

A point that regularly gets lost in patch management meetings: consumer SKUs (Windows 10/11 Home, Pro, Pro Workstation) and enterprise SKUs all carry the same vulnerable binary. Patching one category while neglecting the other leaves a hole in your coverage. The same goes for Windows Server. Running a server role doesn't exempt you—if a user on an RDP session or terminal server opens a malicious document stored on a shared drive, the vulnerable path executes just as it would on a workstation.

Unsupported and end-of-life Windows versions that never received the February 2022 update remain exposed today. No patch will ever arrive for those systems, which means compensating controls or migration to a supported release are the only realistic options. I've walked into organizations that discovered, years after the fact, an air-gapped Windows 7 box quietly serving as a shared document repository. This CVE is precisely the kind of bug that punishes those oversights.

Exploitation Status: Is CVE-2022-21971 Actively Exploited and What Triggers Public Attacks?

CISA KEV, EPSS, and the February 2022 Timeline

The early timeline here is instructive. Microsoft shipped fixes on February 8, 2022, as part of its monthly Patch Tuesday release, and the CVE record appeared on NVD the following day. By the end of February, CISA had added CVE-2022-21971 to its Known Exploited Vulnerabilities Catalog, signaling confirmed exploitation. That's a narrow window between public disclosure and KEV inclusion—faster than typical for most vulnerabilities, which speaks to how quickly threat actors moved on this one. I recommend checking the CISA catalog entry for the latest status rather than relying on memory, since the agency updates entries with new dates and context from time to time.

The exploitation-likelihood statistics reinforce the urgency. The EPSS score for CVE-2022-21971 is approximately 0.54, placing it in the 99th percentile of all known vulnerabilities. To translate: if EPSS is a reasonable predictor, this CVE has a higher likelihood of being exploited in the wild than roughly 99% of everything else in the vulnerability corpus. That score alone should push this item to the top of your remediation queue, even if it's no longer breaking news.

Public PoC and the Risk of Weaponized Attacks

A public proof-of-concept emerged shortly after disclosure, reproducing code execution on Windows 10 and Windows 11 x64 builds through both the WordPad and Word 2019 paths. I won't detail the exploit mechanics here—defenders don't need that—but I'll explain why the PoC's existence changes the threat calculus.

Documented exploits collapse the talent barrier for attackers. Reproducing code execution from a well-written PoC requires a fraction of the skill needed to discover the vulnerability in the first place. Commodity malware operators, initial-access brokers, and even low-capability phishing groups can adapt a public trigger mechanism into their existing delivery pipelines. In red-team and purple-team exercises I've run, the time between a PoC hitting the public domain and it showing up in simulated intrusions is remarkably short.

One caveat worth drawing: "confirmed exploitation" per CISA's standard doesn't automatically mean mass internet scanning or broad ransomware distribution. It indicates observed attacks in real environments, often involving government or high-value networks. For an organization trying to prioritize, though, that distinction is largely academic. Once a CVE reaches KEV listing, treating the exposure as a probable breach is the only sound posture.

How to Patch CVE-2022-21971: Step-by-Step Microsoft Update Guide

Finding the Correct Cumulative Update for Your Build

First, identify the exact Windows version. The quickest way is a run dialog with winver, which displays your build and edition in a small popup. For something more automation-friendly, PowerShell's Get-ComputerInfo command returns the operating system version and build number in structured form.

Once you know the build, match it against the table earlier in this article. If you're managing a fleet, WSUS, Microsoft Configuration Manager, or your vulnerability management platform should already be mapping systems to the corresponding updates. A useful operational note: while the KBs published in February 2022 were the original fixes, Windows cumulative updates are incremental by design. The latest monthly rollup for your supported Windows version already includes the CVE-2022-21971 fix, so installing the most recent update is generally preferable to hunting down the February 2022 one specifically.

Installation and Verification Commands

Standalone systems can patch through Windows Update without ceremony. For enterprise environments, a more deliberate approach works better: stage the update in WSUS or Configuration Manager, pilot it on a representative set of endpoints, then expand the deployment. This avoids the classic failure mode where an update gets pushed to an entire fleet and promptly breaks a line-of-business application nobody tested against.

Verification doesn't require guesswork. The PowerShell command is:

Get-HotFix | Where-Object { $_.HotFixID -match "KB5010(342|345|351|354|386)" }

This returns the relevant February 2022 cumulative updates for the common affected builds if they're present on the system. Windows Update history under Settings > Windows Update > Update history provides a similar check through the GUI. For post-reboot confirmation, the Setup event log records successful installations (Event 19 under the Setup provider). In disconnected networks, the Microsoft Update Catalog supplies offline installers, but verify the file hash against Microsoft's published values before deploying—I've encountered more than one spoofed "KB" installer in the wild.

How to Mitigate CVE-2022-21971 When You Cannot Patch Immediately

Stop the Document-Based Attack Surface: Disable or Remove WordPad

The documented attack requires a user to open a crafted document in WordPad or Word 2019. The WordPad vector is the easier one to eliminate, because most organizations—and honestly, most individuals—don't genuinely need WordPad.

On Windows 11, you can remove WordPad entirely through Settings > Apps > Optional Features, or via DISM in scripted environments. Windows Server uses the same optional-features removal path. Microsoft's later deprecation and removal of WordPad from newer Windows releases reinforces what most administrators already knew: this is a legacy convenience, not a business-critical application. In every environment I've worked on over the past several years, no one ever told me their daily workflow broke because WordPad disappeared.

Word 2019 requires a more surgical approach, since Office is a legitimate business tool. Apply the latest Office and Microsoft 365 updates, verify that documents from the internet open in Protected View, and disable macros for content originating from untrusted sources. These layers don't eliminate the underlying Windows Runtime flaw, but they make the practical exploitation chain meaningfully harder.

Build Compensating Controls: Email Filtering, EDR, and Attachment Quarantine

Layered defenses matter most when patching is delayed. Because this vulnerability requires file delivery followed by user interaction, email and web gateways sit at an ideal chokepoint. Consider quarantining RTF and DOC attachments from external senders, and blocking password-protected archives if your business can tolerate the friction. Most enterprise email security gateways support rule sets for exactly this pattern.

Endpoint detection and response tools add another necessary layer. Exploitation of this CVE tends to produce identifiable process lineage: WordPad or Word spawning unexpected child processes, or document readers accessing memory regions that normal file processing never touches. EDR policies should flag document applications spawning PowerShell, rundll32, or script interpreters. That behavior pattern—a word processor launching an interactive shell—is anomalous in almost every legitimate workflow I've come across.

Detection and Validation for Security Operations Teams

How to Detect Exploitation Attempts in Your Windows Logs

Some CVEs ship with clean, deterministic event IDs that enable high-confidence detection. This one doesn't. Exploitation occurs inside WordPad or an Office process, and the resulting artifacts can resemble application crashes or legitimate document behavior. That reality forces a detection strategy built on broader behavioral patterns rather than a single signature.

Start with Windows Reliability and Application logs. Repeated crashes in WordPad or Microsoft Word (Event ID 1000 or 1001) warrant investigation, particularly when they occur after the user opened an unexpected RTF or DOCX file. One crash is not a signal. A pattern of crashes across multiple endpoints—or crash metadata linking back to a common document—is worth chasing.

Sysmon, if deployed, offers a stronger detection fabric. Process creation events (Event ID 1) can be filtered for document applications spawning shells or script hosts. A useful hunting baseline looks for this process tree:

WordPad.exe OR WINWORD.EXE
  └─ powershell.exe / rundll32.exe / cscript.exe / wscript.exe

Any instance of a document reader spawning an interactive shell is abnormal. If your EDR platform supports custom queries, that pattern is a solid starting point for a detection rule.

Confirm Your Patch Is Installed and Move Toward Compliance Checks

After updates deploy, run the Get-HotFix command across your estate to confirm coverage. For compliance-grade validation, use your vulnerability scanner to identify systems still reporting the CVE rather than trusting a sampling approach. Those scans should include laptops and RDS session hosts—the systems where users actually open documents—not only the server fleet.

For organizations under federal or contractual obligations, the CISA KEV catalog matters beyond good hygiene. Binding Operational Directive 22-01 requires US Federal Civilian Executive Branch agencies to remediate known exploited vulnerabilities by specified deadlines. Even outside the federal sector, cyber insurance underwriters and enterprise clients increasingly reference KEV membership as a baseline security metric. Treating this CVE as a two-week remediation target rather than a whenever-the-next-cycle-arrives item aligns with regulatory expectations and practical risk.

FAQ

What is CVE-2022-21971 in simple terms?

CVE-2022-21971 is a vulnerability in the Windows Runtime subsystem caused by an uninitialized pointer in the prauthproviders component. In practical terms, it allows an attacker to execute code on a victim's machine if the user opens a specially crafted malicious document. It's a memory corruption issue at the component level, not a self-propagating network worm.

Is CVE-2022-21971 actively exploited in the wild?

Yes. CISA added this CVE to its Known Exploited Vulnerabilities Catalog in February 2022, confirming that exploitation had been observed. A reliable public proof-of-concept also emerged that year, which increased the practical risk of weaponization by a broader range of attackers. Attack volumes have fluctuated over time, but the KEV designation keeps this on the list of vulnerabilities that federal agencies must remediate with urgency.

How do I find and install the correct fix for CVE-2022-21971?

First, run winver to identify your Windows build. Then match your version to the corresponding cumulative update KB from the February 2022 Patch Tuesday release. Alternatively, install the most recent cumulative update, which contains the fix along with all later patches. Use Windows Update for standalone systems or WSUS/Microsoft Configuration Manager for enterprise fleets. Verify with the Get-HotFix cmdlet or the Windows Update history page.

What happens if I cannot patch CVE-2022-21971 right away?

Layer your defenses. Remove or disable WordPad where it's not needed, apply the latest Office updates and enable Protected View, configure email gateways to quarantine suspicious document attachments, and ensure your EDR flags document processes spawning unexpected child processes. These controls don't replace patching, but they materially raise the difficulty for an attacker trying to use this flaw.

Why does the CVSS v3 severity display 7.8 if this is a remote code execution vulnerability?

Microsoft's "remote" designation refers to an attacker executing code on a machine other than their own—in this case, by delivering a file that runs locally. The CVSS vector accounts for the real-world constraints: the victim must open a local file (AV:L), and the attack requires user interaction (UI:R). Those factors bring the base score to 7.8 High rather than a network-native 9.8. The practical risk remains significant because phishing and social engineering routinely satisfy those requirements.

Conclusion

CVE-2022-21971 belongs to the category of vulnerabilities that keeps security teams employed: a known-exploited Windows Runtime remote code execution flaw from February 2022 that still lingers in late-patching environments and unsupported operating systems. The public proof-of-concept, the CISA KEV listing, and the EPSS 99th-percentile score combine to make an unambiguous case—this was never a CVE you could safely defer.

Your immediate actions, in order:

1. Patch all supported Windows systems within 48 to 72 hours using the most recent cumulative update.
2. Remove or disable WordPad on systems that don't need it.
3. Verify your EDR and SIEM would detect a WordPad or Word process spawning an unexpected child process.
4. Scan your environment to confirm the update is installed, including laptops and RDS session hosts—not just servers.

If you lack visibility into which Windows versions and installed KBs exist across your environment, that discovery gap is itself a finding. Run at least a one-time network scan querying installed updates and operating system versions, then produce a patching confirmation report for your operations team. And ask your SOC to hunt for anomalous WordPad.exe process trees across the entire estate before attackers find them first.