Paint's fix arrived 24 days after the advisory said there was one

CVE-2026-83844 is an out-of-bounds read in Windows Paint that lets an unauthenticated attacker run code over a network. Microsoft's own wording, from the FAQ on its advisory: "An unauthenticated attacker could exploit this vulnerability by sending a specially crafted packet to an affected service over the network. Successful exploitation could allow the attacker to execute code on the target system. No authentication or user interaction is required."

CVSS 8.1 base, 7.1 temporal. The vector is AV:N/AC:H/PR:N/UI:N — network reachable, high attack complexity, no privileges needed, no user interaction. Weakness class CWE-125. Credited to Anonymous.

Maximum severity, per Microsoft: Important. Exploitability assessment: Exploitation Less Likely. Publicly disclosed: no. Exploited: no.

Most of the coverage this week is about the delivery channel, and it should be. But the revision history is where the story is.

Two revisions

The advisory has exactly two:

The vulnerability was published on 13 October. The build that fixes it was announced on 6 November. Twenty-four days.

For all twenty-four of those days the advisory carried RL:O in its temporal vector. RL is Remediation Level. O is Official Fix. The scoring vector that vulnerability management tools parse automatically said a vendor fix was available, during a period in which, by Microsoft's own revision note, the version that comprehensively addresses the flaw had not been released.

The temporal score of 7.1 is partly derived from that RL:O. A tool that trusted it scored the issue slightly lower than it should have, for over three weeks, because of a field that said the problem was already solved.

The table disagrees with the history

There is one row in the Security Updates table. It reads:

• Release date: 13 October 2026
• Product: Microsoft Paint
• Platform: Store App
• Impact: Remote Code Execution
• Build number: 11.2609.401.0

That build number is the one Microsoft announced on 6 November. The row says 13 October. One of those two dates is doing something other than describing when this build became available, and MSRC does not expose per-row history, so there is no way to tell from the page which.

And then the delivery

The platform field says Store App. That is the whole distribution mechanism.

The fix does not come through Windows Update. It will not appear in WSUS. It will not be approved in an Intune update ring, it will not show in a patch compliance report, and the monthly patch review that your organisation runs will never mention it. It arrives when the Microsoft Store updates the Paint app, which on a managed fleet may be never, because Store updates are frequently restricted by policy on exactly the machines that are most carefully managed.

So the administrator with the cleanest patch dashboard has the least information about this one.

Separate reporting adds a further wrinkle: the CVE record and NVD have listed an older build, 11.2605.91.0, as the fixed version, and administrators report that build never appearing in the Store. A scanner reading NVD would therefore be comparing installed versions against a number that may not exist, which produces a confident answer either way and a wrong one at least some of the time.

What to actually do

• Check the installed Paint version directly. You are looking for 11.2609.401.0 or later.
• On managed fleets, check whether Store updates are permitted at all. If they are blocked, this does not reach those machines by any route.
• Inventory it somewhere your patch tooling can see, because your patch tooling cannot see it by itself. Intune application inventory or direct package inspection will both do.
• Do not rely on a vulnerability scanner that sources its fixed-version data from NVD for this specific CVE until the records agree.

The general lesson, briefly

An increasing share of what ships on Windows arrives through the Store rather than through Windows Update, and the patch management discipline built over two decades covers one of those two channels. This CVE is a small one. The gap it illustrates is not.

What is not established

• Whether the 13 October row was backdated, edited later, or always carried the eventual build number. MSRC shows no per-row history.
• What the NVD record currently says. It was not readable at the time of writing, so the claim about 11.2605.91.0 rests on secondary reporting.
• Whether anything was practically exploitable during the 24-day window. The attack complexity is rated high and Microsoft assesses exploitation as less likely.
• Why the severity is Important rather than Critical for an unauthenticated network RCE. The high attack complexity is a defensible reason and Microsoft does not state one.
• Who reported it. The acknowledgement says Anonymous.