As reported by The Hacker News, Microsoft has shipped a fix for CVE-2026-83844, a remote code execution vulnerability in Windows Paint. But the delivery mechanism — and the conflicting version data surrounding it — make this a more complicated patch story than it first appears.
The core issue is an out-of-bounds read in Paint that could allow network-based code execution. Microsoft rates it as Important with a CVSS score of 8.1. No active exploitation has been observed, and the flaw was not publicly disclosed prior to the October 13 advisory. That's the good news. The bad news is everything about how the patch reaches your endpoints.
Vulnerability Summary
| Field | Detail |
|---|---|
| CVE | CVE-2026-83844 |
| Severity | Important (CVSS 8.1) |
| Type | Out-of-bounds read → Remote Code Execution |
| Affected Product | Microsoft Paint (Windows), builds below 11.2609.401.0 |
| Fixed Build | 11.2609.401.0 (via Microsoft Store) |
| Delivery Channel | Microsoft Store auto-update — NOT Windows Update / WSUS |
| Patch Available | Yes — through Store update only |
| Active Exploitation | None observed as of publication |
| Workaround | None listed; removing Paint was suggested pre-patch |
Why This Patch Breaks Your Normal Workflow
Most enterprise patch management is built around Windows Update, WSUS, or Intune's Windows update rings. Store apps are a parallel universe. They update on their own schedule through the Microsoft Store, and IT has limited visibility into when or whether a specific Store app build has landed on each machine.
For environments that disable Store auto-updates — common in locked-down corporate builds, kiosk deployments, and shared workstation environments — Paint may never receive this fix unless someone explicitly triggers it.
The Version Data Conflict Is a Scanning Trap
Microsoft's advisory says fixed = 11.2609.401.0. The CVE record and NVD entry say fixed = 11.2605.91.0. A scanner reading either source will produce different compliance results for builds in between.
This is the kind of discrepancy that quietly undermines trust in vulnerability management. If your scanner ingests the NVD feed, it may mark a machine running 11.2605.91.0 as patched — but Microsoft's own advisory now says that build is not fixed. The advisory's revision history doesn't even note the change, which means teams relying on change tracking would miss it entirely.
Defenders should treat 11.2609.401.0 as the minimum compliant build and override any scanner logic that uses the older threshold.
The Multi-User Problem
Store apps install per-user, not per-machine. A single PC can have multiple copies of Paint at different versions — one for each user profile — plus a provisioned copy that gets stamped onto new user accounts. Checking only the logged-in user's Paint version is insufficient and will miss stale copies belonging to other accounts.
Who Is Most at Risk
Shield53 Recommendations
Immediate Actions:
- Audit every copy of Paint across all user profiles. Run both commands from an elevated PowerShell session on every endpoint:
Get-AppxPackage -AllUsers -Name Microsoft.Paint | Select-Object Version, @{ n = 'Users'; e = { $_.PackageUserInformation.UserSecurityId.Username -join ', ' } }
Get-AppxProvisionedPackage -Online | Where-Object DisplayName -eq 'Microsoft.Paint' | Select-Object Version - Define 11.2609.401.0 as your compliance baseline. Override any vulnerability scanner that uses the CVE/NVD threshold of 11.2605.91.0. Document this override so future teams understand the discrepancy.
- Force Store updates in managed environments. In Intune, trigger a Store app update scan across enrolled devices. For standalone PCs, manually open the Microsoft Store and check for updates.
- Re-scan after update. Re-run both PowerShell commands and confirm every copy — including the provisioned package — reports 11.2609.401.0 or later.
- For environments where Store access is blocked: Consider deploying Paint via an offline Appx package, or removing Paint entirely if it is not a business requirement. The advisory lists no workaround, so removal remains a valid risk-reduction step.
- Update your vulnerability management process to include Store apps as a recurring patch category — not just Windows Update payloads. This won't be the last time a Microsoft component ships its fix through the Store.
The deeper lesson here is architectural: as Microsoft continues decoupling built-in apps from the OS update channel, enterprises that haven't extended patch management to cover Store apps will accumulate blind spots. Paint today, something more critical tomorrow.
