ESET researchers tested CVE‑2025‑50165, a major Home windows vulnerability described to grant far flung code execution through simply opening a specifically crafted JPG record – one of the vital extensively used picture codecs. The flaw, discovered and documented through Zscaler ThreatLabz, piqued our hobby, as Microsoft assessed its severity as essential however deemed its exploitability as much less most probably. Our root purpose research allowed us to pinpoint the precise location of the misguided code and reproduce the crash. We consider that the exploitation state of affairs is more difficult than it seems that to be.
Key issues of this blogpost:
- ESET researchers be offering a deep dive research of the CVE‑2025‑50165 vulnerability, illustrated with pseudocode snippets.
- We offer our technique to reproduce the crash the usage of a easy 12-bit or 16-bit JPG picture, and an exam of the preliminary launched patch.
- CVE-2025-50165 is a flaw within the encoding and compressing means of a JPG picture, no longer in its interpreting.
- Our conclusion explores and reassesses the exploitability and the assault state of affairs of this flaw.
Assessment
On November 20th, 2025, Zscaler ThreatLabz revealed a piece of writing documenting the invention of CVE‑2025‑50165, a high-impact far flung code execution vulnerability found in WindowsCodecs.dll. This library is Home windows’ primary interface library liable for dealing with maximum not unusual picture record codecs, akin to JPG, PNG, GIF, BMP, and so on. Zscaler’s findings, in addition to the outline supplied through Microsoft, disclose that the flaw stems from the dereference of an uninitialized serve as pointer in WindowsCodecs.dll, which is a part of the Home windows Imaging Element. The previous controlled to trace down the dereference factor within the jpeg_finish_compress serve as, which occurs to be known as when a JPG picture circulation is compressed and (re-)encoded. In relation to image-handling vulnerabilities, one would first call to mind parsing and interpreting insects that occur once the picture is rendered. So this moderately particular inclined code trail left us with some questions we would have liked to reply to:
- What are the precise prerequisites to take the inclined code trail resulting in the dereference of the uninitialized serve as pointer?
- When is jpeg_finish_compress known as?
- Why is the serve as pointer no longer initialized?
Given how not unusual JPG pictures are on the net, we would have liked solutions, so we began through investigating the code that led to the crash.
Crash web site
In line with the CVE‑2025‑50165 access description, WindowsCodecs.dll variations from 10.0.26100.0 and ahead of 10.0.26100.4946 are affected. We analyzed the inclined model 10.0.26100.4768 (SHA-1: 5887D96565749067564BABCD3DC5D107AB6666BD), after which carried out a binary comparability with the primary patched model 10.0.26100.4946 (SHA-1: 4EC1DC0431432BC318E78C520387911EC44F84FC). After downloading the corresponding symbols, we appeared on the crashing serve as, jpeg_finish_compress. In line with a model string found in WindowsCodecs.dll – libjpeg-turbo model 3.0.2 (construct 20250529) – the DLL depends upon a moderately outdated implementation of the libjpeg-turbo library (launched on January 24th, 2024) to maintain JPG pictures. The publicly to be had repository allowed us to map many of the related binary code and constructions to their supply code equivalents. For example, the compiled model of jpeg_finish_compress is similar to its supply code similar to be had right here, as proven in Determine 1.
In accordance with Zscaler’s findings, the crash occurs at jpeg_finish_compress+0xCC, which corresponds to line 48 in Determine 1, when dereferencing a serve as pointer situated at offset 0x10 of an unknown construction (pub). In line with libjpeg-turbo source code, this corresponds to a serve as pointer named compress_data_12. With a purpose to achieve this particular trail, the data_precision member of jpeg_compress_struct must be set to 12. This corresponds to the bit intensity, or in different phrases the choice of bits used to explain colours. Necessarily, WindowsCodecs.dll crashes when it tries to encode a 12‑bit precision JPG picture.
Patch diffing and root purpose research
The use of Diaphora, a binary diffing software, we carried out a diff between the inclined model 10.0.26100.4768 and the patched model 10.0.26100.4946, as proven in Determine 2.
Strangely, the crashing serve as jpeg_finish_compress discussed within the article isn’t provide. Then again, two encoding-related purposes had been modified: rawtransencode_master_selection and jinit_c_rawtranscode_coef_controller_turbo. The diff between the inclined and patched variations of rawtransencode_master_selection is proven in Determine 3.
The one related distinction appears to be that the serve as jinit_c_rawtranscode_coef_controller_turbo, which used to be in the past inlined within the frame of the serve as rawtransencode_master_selection, is now separated. Having a look on the patched model of the jinit_c_rawtranscode_coef_controller_turbo serve as finds that the in the past uninitialized construction member compress_data_12 is now set to indicate to a serve as named rawtranscode_compress_output_16, as proven in Determine 4.
Be aware that the sector compress_data_16, which used to be additionally no longer initialized within the inclined model, could also be set to indicate to rawtranscode_compress_output_16 within the patched model. This serve as is just a stub serve as that calls rawtranscode_compress_output, which would possibly point out that there’s no particular code to maintain both 12-bit or 16-bit precision JPG pictures.
Reproducing the crash
As discussed in Zscaler’s article, one can collect the code snippet proposed through Microsoft (https://be informed.microsoft.com/en-us/home windows/win32/wic/-wic-codec-jpegmetadataencoding#jpeg-re-encode-example-code) to decode and re-encode a JPG picture.
As soon as this program is compiled, the crash will also be reproduced through offering both a 12-bit or a 16-bit JPG record. Going in the course of the samples from the libjpeg-turbo repository, a 12-bit precision pattern picture is to be had for obtain at https://github.com/libjpeg-turbo/libjpeg-turbo/blob/primary/testimages/testorig12.jpg. Feeding this picture to the re-encoding instance utility led to a crash at the very same location discussed in Zscaler’s article. Determine 5 displays the context of the crash right through a debugging consultation.
The repeated hex worth 0xBAADF00D pointed to through the reminiscence cope with is a magic worth utilized by the C runtime (CRT) heap when a program calls HeapAlloc to allocate reminiscence. It marks the reminiscence as uninitialized (see https://www.nobugs.org/developer/win32/debug_crt_heap.html).
As indicated in the past, each analyzed variations of WindowsCodecs.dll seem in an effort to maintain 16-bit precision JPG pictures. But if checking out such pictures, the re-encoding utility crashes when dereferencing the compress_data_16 serve as pointer, as seen in Determine 6.
Having reproduced the crash, we puzzled whether or not this particular vulnerability used to be additionally provide within the supply code of the libjpeg-turbo library.
Exploring the supply code
Going in the course of the commits of libjpeg-turbo published that identical problems had been resolved on December 18th, 2024, with dedicate e0e18de, introducing model 3.1.1. Necessarily, the dedicate makes positive that constructions are zero-initialized and that an error is raised if a pointer is NULL. It seems that the entire zero-initializations and exams offered through this dedicate are absent within the inclined and patched variations of WindowsCodecs.dll.
The patch message additionally hints at different doable inclined code paths and, extra importantly, that crashes might also occur within the decompression procedure when manipulating a JPG picture, as highlighted through the diff of record jdapistd.c, illustrated in Determine 7.
Because the dedicate description obviously specifies, a calling utility would crash (because of the dereference of an uninitialized serve as pointer) best if it erroneously adjustments the data_precision box after calling the jpeg_start_compress or jpeg_start_decompress routines. This creates a moderately particular and most probably unrealistic state of affairs the place an utility the usage of WindowsCodecs.dll would adjust the state of inside constructions. Whilst such packages would possibly exist, it does no longer seem that the Home windows Imaging Element API lets in such habits.
Exploitability
As published through our root purpose research, the core factor of CVE‑2025‑50165 is living in WindowsCodecs.dll’s dealing with of JPG pictures with an information precision worth rather then the traditional and same old 8-bit. The 2 precision-specific serve as guidelines (compress_data_12 and compress_data_16) had been uninitialized right through the compression procedure, developing two inclined code paths that appear to be reachable best when (re-)encoding a JPG picture. Merely opening, and subsequently interpreting and rendering, a specifically crafted picture is not going to cause the vulnerability. Then again, the inclined serve as jpeg_finish_compress may well be known as if the picture is stored or if a bunch utility, such because the Microsoft Footage utility, creates thumbnails of pictures, as proven in Determine 8.
To ensure that a program to be regarded as inclined, it wishes the next traits:
- uses a inclined model of WindowsCodecs.dll,
- does no longer crash or abort whilst interpreting a 12-bit or 16-bit JPG record, and
- lets in the picture to be re-encoded.
Additionally, as discussed through Zscaler researchers, an cope with leak and sufficient keep watch over over the heap are obligatory to take advantage of this vulnerability.
Conclusion
Even though JPG is older, extensively used, and in all probability the preferred virtual picture layout in fuzz checking out, vulnerabilities can nonetheless be present in some formats. This find out about of CVE‑2025‑50165 additionally highlights the significance of maintaining with safety updates when the usage of third-party libraries.
Root purpose research along side patch diffing proved an important aggregate that allowed us to reply to our preliminary questions. We came upon that the malicious program will also be brought on when WindowsCodecs.dll encodes a 12-bit or a 16-bit precision JPG circulation as each precision-specific serve as guidelines had been neither initialized nor checked ahead of being dereferenced. Moreover, we found out that this procedure occurs when such a picture is stored or when a thumbnail is constituted of it.
This investigation led us to a identical conclusion as Microsoft’s in regards to the exploitability of this vulnerability. Certainly, as WindowsCodecs.dll is a library, a bunch utility can be regarded as inclined if it lets in JPG pictures to be (re-)encoded, and exploitable provided that an attacker has sufficient keep watch over over the applying (cope with leak, heap manipulation). Placing all of it in combination, it kind of feels certainly that exploitation is not likely.
After all, it’s value citing that, as of this writing and consistent with our assessments, more recent variations of WindowsCodecs.dll (akin to 10.0.22621.6133, SHA-1: 3F3767D05E5A91184005D98427074711F68D9950) put in force the other adjustments discussed in libjpeg-turbo’s dedicate, successfully addressing the loss of initialization and serve as pointer verification.
