Blog de Zscaler

Reciba en su bandeja de entrada las últimas actualizaciones del blog de Zscaler

Security Research

CVE-2025-50165: Critical Flaw in Windows Graphics Component

image
ARJUN G U
November 20, 2025 - 6 Min de lectura

Introduction

In May 2025, Zscaler ThreatLabz discovered CVE-2025-50165, a critical remote code execution (RCE) vulnerability with a CVSS score of 9.8 that impacts the Windows Graphics Component. The vulnerability lies within windowscodecs.dll, and any application that uses this library as a dependency is vulnerable to compromise, such as a Microsoft Office document. For example, attackers can exploit the vulnerability by creating a malicious JPEG image and inserting it into any file that leverages windowscodecs.dll. If a user opens that file, their system can be compromised by an attacker who can go on to perform RCE and take over the victim’s system.

Microsoft released a patch to fix the vulnerability on August 12, 2025. Since the Windows Graphics Component is a critical part of all Windows systems, this vulnerability poses a significant security threat to every impacted Windows system. 

Affected Versions

The following table outlines the specific Microsoft Windows products and versions impacted by CVE-2025-50165, and the corresponding patched versions that address the vulnerability:

Product

Impacted Version

Patched Version

Windows Server 2025

10.0.26100.4851

10.0.26100.4946

Windows 11 Version 24H2 for x64-based Systems

10.0.26100.4851

10.0.26100.4946

Windows 11 Version 24H2 for ARM64-based Systems

10.0.26100.4851

10.0.26100.4946

Windows Server 2025 (Server Core installation)

10.0.26100.4851

10.0.26100.4946

Table 1: Impacted Windows versions with vulnerable windowscodecs.dll and their patched versions.

Recommendations

ThreatLabz recommends Windows users update applications and install the patched versions specified in the affected versions table above.

Attack Chain

The attack chain begins with a maliciously crafted JPEG image designed to exploit the vulnerability. This malicious image, when rendered via the windowscodecs.dll, will trigger the vulnerability. The exploit can also be triggered indirectly by embedding the image in another file such as a Microsoft Office document. When the exploit is triggered, the attacker can execute arbitrary code.

How It Works

This section references the methodology used by ThreatLabz to discover and analyze CVE-2025-50165. We touch on how ThreatLabz identified the vulnerable code path, the process of triaging the crash, and the development of a Proof-of-Concept (PoC) exploit.

Identify the vulnerable path for fuzzing

In the figure below, line 51 served as the entry point for fuzzing. At this line, the original FileSize value can be replaced with MutatedBufferSize. This modification controls the buffer contents returned by MapViewOfFile and defines the snapshot’s entry point for subsequent fuzzing operations.

IDA decompilation of the function GpReadOnlyMemoryStream::InitFile.

Figure 1: IDA decompilation of the function GpReadOnlyMemoryStream::InitFile.

Crash analysis

The fuzzing process successfully identified a crash, as shown in the figure below.

Crash analysis of Microsoft Visio captured in WinDbg.

Figure 2: Crash analysis of Microsoft Visio captured in WinDbg.

The WinDbg output pinpointed the crashing instruction as call qword ptr [r8+10h] ds:0000080667c170=c0c0c0c0c0c0c0c0. This showed r8+10h was being dereferenced but pointed to uninitialized memory, a state identifiable by the c0c0c0c0c0c0c0c0 pattern used by Gflags. Further examination of the r8 register's memory dump, shown in the figure below, revealed this uninitialized memory could be user-controlled through heap spraying.

Memory dump of r8 register in WinDbg.

Figure 3: Memory dump of r8 register in WinDbg.

The address 0000015fc1cab170 contained the untrusted function pointer. The pointer was dereferenced at the windowscodecs!jpeg_finish_compress+0xcc instruction, directly leading to the crash. To understand the execution flow that led to this point, ThreatLabz conducted a stack trace analysis, as illustrated below.

