Microsoft Paint Remote Code Execution Flaw: Patch Confusion Resolved — Detection and Remediation Guide for Defenders

Microsoft Paint is not the application your threat model worried about this quarter. It ships on every supported version of Windows, it's rarely inventoried as attack surface, and it almost never appears in a patch prioritization meeting. That's exactly why last month's disclosure of a remote code execution vulnerability in Microsoft Paint — followed by weeks of confusing messaging about whether a fix actually existed — should get your attention now.

Per Dark Reading's reporting, Microsoft disclosed the Paint vulnerability but left defenders in an ambiguous position: the initial communication did not make clear whether the issue had been patched, which builds were protected, or what defenders should do in the interim. That ambiguity has now been resolved — Microsoft has shipped a fix — but the episode is a textbook case study in how patch-confusion windows create real operational risk. Attackers read the same disclosures we do, and the gap between "vulnerability disclosed" and "patch confirmed deployed" is where exploitation happens.

Every organization running Windows endpoints with Paint installed (which is effectively all of them, since mspaint.exe is an inbox Windows component and also distributed via the Microsoft Store) should treat this as a patch-verification task this week, not next cycle.

Technical Analysis

What We Know

• Affected component: Microsoft Paint (mspaint.exe), an inbox Windows application also serviced through the Microsoft Store on Windows 10 and Windows 11.
• Vulnerability class: Remote code execution. In practical terms, this class of flaw in a file-parsing application like Paint typically requires the user to open a crafted image file. The "remote" in RCE refers to the attacker's ability to deliver the malicious payload from afar — via email attachment, malicious download, or a file shared through collaboration platforms — not that Paint listens on a network port.
• Attack chain (defender's view): The realistic exploitation path is a social engineering lure delivering a weaponized image file, the user opening it in Paint (either deliberately or because Paint is the default handler for the file type), and arbitrary code executing in the context of that user. From there, expect the standard post-exploitation playbook: child process spawning for reconnaissance, persistence establishment, and credential access.
• Exploitation requirements: User interaction — the victim must open the malicious file. No authentication bypass, no pre-auth exposure. This makes it a phishing-delivered threat in practice, which means your email gateway and user population are the first control layers, and the endpoint is the last.
• Exploitation status: At the time of the disclosure covered in this reporting, there was no confirmed widespread in-the-wild exploitation. However, the disclosure-then-confusion sequence means technical details have been circulating publicly for weeks. Treat public disclosure of an RCE in a ubiquitous, file-parsing application as a pre-exploitation clock ticking. RCEs in default-installed Windows components with public technical details historically move to PoC and weaponization quickly.

Why the Confusion Matters Operationally

The patch-messaging ambiguity created two distinct failure modes I've seen burn organizations before:

1. False confidence: Teams assumed Patch Tuesday coverage included the fix, closed their internal tracking ticket, and never verified.
2. False deprioritization: Teams assumed no patch existed, filed it as "monitoring," and moved on — and then never revisited when the fix quietly shipped.

Both failure modes end the same way: an unpatched endpoint fleet weeks after a working fix is available. This is why patch verification — not patch assumption — has to be a scripted, auditable step.

Detection & Response

Because exploitation requires code execution flowing through mspaint.exe, your highest-fidelity detection logic centers on Paint spawning child processes and Paint performing anomalous network activity. Legitimate Paint usage almost never does either. These are low-noise, high-signal detections that a veteran SOC analyst can actually run in production.

Sigma Rules

---
title: Microsoft Paint Spawning Child Process
id: 3f8a1c92-7b4e-4d51-9a26-8e1f2c3d4b5a
status: experimental
description: Detects mspaint.exe spawning any child process, consistent with post-exploitation behavior following successful exploitation of a file-parsing RCE in Microsoft Paint. Paint has no legitimate reason to spawn child processes in normal operation.
references:
  - https://www.darkreading.com/application-security/microsoft-rce-bug-windows-paint-confusion
  - https://attack.mitre.org/techniques/T1203/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1203
  - attack.t1059
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    ParentImage|endswith: '\mspaint.exe'
  filter_known:
    Image|endswith:
      - '\mspaint.exe'
  condition: selection and not filter_known
falsepositives:
  - Rare; accessibility tools or enterprise shell integrations may interact with Paint. Investigate any hit.
level: high
---
title: Microsoft Paint Outbound Network Connection
id: 9c2e7b14-5a6d-4f83-b1e7-2d4a6c8e0f12
status: experimental
description: Detects mspaint.exe initiating an outbound network connection. Paint is a local image editor and does not legitimately establish network connections in standard use; such activity may indicate payload retrieval or C2 following exploitation.
references:
  - https://www.darkreading.com/application-security/microsoft-rce-bug-windows-paint-confusion
  - https://attack.mitre.org/techniques/T1071/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.command_and_control
  - attack.t1071
  - attack.t1105
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    Image|endswith: '\mspaint.exe'
    Initiated: 'true'
  condition: selection
falsepositives:
  - Microsoft Store telemetry or update checks on some builds may generate rare hits; validate destination against Microsoft service ranges before tuning.
level: high
---
title: Suspicious Image File Written to User-Writable Locations Followed by Paint Execution
id: 5d1a9e36-2c8b-4f47-a3d9-6b7c1e5f8a24
status: experimental
description: Detects execution of mspaint.exe with a command line referencing image files in temp, downloads, or appdata paths — a common delivery location for phishing-borne malicious image files targeting document/image parser vulnerabilities.
references:
  - https://www.darkreading.com/application-security/microsoft-rce-bug-windows-paint-confusion
  - https://attack.mitre.org/techniques/T1204.002/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1204.002
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\mspaint.exe'
    CommandLine|contains:
      - '\AppData\Local\Temp\'
      - '\Downloads\'
      - '\AppData\Roaming\'
      - 'C:\Users\Public\'
  condition: selection
falsepositives:
  - Users legitimately opening downloaded images in Paint. Correlate with parent process (email clients, browsers) and file provenance before escalation.
level: medium

KQL — Microsoft Sentinel / Defender

Hunt for Paint executing from anomalous parents, spawning children, or touching the network. The child-process query is the one to run first — it is the closest thing to a smoking gun this threat produces.

// Hunt 1: mspaint.exe spawning child processes (high fidelity)
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName =~ "mspaint.exe"
| where FileName !~ "mspaint.exe"
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine,
          InitiatingProcessCommandLine, InitiatingProcessParentFileName, SHA256
| order by TimeGenerated desc;

// Hunt 2: mspaint.exe making network connections (high fidelity)
DeviceNetworkEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName =~ "mspaint.exe"
| project TimeGenerated, DeviceName, InitiatingProcessAccountName, RemoteIP,
          RemoteUrl, RemotePort, InitiatingProcessCommandLine
| order by TimeGenerated desc;

// Hunt 3: Paint launched by email clients or browsers (delivery vector context)
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where FileName =~ "mspaint.exe"
| where InitiatingProcessFileName has_any ("outlook.exe", "msedge.exe", "chrome.exe", "firefox.exe", "thunderbird.exe", "winword.exe", "excel.exe")
| project TimeGenerated, DeviceName, AccountName, ProcessCommandLine,
          InitiatingProcessFileName, InitiatingProcessCommandLine
| order by TimeGenerated desc

Velociraptor VQL

Use this artifact for fleet-wide triage when you need to confirm whether Paint executed with suspicious lineage across endpoints that may lack full EDR telemetry.

-- Hunt for mspaint.exe executions and anomalous child processes
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ 'mspaint'
   OR Exe =~ '(?i)mspaint\.exe$'

-- Correlate: identify processes whose parent was Paint
SELECT Pid, Ppid, Name, CommandLine, Username, CreateTime
FROM pslist()
WHERE Ppid IN (
    SELECT Pid FROM pslist() WHERE Name =~ 'mspaint'
)

Remediation

1. Deploy the Microsoft security update covering this flaw immediately. Because this issue is serviced both as an inbox Windows component and (on Windows 10/11) through the Microsoft Store, verify both channels:
   • Confirm the applicable cumulative update for your Windows builds is deployed via your standard patching mechanism (WSUS, Intune, ConfigMgr).
   • Confirm Microsoft Store app updates are not disabled via policy. If your organization blocks Store updates, you must push the updated Paint package through your managed distribution path — a blocked Store means a permanently stale Paint.
2. Verify, don't assume. Run the script below across your fleet and reconcile the results against your asset inventory. Any endpoint that fails the check gets a ticket, not a shrug.
3. Reduce the delivery surface while patching completes:
   • Ensure your email gateway detonates or strips image attachments matching your risk policy, and that attachment sandboxing covers image file types, not just Office documents and executables.
   • Enable attack surface reduction rules that block Office applications and email clients from spawning unexpected child processes — this blunts the delivery-to-execution chain even if a malicious image lands.
4. Deploy the detections above. The "Paint spawns a child process" Sigma rule and KQL hunt should be running in your environment permanently — they cost almost nothing and catch a broad class of parser-bug exploitation, not just this one.
5. Fix the process gap. This incident's real lesson is patch-state ambiguity. Add an explicit step to your vulnerability management workflow: for every Microsoft disclosure, a named owner must confirm — with evidence — which update resolves it and when fleet coverage is verified. "Assumed patched" is not a state. Review Microsoft's Security Update Guide entry for this issue directly rather than relying on secondary summaries of patch status.

The following PowerShell script verifies Paint's presence, version, and update-channel state so you can audit remediation coverage:

# Verify Microsoft Paint installation state and version across the endpoint
# Run elevated. Output is suitable for central collection via your RMM/Intune.

$results = [ordered]@{}

# 1. Check inbox mspaint.exe presence and version
$inboxPath = "$env:SystemRoot\System32\mspaint.exe"
if (Test-Path $inboxPath) {
    $v = (Get-Item $inboxPath).VersionInfo
    $results['InboxPaintPresent'] = $true
    $results['InboxPaintVersion'] = $v.FileVersion
    $results['InboxPaintLastWrite'] = (Get-Item $inboxPath).LastWriteTime
} else {
    $results['InboxPaintPresent'] = $false
}

# 2. Check Store-packaged Paint (Windows 10/11)
$storePkg = Get-AppxPackage -Name "Microsoft.Paint" -ErrorAction SilentlyContinue
if ($storePkg) {
    $results['StorePaintVersion'] = $storePkg.Version
    $results['StorePaintInstallDate'] = $storePkg.InstallLocation
} else {
    $results['StorePaintVersion'] = 'Not Installed'
}

# 3. Check whether Store auto-updates are blocked by policy (a stale-Paint risk)
$policyPath = 'HKLM:\SOFTWARE\Policies\Microsoft\WindowsStore'
if (Test-Path $policyPath) {
    $autoUpdate = (Get-ItemProperty -Path $policyPath -Name 'AutoDownload' -ErrorAction SilentlyContinue).AutoDownload
    $results['StoreAutoUpdatePolicy'] = if ($null -eq $autoUpdate) { 'Not Set' } elseif ($autoUpdate -eq 2) { 'DISABLED - Paint may be stale' } else { "Value: $autoUpdate" }
} else {
    $results['StoreAutoUpdatePolicy'] = 'Not Set (default: updates enabled)'
}

# 4. Check installed cumulative updates from the last 90 days
$results['RecentHotfixes'] = (Get-HotFix | Where-Object { $_.InstalledOn -gt (Get-Date).AddDays(-90) } |
    Sort-Object InstalledOn -Descending | Select-Object -First 5 |
    ForEach-Object { "$($_.HotFixID) ($($_.InstalledOn.ToString('yyyy-MM-dd')))" }) -join '; '

[PSCustomObject]$results | ConvertTo-Json -Compress

The Bottom Line

A remote code execution flaw in Microsoft Paint sounds minor until you remember it sits on every Windows endpoint you manage, parses attacker-deliverable content, and spent weeks in a patch-status fog that attackers could read just as easily as defenders. The fix exists now. Your job is threefold: confirm it's actually deployed across the fleet (including the Store-update edge case), turn on the child-process and network detections that catch parser-bug exploitation generically, and close the workflow gap that let "unclear if patched" persist in your environment for weeks. Ubiquitous, boring applications are exactly where the next phishing-delivered initial access comes from.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub