Source: NSB Cyber
Microsoft Paint is the last application most people associate with security risk. Yet a recently disclosed flaw, tracked as CVE-2026-83844 and rated 7.0 (High), gives threat actors another attack path during phishing campaigns. An attacker can trick victims into running code on a Windows 11 machine by sending them a payload in the form of an image. This is a useful reminder that in modern software, the risk rarely lives where our intuition points, it more often lives in a part of a program that quietly parses data it did not create.
But understanding the real risk requires looking beyond the initial vulnerability classification. In a separate technical deep dive, we take a closer look at what the vulnerability actually means, how it can be exploited and the implications for affected systems.
There is twist in where the danger hides. A feature designed to increase trust in what we see online became the pathway an attacker could use to reach the machine.
Recent versions of Paint added Content Credentials (the C2PA standard), the "nutrition label" that tells you whether an image was AI-generated or edited and by whom. To show that label, Paint reads the provenance metadata embedded within an image, all of this happens when you open or import the picture, and before any verifications have been performed on the image.
The irony of making this in Microsoft Paint
In Microsoft's official advisory, updated on 8 Nov 2026, they put the attack vector as "Local". This means that the remote code execution (RCE) is performed locally on the Windows 11 machine, where the payload that triggers this RCE is an image that is sent to the victim's machine.
Most of the attacks we see in the wild against companies targets the individual in the form of phishing where the victim downloads an email attachment or clicks a link to a malicious website. Now it is possible for an attacker to send an image via an email attachment to invoke Paint into running code on your machine.
This is a stark reminder that every new feature that consumes external data adds to the attack surface.
The underlying mistake was very simple. Deep in the code that decodes the metadata, the parser keeps track of two numbers: 1. Where it was reading from, and 2. How much there is left to read.
The metadata is broken up into chunks and each time a chunk is read, the parser changes the tracked numbers to move its position forward. However, it leaves out a tiny but important detail: just how much of the data is left to be read!
For a single read, it's harmless but the format of the payload allows an attacker to basically say "now repeat this thousands of times". So with the remaining-bytes count frozen at its original value, the program is led to believing it has plenty of data, long after it had run off the end of the buffer and into memory it was never meant to touch.
This vulnerability is called an over-read, involving reading memory outside of the bounds allocated to the program, which becomes the foothold for the code execution the advisory warns about.
How was it fixed? In the patched version, Microsoft replaced the entire hand-written component with a memory-safe implementation written in Rust, a language whose design makes this specific class of mistake essentially impossible to ship. It is a real-world example of a strategy the whole industry is moving toward: when a category of bug keeps recurring in a risky component, you don't just swat the latest instance, you rebuild the component so the category can't occur. The vulnerable code was removed.
Another operational lesson was buried in this story: the patch was confusing to apply. Public reporting noted that the vendor first pointed to one version number, the Microsoft Store served a different one to some users, and the authoritative "fixed" version was something else again, all while auto-updates were nominally on. Many organisations likely believed they were covered when they were, in fact, not. The security takeaway is not glamorous but it is the one that actually prevents incidents: verify the installed version against the vendor's final advisory, don't assume "updates are on" equals "patched," and treat even built-in, low-profile apps as part of your patch inventory.
For security teams, the message is simple. Attackers no longer need you to run a suspicious executable; they increasingly need only that one of your everyday tools quietly opens the wrong piece of content. Defending against that means funding the unglamorous work: Disciplined inventory of every app that touches untrusted data, and verification that patches have genuinely landed. CVE-2026-83844 did minimal real-world harm precisely because it was found and fixed responsibly. The organisations that stay ahead of the next one will be those that treat "it's just Paint" as a reason to look harder, not a reason to look away.
Disclosure & Timeline
Mid-October 2026 - CVE-2026-83844 is published by the Microsoft Security Response Center (MSRC): out-of-bounds read in Microsoft Paint, rated 8.1 (High), network attack vector, unauthenticated, no user privileges required. (Public reporting cites a disclosure around October 13.)
Fix shipped - the issue is addressed in Microsoft Paint build 11.2609.401.0, delivered through the Microsoft Store, which replaced the vulnerable parsing component rather than patching it in place.
Patch-version confusion (late October - early November 2026) - the fixed build was first cited as 11.2605.91.0; the Store continued offering 11.2605.81.0 to some users; MSRC ultimately lists 11.2609.401.0 as the fixed version. Multiple outlets warned that users with auto-updates enabled could still be running an unpatched build.
As of early November 2026 - no known exploitation in the wild and no detailed public proof-of-concept had been reported.
This write-up - produced by reverse-engineering the already-patched issue and shared only after a fix was broadly available, for educational and defensive purposes. It describes the bug class and the fix, not a working exploit.
8th November 2026 - CVE score downgraded and Attack Vector changed from “Network” to “Local” (currently AV:L, CVSS:3.1 score of 7).
Action item: verify your installed version with Get-AppxPackage Microsoft.Paint and confirm it is 11.2609.401.0 or later — don't assume "auto-updates on" means "patched."
Dates reflect public reporting at the time of writing; exact vendor report and patch-release dates were not independently confirmed. Written up from a reverse-engineering analysis of the affected and patched Microsoft Paint builds, shared for educational and defensive purposes.
Want to stay on top of the latest breaches and incidents? Subscribe to our LinkedIn Newsletter, visit our Signals page every Friday and explore our latest Blogs.