STACK_TEXT:  
RetAddr               Call Site
00007ffe`a8da58bb     WindowsCodecs!jpeg_finish_compress+0xcc
00007ffe`a8d4b6cd     WindowsCodecs!CJpegTurboFrameEncode::HrWriteSource+0x46b
00007ff7`16d6218b     WindowsCodecs!CFrameEncodeBase::WriteSource+0x18d

The WinDbg stack trace highlighted three prominent functions within windowsCodecs.dll

  • jpeg_finish_compress
  • CJpegTurboFrameEncode::HrWriteSource
  • CFrameEncodeBase::WriteSource

Further investigation into the stack trace and additional research revealed the vulnerability's precise origin and the corresponding code snippet. By modifying the path to the crafted JPEG file, the exact location of the vulnerability’s trigger was pinpointed to the execution of piFrameEncode->WriteSource, as shown in the example below. 

[ REDACTED ]
// Create the decoder.
if (SUCCEEDED(hr))
{
    hr = piFactory->CreateDecoderFromFilename(L"/path/to/poc.jpg", NULL, GENERIC_READ,
            WICDecodeMetadataCacheOnDemand, // For JPEG lossless decoding/encoding.
            &piDecoder);
}
[ REDACTED ]
if (SUCCEEDED(hr))
{
    hr = piFrameEncode->WriteSource(
             static_cast (piFrameDecode),
             NULL); // Using NULL enables JPEG lossless encoding.
}


Exploit

ANALYST NOTE: Control Flow Guard (CFG) is disabled for the 32-bit version of windowscodecs.dll by default. However, the 64-bit version requires a CFG bypass to successfully exploit the vulnerability.

By leveraging heap spraying and exploiting the untrusted pointer dereference vulnerability, control of the instruction pointer (IP) can be obtained which enables further exploitation through Return-Oriented Programming (ROP). This is achieved with the following steps:

  1. Allocate a series of heap chunks, each sized 0x3ef7, with the ROP chain data stored within them.
  2. Free some of these heap chunks and return them to the free list so that one is reallocated as the victim chunk.
  3. Trigger the untrusted pointer dereference vulnerability.
  4. Use RIP control to employ a stack pivot gadget and redirect execution to the ROP chain stored within the heap.

The figure below shows the exploitation process and the resulting crash output.

Illustration of the exploitation steps and the resulting crash output captured in WinDbg.

Figure 4: Illustration of the exploitation steps and the resulting crash output captured in WinDbg.

With control of the IP established through the exploitation process, the next phase involves leveraging ROP gadgets to achieve arbitrary code execution. These gadgets are used to create a Read-Write-Execute (RWX) memory region using a function like VirtualAlloc. Once the RWX memory is set up, additional ROP gadgets such as mov dword [rax]rcx, where RAX points to the shellcode address and RCX contains the shellcode data, are used to write the malicious shellcode into this newly created memory region. Finally, execution is redirected to the shellcode by jumping to the address of the RWX memory.

Proof-of-Concept (PoC)

To demonstrate the exploitation of the vulnerability, ThreatLabz created an example application which allows the user to control the heap and process the JPEG image using the three functions. 

  1. Enables the creation of heap allocations with user-specified inputs:
    • Index: Specifies the location in a global array where the allocated heap address will be stored (e.g., index 0, 1, ...).
    • Size: Determines the size of the heap memory block to allocate.
    • Data: Represents the value stored within the allocated memory block.
  2. Frees a heap allocation based on the provided index value.
  3. Accepts Base64-encoded JPEG image data and uses the JPEG re-encode example code to process the image.
  4. Terminates the application.

In the figure below, the memory address 0X00007FF7F0BB448, displayed as Reward, represents the virtual memory address of the application’s main function. This address allows users to calculate the base address where the application’s process is mapped in memory, providing critical information for exploitation. Using options 1 and 2, users can perform a heap spray attack by densely allocating and freeing heap memory chunks to control the layout of data in memory. Option 3 then triggers the vulnerability by processing a specially crafted JPEG image, leveraging the heap spray setup to manipulate the application’s control flow and gain access to memory required for exploitation.

Core functionality of the executable used to demonstrate the PoC.

Figure 5: Core functionality of the executable used to demonstrate the PoC.

Check out this video for a detailed demonstration of RIP control in the example application, showing how RCE is achieved during the exploitation process.

Conclusion

With a CVSS score of 9.8, CVE-2025-50165 poses a significant risk to all Windows environments as the Microsoft Graphics Component is integral to all Windows environments. It is critical that Windows users update applications and install the patched versions in a timely manner.

Zscaler Coverage

The Zscaler ThreatLabz team has deployed protection for CVE-2025-50165.

form submtited
Gracias por leer

¿Este post ha sido útil?

Descargo de responsabilidad: Esta entrada de blog ha sido creada por Zscaler con fines únicamente informativos y se proporciona "tal cual" sin ninguna garantía de exactitud, integridad o fiabilidad. Zscaler no asume ninguna responsabilidad por cualquier error u omisión o por cualquier acción tomada en base a la información proporcionada. Cualquier sitio web de terceros o recursos vinculados en esta entrada del blog se proporcionan solo por conveniencia, y Zscaler no es responsable de su contenido o prácticas. Todo el contenido está sujeto a cambios sin previo aviso. Al acceder a este blog, usted acepta estos términos y reconoce su exclusiva responsabilidad de verificar y utilizar la información según convenga a sus necesidades.

Reciba en su bandeja de entrada las últimas actualizaciones del blog de Zscaler

Al enviar el formulario, acepta nuestra política de privacidad.