CISA’s required action for CVE-2023-36563 is to apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable. In practice, find every instance of Microsoft WordPad in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.
What the patching decision means for WordPad exposure
For CVE-2023-36563, the practical decision is not just “apply a patch.” It is whether any Microsoft WordPad installation can still be safely used under the vendor’s mitigation path, or whether the product must be removed from service. Because the flaw was used in the wild, treat every remaining instance as a live exposure until you confirm remediation or retirement.
Start with a full inventory of endpoints and servers that still include WordPad, then confirm whether each system can accept the vendor update or a documented mitigation. If you cannot make the configuration safe, the correct fallback is to discontinue use, not to leave the application reachable and hope it is not targeted.
Operationally, this is a vulnerability-management problem with an application-retirement branch. The right outcome is a verified state change on every asset, not a general claim that “patching is underway.” That means you need to know where WordPad exists, which systems were updated, and which systems were removed from exposure because they could not be fixed in place. The same prioritisation logic used for exploited vulnerabilities applies here, so a guide to zero-day and actively exploited vulnerabilities is the right place to anchor emergency triage and post-patch checking.
How to mitigate when you cannot patch immediately
If patching is delayed, the goal is to reduce reachable attack surface around WordPad and make any remaining exposure as narrow as possible. That usually means limiting who can launch it, removing unnecessary internet-facing access paths, and preferring a controlled workaround over continued open availability. If the mitigation depends on user behaviour alone, treat it as temporary and weak.
Use the vendor’s documented mitigation exactly as written, because ad hoc workarounds often miss the condition that made the flaw exploitable. If the vendor has no practical mitigation for a given environment, discontinue use of the product on that system. For broader remediation discipline, align the response with the same controls used for ongoing vulnerability tracking in the vulnerability management guide, especially asset scoping, exception handling, and verification.
Where exposure is hard to eliminate, validate whether downstream systems or users can still invoke WordPad indirectly through file associations, remote desktop sessions, software bundles, or legacy workflows. A mitigation that leaves an indirect launch path intact is often only partial containment. In practice, retired or isolated functionality is safer than “patched but still broadly reachable” functionality when the product is no longer a business requirement.
What to check after remediation
After patching or mitigation, assume the next question is whether the flaw was already used against you. Review endpoint, application, and central logs for unusual document-opening behaviour, suspicious child processes, unexpected user activity around WordPad, and any signs that a malicious document or payload was introduced before remediation. If logs are sparse, compensate by checking adjacent telemetry from EDR, mail gateways, file shares, and user activity records.
Post-remediation review matters because exploited disclosure flaws often leave only weak evidence unless you already had strong monitoring in place. If you find signs of suspicious activity, treat the event as a compromise-assessment problem, not just a patching ticket. In a case like this, one useful analogue is CitrixBleed exploitation 2023, where the main lesson was that exploitation can precede visible impact and session or access abuse may persist after the vulnerability is closed.
Because the flaw was observed in the wild, also verify whether the same endpoints had other signs of post-exploitation activity, such as new local accounts, unexpected persistence, or abnormal outbound connections. If WordPad was only one step in a broader intrusion chain, patching alone will not resolve the incident.
Risk and Threat Considerations
Information disclosure flaws are dangerous because they can expose data that users assumed was local, transient, or unrecoverable. When the vulnerable component is a common desktop tool, the risk expands from a single document to the wider endpoint estate, especially if the product remains present long after it stopped being a business requirement.
Failure mechanism: An attacker triggers the flaw through a crafted file or workflow, causing the application to reveal information that should not have been disclosed, which can support follow-on intrusion, targeting, or data theft.
Impact: The exposed information can enable reconnaissance, reveal sensitive content, or help an attacker move from opportunistic exploitation to broader compromise, especially if the affected endpoint is still trusted by the rest of the environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | CVE remediation and verification require tracked flaw handling on affected endpoints. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Post-patch log review is needed to look for earlier exploitation signs. | |
| Recommendation — Track, remediate, and verify the WordPad flaw on all affected systems. Review logs for evidence of prior exploitation after remediation. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The response depends on identifying, prioritising, and remediating exposed WordPad installations. |
| CIS-8 — Audit Log Management | The answer explicitly calls for checking logs for signs of prior compromise. | |
| Recommendation — Inventory, prioritise, and remediate all systems still exposed to the vulnerability. Collect and review relevant logs to confirm whether exploitation occurred before remediation. | ||
| NIST CSF 2.0 | PR.IP-12 — Vulnerability Management | The question is about patching or mitigating a known exploited vulnerability. |
| Recommendation — Apply vulnerability management processes to patch or mitigate the affected WordPad deployment. | ||
Practitioner Guidance
What to prioritise: Triage by exposure, not by convenience. Systems that still have WordPad installed and can process untrusted content should be first in line, followed by systems where patching is not possible and the product must be removed or isolated.
What to verify: Do not stop at “update applied.” Confirm the vulnerable product is actually present, the mitigation is the vendor’s documented one, and the endpoint can no longer be used through indirect launch paths or stale deployments.
Practitioner takeaway: For an actively exploited disclosure flaw, the decisive question is whether the affected software is still reachable in your estate; if it is, remediation is incomplete until the patch, mitigation, or retirement is verified.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2024-29059 (Microsoft .NET Framework Information Disclosure)?
- How do you patch or mitigate CVE-2021-31196 (Microsoft Exchange Server Information Disclosure)?
- CVE-2023-36563 (Microsoft WordPad Information Disclosure)
- How do you patch or mitigate CVE-2023-32049 (Microsoft Windows Defender SmartScreen Security Feature Bypass)?