ESET researchers examined CVE\u20112025\u201150165, a critical Home windows vulnerability described to grant distant code execution by merely opening a specifically crafted JPG file \u2013 one of the vital broadly used picture codecs. The flaw, discovered and documented by Zscaler ThreatLabz, piqued our curiosity, as Microsoft assessed its severity as important however deemed its exploitability as much less doubtless. Our root trigger evaluation allowed us to pinpoint the precise location of the defective code and reproduce the crash. We imagine that the exploitation state of affairs is tougher than it seems to be.<\/p>\n

\n
Key factors of this blogpost:<\/strong><\/p>\n
\n
ESET researchers supply a deep dive evaluation of the CVE\u20112025\u201150165 vulnerability, illustrated with pseudocode snippets.<\/li>\n
We offer our technique to breed the crash utilizing a easy 12-bit or 16-bit JPG picture, and an examination of the preliminary launched patch.<\/li>\n
CVE-2025-50165 is a flaw within the encoding and compressing means of a JPG picture, not in its decoding.<\/li>\n
Our conclusion explores and reassesses the exploitability and the assault state of affairs of this flaw.<\/li>\n<\/ul>\n<\/blockquote>\n
Overview<\/h2>\n
On November 20^{th<\/sup>, 2025, Zscaler ThreatLabz printed an article documenting the invention of CVE\u20112025\u201150165<\/a>, a high-impact distant code execution vulnerability current in WindowsCodecs.dll<\/span>. This library is Home windows\u2019 important interface library accountable for dealing with most typical picture file codecs, corresponding to JPG, PNG, GIF, BMP, and many others. Zscaler\u2019s findings, in addition to the description supplied by Microsoft<\/a>, reveal that the flaw stems from the dereference of an uninitialized perform pointer in WindowsCodecs.dll<\/a>, which is a part of the Home windows Imaging Element. The previous managed to trace down the dereference difficulty contained in the jpeg_finish_compress<\/span> perform, which occurs to be known as when a JPG picture stream is compressed and (re-)encoded. In terms of image-handling vulnerabilities, one would first consider parsing and decoding bugs that occur as quickly because the picture is rendered. So this relatively particular weak code path left us with some questions we needed to reply:<\/p>\n}
\n
What are the precise situations to take the weak code path resulting in the dereference of the uninitialized perform pointer?<\/li>\n
When is jpeg_finish_compress<\/span> known as?<\/li>\n
Why is the perform pointer not initialized?<\/li>\n<\/ul>\n
Given how frequent<\/a> JPG photographs are on the net, we needed solutions, so we began by investigating the code that triggered the crash.<\/p>\n
Crash web site<\/h2>\n
Based on the CVE\u20112025\u201150165<\/a> entry description, WindowsCodecs.dll<\/span> variations from 10.0.26100.0 and earlier than 10.0.26100.4946 are affected. We analyzed the weak model 10.0.26100.4768 (SHA-1: 5887D96565749067564BABCD3DC5D107AB6666BD<\/span>), after which carried out a binary comparability with the primary patched model 10.0.26100.4946 (SHA-1: 4EC1DC0431432BC318E78C520387911EC44F84FC<\/span>). After downloading the corresponding symbols, we appeared on the crashing perform, jpeg_finish_compress<\/span>. Based on a model string current in WindowsCodecs.dll \u2013 libjpeg-turbo model 3.0.2 (construct 20250529)<\/span> \u2013 the DLL depends on a relatively outdated implementation of the libjpeg-turbo library<\/a> (launched on January 24^{th<\/sup>, 2024) to deal with JPG photographs. The publicly obtainable repository allowed us to map a lot of the related binary code and buildings to their supply code equivalents. For example, the compiled model of jpeg_finish_compress<\/span> is similar to its supply code equal obtainable}right here<\/a>, as proven in Determine 1.<\/p>\n
$\"Figure$
Determine 1. Hex-Rays IDA decompiler output of the <\/em>jpeg_finish_compress<\/span> perform is much like the cited supply code<\/em><\/figcaption><\/figure>\nPrimarily based on Zscaler\u2019s findings, the crash occurs at jpeg_finish_compress+0xCC<\/span>, which corresponds to line 48 in Determine 1, when dereferencing a perform pointer situated at offset 0x10<\/span> of an unknown construction (pub<\/span>). Based on libjpeg-turbo sourc<\/span>e code, this corresponds to a perform pointer named compress_data_12<\/span>. With a purpose to attain this particular path, the data_precision<\/span> member of jpeg_compress_struct<\/span> must be set to 12<\/span>. This corresponds to the bit depth<\/a>, or in different phrases the variety of bits used to explain colours. Primarily, WindowsCodecs.dll<\/span> crashes when it tries to encode a 12\u2011bit precision JPG picture.<\/p>\n
Patch diffing and root trigger evaluation<\/h2>\n
Utilizing Diaphora<\/a>, a binary diffing instrument, we carried out a diff between the weak model 10.0.26100.4768 and the patched model 10.0.26100.4946, as proven in Determine 2.<\/p>\n
$\"Figure$
Determine 2. Diaphora efficiently highlighted the partially matched and unmatched capabilities between each libraries<\/em><\/figcaption><\/figure>\n
Surprisingly, the crashing perform jpeg_finish_compress<\/span> talked about within the article just isn’t current. Nevertheless, two encoding-related capabilities had been modified: rawtransencode_master_selection<\/span> and jinit_c_rawtranscode_coef_controller_turbo<\/span>. The diff between the weak and patched variations of rawtransencode_master_selection<\/span> is proven in Determine 3.<\/p>\n
$\"Figure$
Determine 3. Diff between the weak (left) and patched (proper) variations of <\/em>rawtransencode_master_selection<\/span><\/figcaption><\/figure>\nThe one related distinction appears to be that the perform jinit_c_rawtranscode_coef_controller_turbo<\/span>, which was beforehand inlined<\/a> within the physique of the perform rawtransencode_master_selection<\/span>, is now separated. Trying on the patched model of the jinit_c_rawtranscode_coef_controller_turbo<\/span> perform reveals that the beforehand uninitialized construction member compress_data_12<\/span> is now set to level to a perform named rawtranscode_compress_output_16<\/span>, as proven in Determine 4.<\/p>\n
$\"Figure$
Determine 4. Patched model of <\/em>jinit_c_rawtranscode_coef_controller_turbo<\/span><\/figcaption><\/figure>\n
Be aware that the sector compress_data_16<\/span>, which was additionally not initialized within the weak model, can be set to level to rawtranscode_compress_output_16<\/span> within the patched model. This perform is solely a stub perform that calls rawtranscode_compress_output<\/span>, which can point out that there\u2019s no particular code to deal with both 12-bit or 16-bit precision JPG photographs.<\/p>\n
Reproducing the crash<\/h2>\n
As talked about in Zscaler\u2019s article, one can compile the code snippet proposed by Microsoft (https:\/\/study.microsoft.com\/en-us\/home windows\/win32\/wic\/-wic-codec-jpegmetadataencoding#jpeg-re-encode-example-code<\/a>) to decode and re-encode a JPG picture.<\/p>\n
As soon as this program is compiled, the crash could be reproduced by offering both a 12-bit or a 16-bit JPG file. Going by way of the samples from the libjpeg-turbo<\/span> repository, a 12-bit precision pattern picture is obtainable for obtain at https:\/\/github.com\/libjpeg-turbo\/libjpeg-turbo\/blob\/important\/testimages\/testorig12.jpg<\/a>. Feeding this picture to the re-encoding instance utility resulted in a crash at the very same location talked about in Zscaler\u2019s article. Determine 5 reveals the context of the crash throughout a debugging session.<\/p>\n
$\"Figure$
Determine 5. The re-encoding instance utility crashes in the course of the compression routine when dealing with a 12-bit JPG picture<\/em><\/figcaption><\/figure>\nThe repeated hex worth 0xBAADF00D<\/span> pointed to by the reminiscence handle is a magic worth utilized by the C runtime (CRT) heap when a program calls HeapAlloc<\/span> to allocate reminiscence. It marks the reminiscence as uninitialized (see https:\/\/www.nobugs.org\/developer\/win32\/debug_crt_heap.html<\/a>).<\/p>\n
As indicated beforehand, each analyzed variations of WindowsCodecs.dll<\/span> seem to have the ability to deal with 16-bit precision JPG photographs. However when testing such photographs, the re-encoding utility crashes when dereferencing the compress_data_16 perform<\/span> pointer, as noticed in Determine 6.<\/p>\n
$\"Figure$
Determine 6. The re-encoding instance utility crashes in the course of the compression routine when dealing with a 16-bit JPG picture<\/em><\/figcaption><\/figure>\n
Having reproduced the crash, we questioned whether or not this particular vulnerability was additionally current within the supply code of the libjpeg-turbo<\/span> library.<\/p>\n
Exploring the supply code<\/h2>\n
Going by way of the commits of libjpeg-turbo<\/span> revealed that related points had been resolved on December 18^{th<\/sup>, 2024, with commit}e0e18de<\/a>, introducing model 3.1.1. Primarily, the commit makes positive that buildings are zero-initialized and that an error is raised if a pointer is NULL<\/span>. It seems that every one the zero-initializations and checks launched by this commit are absent within the weak and patched variations of WindowsCodecs.dll<\/span>.<\/p>\n
The patch message additionally hints at different potential weak code paths and, extra importantly, that crashes may occur within the decompression course of when manipulating a JPG picture, as highlighted by the diff of file jdapistd.c<\/a>, illustrated in Determine 7.<\/p>\n
$\"Figure$
Determine 7. Diff of decompression routines carried out in <\/em>jdapistd.c<\/span><\/figcaption><\/figure>\n
Because the commit description clearly specifies, a calling utility would crash (as a result of dereference of an uninitialized perform pointer) solely<\/strong> if it erroneously adjustments the data_precision<\/span> discipline after calling the jpeg_start_compress<\/span> or jpeg_start_decompress<\/span> routines. This creates a relatively particular and sure unrealistic state of affairs the place an utility utilizing WindowsCodecs.dll<\/span> would alter the state of inner buildings. Whereas such functions could exist, it doesn’t seem that the Home windows Imaging Element API permits such habits.<\/p>\n
Exploitability<\/h2>\n
As revealed by our root trigger evaluation, the core difficulty of CVE\u20112025\u201150165 resides in WindowsCodecs.dll<\/span>\u2019s dealing with of JPG photographs with a knowledge precision worth apart from the traditional and normal 8-bit. The 2 precision-specific perform pointers (compress_data_12<\/span> and compress_data_16<\/span>) had been uninitialized in the course of the compression course of, creating two weak code paths that appear to be reachable solely when (re-)encoding<\/em> a JPG picture. Merely opening, and due to this fact decoding and rendering, a specifically crafted picture won’t set off the vulnerability. Nevertheless, the weak perform jpeg_finish_compress<\/span> might be known as if the picture is saved or if a bunch utility, such because the Microsoft Pictures utility, creates thumbnails of photographs, as proven in Determine 8.<\/p>\n
$\"Figure$ Determine 8. The weak <\/em>jpeg_finish_compress<\/span> perform known as in the course of the creation of a thumbnail for a picture<\/em><\/figcaption><\/figure>\n
To ensure that a program to be thought-about weak, it wants the next traits:<\/p>\n
\n
makes use of a weak model of WindowsCodecs.dll<\/span>,<\/li>\n
doesn’t crash or abort whereas decoding a 12-bit or 16-bit JPG file, and<\/li>\n
permits the picture to be re-encoded.<\/li>\n<\/ul>\n
Furthermore, as talked about by Zscaler researchers, an handle leak and sufficient management over the heap are necessary to use this vulnerability.<\/p>\n
Conclusion<\/h2>\n
Though JPG is older, broadly used, and maybe the preferred digital picture format in fuzz testing<\/a>, vulnerabilities can nonetheless be present in some codecs. This examine of CVE\u20112025\u201150165 additionally highlights the significance of maintaining with safety updates when utilizing third-party libraries.<\/p>\n
Root trigger evaluation together with patch diffing proved a really highly effective mixture that allowed us to reply our preliminary questions. We discovered that the bug could be triggered when WindowsCodecs.dll<\/span> encodes a 12-bit or a 16-bit precision JPG stream as each precision-specific perform pointers had been neither initialized nor checked earlier than being dereferenced. Moreover, we found out that this course of occurs when such a picture is saved or when a thumbnail is created from it.<\/p>\n
This investigation led us to an analogous conclusion as Microsoft\u2019s concerning the exploitability of this vulnerability. Certainly, as WindowsCodecs.dll is a library, a bunch utility can be thought-about weak if it permits JPG photographs to be (re-)encoded, and exploitable provided that an attacker has sufficient management over the appliance (handle leak, heap manipulation). Placing all of it collectively, it appears certainly that exploitation is unlikely.<\/p>\n
Lastly, it\u2019s value mentioning that, as of this writing and in response to our exams, newer variations of WindowsCodecs.dll<\/span> (corresponding to 10.0.22621.6133, SHA-1: 3F3767D05E5A91184005D98427074711F68D9950<\/span>) implement the completely different adjustments talked about in libjpeg-turbo<\/span>\u2019s commit, successfully addressing the dearth of initialization and performance pointer verification.<\/p>\n
$\"\"$ <\/a><\/p>\n<\/div>\n\n","protected":false},"excerpt":{"rendered":"
ESET researchers examined CVE\u20112025\u201150165, a critical Home windows vulnerability described to grant distant code execution by merely opening a specifically crafted JPG file \u2013 one of the vital broadly used picture codecs. The flaw, discovered and documented by Zscaler ThreatLabz, piqued our curiosity, as Microsoft assessed its severity as important however deemed its exploitability as […]<\/p>\n","protected":false},"author":2,"featured_media":10158,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[58],"tags":[7133,420,2705,7132,1059],"class_list":["post-10156","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cybersecurity","tag-component","tag-critical","tag-flaw","tag-imaging","tag-windows"],"_links":{"self":[{"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/posts\/10156","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=10156"}],"version-history":[{"count":1,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/posts\/10156\/revisions"}],"predecessor-version":[{"id":10157,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/posts\/10156\/revisions\/10157"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/media\/10158"}],"wp:attachment":[{"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=10156"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=10156"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=10156"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}