{"id":103,"date":"2026-03-16T10:58:55","date_gmt":"2026-03-16T10:58:55","guid":{"rendered":"https:\/\/escudodigital.uy\/index.php\/2026\/03\/16\/a-critical-flaw-in-windows-imaging-component\/"},"modified":"2026-03-16T10:58:55","modified_gmt":"2026-03-16T10:58:55","slug":"a-critical-flaw-in-windows-imaging-component","status":"publish","type":"post","link":"https:\/\/escudodigital.uy\/index.php\/2026\/03\/16\/a-critical-flaw-in-windows-imaging-component\/","title":{"rendered":"A critical flaw in Windows Imaging Component"},"content":{"rendered":"<div>\n<p>ESET researchers examined CVE\u20112025\u201150165, a serious Windows vulnerability described to grant remote code execution by merely opening a specially crafted JPG file \u2013 one of the most widely used image formats. The flaw, found and documented by Zscaler ThreatLabz, piqued our interest, as Microsoft assessed its severity as critical but deemed its exploitability as less likely. Our root cause analysis allowed us to pinpoint the exact location of the faulty code and reproduce the crash. We believe that the exploitation scenario is harder than it appears to be.<\/p>\n<blockquote>\n<p><strong>Key points of this blogpost:<\/strong><\/p>\n<ul>\n<li>ESET researchers offer a deep dive analysis of the CVE\u20112025\u201150165 vulnerability, illustrated with pseudocode snippets.<\/li>\n<li>We provide our method to reproduce the crash using a simple 12-bit or 16-bit JPG image, and an examination of the initial released patch.<\/li>\n<li>CVE-2025-50165 is a flaw in the encoding and compressing process of a JPG image, not in its decoding.<\/li>\n<li>Our conclusion explores and reassesses the exploitability and the attack scenario of this flaw.<\/li>\n<\/ul>\n<\/blockquote>\n<h2>Overview<\/h2>\n<p>On November 20<sup>th<\/sup>, 2025, Zscaler ThreatLabz published an article <a href=\"https:\/\/www.zscaler.com\/blogs\/security-research\/cve-2025-50165-critical-flaw-windows-graphics-component\" target=\"_blank\" rel=\"noopener\">documenting the discovery of CVE\u20112025\u201150165<\/a>, a high-impact remote code execution vulnerability present in <span style=\"font-family: courier new, courier, monospace;\">WindowsCodecs.dll<\/span>. This library is Windows\u2019 main interface library responsible for handling most common image file formats, such as JPG, PNG, GIF, BMP, etc. Zscaler\u2019s findings, as well as the <a href=\"https:\/\/msrc.microsoft.com\/update-guide\/vulnerability\/CVE-2025-50165\" target=\"_blank\" rel=\"noopener\">description provided by Microsoft<\/a>, reveal that the flaw stems from the dereference of an uninitialized function pointer in <a href=\"https:\/\/learn.microsoft.com\/en-us\/windows\/win32\/wic\/-wic-api\" target=\"_blank\" rel=\"noopener\">WindowsCodecs.dll<\/a>, which is part of the Windows Imaging Component. The former managed to track down the dereference issue inside the <span style=\"font-family: courier new, courier, monospace;\">jpeg_finish_compress<\/span> function, which happens to be called when a JPG image stream is compressed and (re-)encoded. When it comes to image-handling vulnerabilities, one would first think of parsing and decoding bugs that happen as soon as the image is rendered. So this rather specific vulnerable code path left us with some questions we wanted to answer:<\/p>\n<ul>\n<li>What are the exact conditions to take the vulnerable code path leading to the dereference of the uninitialized function pointer?<\/li>\n<li>When is <span style=\"font-family: courier new, courier, monospace;\">jpeg_finish_compress<\/span> called?<\/li>\n<li>Why is the function pointer not initialized?<\/li>\n<\/ul>\n<p>Given how <a href=\"https:\/\/w3techs.com\/technologies\/history_overview\/image_format\/all\" target=\"_blank\" rel=\"noopener\">common<\/a> JPG images are on the web, we wanted answers, so we started by investigating the code that caused the crash.<\/p>\n<h2>Crash site<\/h2>\n<p>According to the <a href=\"https:\/\/www.cve.org\/CVERecord?id=CVE-2025-50165\" target=\"_blank\" rel=\"noopener\">CVE\u20112025\u201150165<\/a> entry description, <span style=\"font-family: courier new, courier, monospace;\">WindowsCodecs.dll<\/span> versions from 10.0.26100.0 and before 10.0.26100.4946 are affected. We analyzed the vulnerable version 10.0.26100.4768 (SHA-1: <span style=\"font-family: courier new, courier, monospace;\">5887D96565749067564BABCD3DC5D107AB6666BD<\/span>), and then performed a binary comparison with the first patched version 10.0.26100.4946 (SHA-1: <span style=\"font-family: courier new, courier, monospace;\">4EC1DC0431432BC318E78C520387911EC44F84FC<\/span>). After downloading the corresponding symbols, we looked at the crashing function, <span style=\"font-family: courier new, courier, monospace;\">jpeg_finish_compress<\/span>. According to a version string present in <span style=\"font-family: courier new, courier, monospace;\">WindowsCodecs.dll \u2013 libjpeg-turbo version 3.0.2 (build 20250529)<\/span> \u2013 the DLL relies on a rather old implementation of the <a href=\"https:\/\/github.com\/libjpeg-turbo\/libjpeg-turbo\/tree\/3.0.2\" target=\"_blank\" rel=\"noopener\">libjpeg-turbo library<\/a> (released on January 24<sup>th<\/sup>, 2024) to handle JPG images. The publicly available repository allowed us to map most of the relevant binary code and structures to their source code equivalents. For instance, the compiled version of <span style=\"font-family: courier new, courier, monospace;\">jpeg_finish_compress<\/span> is very similar to its source code equivalent available <a href=\"https:\/\/github.com\/libjpeg-turbo\/libjpeg-turbo\/blob\/3.0.2\/jcapimin.c#L173\" target=\"_blank\" rel=\"noopener\">here<\/a>, as shown in Figure 1.<\/p>\n<figure class=\"image\"><img decoding=\"async\" title=\"Figure 1. Hex-Rays IDA decompiler output of the jpeg_finish_compress function is similar to the cited source code\" src=\"https:\/\/web-assets.esetstatic.com\/wls\/2025\/12-25\/cve-2025-50165\/figure-1.png\" alt=\"Figure 1. Hex-Rays IDA decompiler output of the jpeg_finish_compress function\" width=\"\" height=\"\"\/><figcaption><em>Figure 1. Hex-Rays IDA decompiler output of the <\/em><span style=\"font-family: courier new, courier, monospace;\">jpeg_finish_compress<\/span><em> function is similar to the cited source code<\/em><\/figcaption><\/figure>\n<p>Based on Zscaler\u2019s findings, the crash happens at <span style=\"font-family: courier new, courier, monospace;\">jpeg_finish_compress+0xCC<\/span>, which corresponds to line 48 in Figure 1, when dereferencing a function pointer located at offset <span style=\"font-family: courier new, courier, monospace;\">0x10<\/span> of an unknown structure (<span style=\"font-family: courier new, courier, monospace;\">pub<\/span>). According to <span style=\"font-family: courier new, courier, monospace;\">libjpeg-turbo sourc<\/span>e code, this corresponds to a function pointer named <span style=\"font-family: courier new, courier, monospace;\">compress_data_12<\/span>. In order to reach this specific path, the <span style=\"font-family: courier new, courier, monospace;\">data_precision<\/span> member of <span style=\"font-family: courier new, courier, monospace;\">jpeg_compress_struct<\/span> needs to be set to <span style=\"font-family: courier new, courier, monospace;\">12<\/span>. This corresponds to the <a href=\"https:\/\/en.wikipedia.org\/wiki\/Color_depth\">bit depth<\/a>, or in other words the number of bits used to describe colors. Essentially, <span style=\"font-family: courier new, courier, monospace;\">WindowsCodecs.dll<\/span> crashes when it tries to encode a 12\u2011bit precision JPG image.<\/p>\n<h2>Patch diffing and root cause analysis<\/h2>\n<p>Using <a href=\"https:\/\/github.com\/joxeankoret\/diaphora\">Diaphora<\/a>, a binary diffing tool, we performed a diff between the vulnerable version 10.0.26100.4768 and the patched version 10.0.26100.4946, as shown in Figure 2.<\/p>\n<figure class=\"image\"><img decoding=\"async\" title=\"Figure 2. Diaphora successfully highlighted the partially matched and unmatched functions between both libraries\" src=\"https:\/\/web-assets.esetstatic.com\/wls\/2025\/12-25\/cve-2025-50165\/figure-2.png\" alt=\"Figure 2. partially matched and unmatched functions between both libraries\" width=\"\" height=\"\"\/><figcaption><em>Figure 2. Diaphora successfully highlighted the partially matched and unmatched functions between both libraries<\/em><\/figcaption><\/figure>\n<p>Surprisingly, the crashing function <span style=\"font-family: courier new, courier, monospace;\">jpeg_finish_compress<\/span> mentioned in the article is not present. However, two encoding-related functions were changed: <span style=\"font-family: courier new, courier, monospace;\">rawtransencode_master_selection<\/span> and <span style=\"font-family: courier new, courier, monospace;\">jinit_c_rawtranscode_coef_controller_turbo<\/span>. The diff between the vulnerable and patched versions of <span style=\"font-family: courier new, courier, monospace;\">rawtransencode_master_selection<\/span> is shown in Figure 3.<\/p>\n<figure class=\"image\"><img decoding=\"async\" title=\"Figure 3. Diff between the vulnerable (left) and patched (right) versions of rawtransencode_master_selection\" src=\"https:\/\/web-assets.esetstatic.com\/wls\/2025\/12-25\/cve-2025-50165\/figure-3.png\" alt=\"Figure 3. Diff between vulnerable and patched versions of rawtransencode_master_selection\" width=\"\" height=\"\"\/><figcaption><em>Figure 3. Diff between the vulnerable (left) and patched (right) versions of <\/em><span style=\"font-family: courier new, courier, monospace;\">rawtransencode_master_selection<\/span><\/figcaption><\/figure>\n<p>The only relevant difference seems to be that the function <span style=\"font-family: courier new, courier, monospace;\">jinit_c_rawtranscode_coef_controller_turbo<\/span>, which was previously <a href=\"https:\/\/en.wikipedia.org\/wiki\/Inline_expansion\" target=\"_blank\" rel=\"noopener\">inlined<\/a> in the body of the function <span style=\"font-family: courier new, courier, monospace;\">rawtransencode_master_selection<\/span>, is now separated. Looking at the patched version of the <span style=\"font-family: courier new, courier, monospace;\">jinit_c_rawtranscode_coef_controller_turbo<\/span> function reveals that the previously uninitialized structure member <span style=\"font-family: courier new, courier, monospace;\">compress_data_12<\/span> is now set to point to a function named <span style=\"font-family: courier new, courier, monospace;\">rawtranscode_compress_output_16<\/span>, as shown in Figure 4.<\/p>\n<figure class=\"image\"><img decoding=\"async\" title=\"Figure 4. Patched version of jinit_c_rawtranscode_coef_controller_turbo\" src=\"https:\/\/web-assets.esetstatic.com\/wls\/2025\/12-25\/cve-2025-50165\/figure-4.png\" alt=\"Figure 4. Patched version of jinit_c_rawtranscode_coef_controller_turbo\" width=\"\" height=\"\"\/><figcaption><em>Figure 4. Patched version of <\/em><span style=\"font-family: courier new, courier, monospace;\">jinit_c_rawtranscode_coef_controller_turbo<\/span><\/figcaption><\/figure>\n<p>Note that the field <span style=\"font-family: courier new, courier, monospace;\">compress_data_16<\/span>, which was also not initialized in the vulnerable version, is also set to point to <span style=\"font-family: courier new, courier, monospace;\">rawtranscode_compress_output_16<\/span> in the patched version. This function is simply a stub function that calls <span style=\"font-family: courier new, courier, monospace;\">rawtranscode_compress_output<\/span>, which may indicate that there\u2019s no specific code to handle either 12-bit or 16-bit precision JPG images.<\/p>\n<h2>Reproducing the crash<\/h2>\n<p>As mentioned in Zscaler\u2019s article, one can compile the code snippet proposed by Microsoft (<a href=\"https:\/\/learn.microsoft.com\/en-us\/windows\/win32\/wic\/-wic-codec-jpegmetadataencoding#jpeg-re-encode-example-code\" target=\"_blank\" rel=\"noopener\">https:\/\/learn.microsoft.com\/en-us\/windows\/win32\/wic\/-wic-codec-jpegmetadataencoding#jpeg-re-encode-example-code<\/a>) to decode and re-encode a JPG image.<\/p>\n<p>Once this program is compiled, the crash can be reproduced by providing either a 12-bit or a 16-bit JPG file. Going through the samples from the <span style=\"font-family: courier new, courier, monospace;\">libjpeg-turbo<\/span> repository, a 12-bit precision sample image is available for download at <a href=\"https:\/\/github.com\/libjpeg-turbo\/libjpeg-turbo\/blob\/main\/testimages\/testorig12.jpg\" target=\"_blank\" rel=\"noopener\">https:\/\/github.com\/libjpeg-turbo\/libjpeg-turbo\/blob\/main\/testimages\/testorig12.jpg<\/a>. Feeding this image to the re-encoding example application resulted in a crash at the exact same location mentioned in Zscaler\u2019s article. Figure 5 shows the context of the crash during a debugging session.<\/p>\n<figure class=\"image\"><img decoding=\"async\" title=\"Figure 5. The re-encoding example application crashes during the compression routine when handling a 12-bit JPG image\" src=\"https:\/\/web-assets.esetstatic.com\/wls\/2025\/12-25\/cve-2025-50165\/figure-5.png\" alt=\"Figure 5. The re-encoding example application crashes\" width=\"\" height=\"\"\/><figcaption><em>Figure 5. The re-encoding example application crashes during the compression routine when handling a 12-bit JPG image<\/em><\/figcaption><\/figure>\n<p>The repeated hex value <span style=\"font-family: courier new, courier, monospace;\">0xBAADF00D<\/span> pointed to by the memory address is a magic value used by the C runtime (CRT) heap when a program calls <span style=\"font-family: courier new, courier, monospace;\">HeapAlloc<\/span> to allocate memory. It marks the memory as uninitialized (see <a href=\"https:\/\/www.nobugs.org\/developer\/win32\/debug_crt_heap.html\">https:\/\/www.nobugs.org\/developer\/win32\/debug_crt_heap.html<\/a>).<\/p>\n<p>As indicated previously, both analyzed versions of <span style=\"font-family: courier new, courier, monospace;\">WindowsCodecs.dll<\/span> appear to be able to handle 16-bit precision JPG images. But when testing such images, the re-encoding application crashes when dereferencing the <span style=\"font-family: courier new, courier, monospace;\">compress_data_16 function<\/span> pointer, as observed in Figure 6.<\/p>\n<figure class=\"image\"><img decoding=\"async\" title=\"Figure 6. The re-encoding example application crashes during the compression routine when handling a 16-bit JPG image\" src=\"https:\/\/web-assets.esetstatic.com\/wls\/2025\/12-25\/cve-2025-50165\/figure-6.png\" alt=\"Figure 6. The re-encoding example application crashes during the compression routine\" width=\"\" height=\"\"\/><figcaption><em>Figure 6. The re-encoding example application crashes during the compression routine when handling a 16-bit JPG image<\/em><\/figcaption><\/figure>\n<p>Having reproduced the crash, we wondered whether this specific vulnerability was also present in the source code of the <span style=\"font-family: courier new, courier, monospace;\">libjpeg-turbo<\/span> library.<\/p>\n<h2>Exploring the source code<\/h2>\n<p>Going through the commits of <span style=\"font-family: courier new, courier, monospace;\">libjpeg-turbo<\/span> revealed that similar issues were resolved on December 18<sup>th<\/sup>, 2024, with commit <a href=\"https:\/\/github.com\/libjpeg-turbo\/libjpeg-turbo\/commit\/e0e18dea5433e600ea92d60814f13efa40a0d7dd\" target=\"_blank\" rel=\"noopener\">e0e18de<\/a>, introducing version 3.1.1. Essentially, the commit makes sure that structures are zero-initialized and that an error is raised if a pointer is <span style=\"font-family: courier new, courier, monospace;\">NULL<\/span>. It turns out that all the zero-initializations and checks introduced by this commit are absent in the vulnerable and patched versions of <span style=\"font-family: courier new, courier, monospace;\">WindowsCodecs.dll<\/span>.<\/p>\n<p>The patch message also hints at other potential vulnerable code paths and, more importantly, that crashes may also happen in the decompression process when manipulating a JPG image, as highlighted by the <a href=\"https:\/\/github.com\/libjpeg-turbo\/libjpeg-turbo\/commit\/e0e18dea5433e600ea92d60814f13efa40a0d7dd#diff-5d6ee1aad3500f31a47dc0a72914aa3dd8812211b00640d7e6b894ef2edc5f6d\" target=\"_blank\" rel=\"noopener\">diff of file jdapistd.c<\/a>, illustrated in Figure 7.<\/p>\n<figure class=\"image\"><img loading=\"lazy\" decoding=\"async\" title=\"Figure 7. Diff of decompression routines implemented in jdapistd.c\" src=\"https:\/\/web-assets.esetstatic.com\/wls\/2025\/12-25\/cve-2025-50165\/figure-7.png\" alt=\"Figure 7. Diff of decompression routines\" width=\"770\" height=\"658\"\/><figcaption><em>Figure 7. Diff of decompression routines implemented in <\/em><span style=\"font-family: courier new, courier, monospace;\">jdapistd.c<\/span><\/figcaption><\/figure>\n<p>As the commit description clearly specifies, a calling application would crash (due to the dereference of an uninitialized function pointer) <strong>only<\/strong> if it erroneously changes the <span style=\"font-family: courier new, courier, monospace;\">data_precision<\/span> field after calling the <span style=\"font-family: courier new, courier, monospace;\">jpeg_start_compress<\/span> or <span style=\"font-family: courier new, courier, monospace;\">jpeg_start_decompress<\/span> routines. This creates a rather specific and likely unrealistic scenario where an application using <span style=\"font-family: courier new, courier, monospace;\">WindowsCodecs.dll<\/span> would alter the state of internal structures. While such applications may exist, it does not appear that the Windows Imaging Component API allows such behavior.<\/p>\n<h2>Exploitability<\/h2>\n<p>As revealed by our root cause analysis, the core issue of CVE\u20112025\u201150165 resides in <span style=\"font-family: courier new, courier, monospace;\">WindowsCodecs.dll<\/span>\u2019s handling of JPG images with a data precision value other than the conventional and standard 8-bit. The two precision-specific function pointers (<span style=\"font-family: courier new, courier, monospace;\">compress_data_12<\/span> and <span style=\"font-family: courier new, courier, monospace;\">compress_data_16<\/span>) were uninitialized during the compression process, creating two vulnerable code paths that seem to be reachable <em>only when (re-)encoding<\/em> a JPG image. Simply opening, and therefore decoding and rendering, a specially crafted image will not trigger the vulnerability. However, the vulnerable function <span style=\"font-family: courier new, courier, monospace;\">jpeg_finish_compress<\/span> could be called if the image is saved or if a host application, such as the Microsoft Photos application, creates thumbnails of images, as shown in Figure 8.<\/p>\n<figure class=\"image\"><img decoding=\"async\" title=\"Figure 8. The vulnerable jpeg_finish_compress function is called during the creation of a thumbnail for an image\" src=\"https:\/\/web-assets.esetstatic.com\/wls\/2025\/12-25\/cve-2025-50165\/figure-8.png\" alt=\"Figure 8. The vulnerable jpeg_finish_compress function is called\" width=\"\" height=\"\"\/><figcaption><em>Figure 8. The vulnerable <\/em><span style=\"font-family: courier new, courier, monospace;\">jpeg_finish_compress<\/span><em> function is called during the creation of a thumbnail for an image<\/em><\/figcaption><\/figure>\n<p>In order for a program to be considered vulnerable, it needs the following characteristics:<\/p>\n<ul>\n<li>makes use of a vulnerable version of <span style=\"font-family: courier new, courier, monospace;\">WindowsCodecs.dll<\/span>,<\/li>\n<li>does not crash or abort while decoding a 12-bit or 16-bit JPG file, and<\/li>\n<li>allows the image to be re-encoded.<\/li>\n<\/ul>\n<p>Moreover, as mentioned by Zscaler researchers, an address leak and enough control over the heap are mandatory to exploit this vulnerability.<\/p>\n<h2>Conclusion<\/h2>\n<p>Although JPG is older, widely used, and perhaps the most popular digital image format in <a href=\"https:\/\/en.wikipedia.org\/wiki\/Fuzzing\" target=\"_blank\" rel=\"noopener\">fuzz testing<\/a>, vulnerabilities can still be found in some codecs. This study of CVE\u20112025\u201150165 also highlights the importance of keeping up with security updates when using third-party libraries.<\/p>\n<p>Root cause analysis along with patch diffing proved a very powerful combination that allowed us to answer our initial questions. We found out that the bug can be triggered when <span style=\"font-family: courier new, courier, monospace;\">WindowsCodecs.dll<\/span> encodes a 12-bit or a 16-bit precision JPG stream as both precision-specific function pointers were neither initialized nor checked before being dereferenced. Additionally, we figured out that this process happens when such an image is saved or when a thumbnail is created from it.<\/p>\n<p>This investigation led us to a similar conclusion as Microsoft\u2019s regarding the exploitability of this vulnerability. Indeed, as WindowsCodecs.dll is a library, a host application would be considered vulnerable if it allows JPG images to be (re-)encoded, and exploitable only if an attacker has enough control over the application (address leak, heap manipulation). Putting it all together, it seems indeed that exploitation is unlikely.<\/p>\n<p>Finally, it\u2019s worth mentioning that, as of this writing and according to our tests, newer versions of <span style=\"font-family: courier new, courier, monospace;\">WindowsCodecs.dll<\/span> (such as 10.0.22621.6133, SHA-1: <span style=\"font-family: courier new, courier, monospace;\">3F3767D05E5A91184005D98427074711F68D9950<\/span>) implement the different changes mentioned in <span style=\"font-family: courier new, courier, monospace;\">libjpeg-turbo<\/span>\u2019s commit, effectively addressing the lack of initialization and function pointer verification.<\/p>\n<p><a href=\"https:\/\/www.eset.com\/int\/business\/services\/threat-intelligence\/?utm_source=welivesecurity.com&amp;utm_medium=referral&amp;utm_campaign=wls-research&amp;utm_content=revisiting-cve-2025-50165-critical-flaw-windows-imaging-component&amp;sfdccampaignid=7011n0000017htTAAQ\" target=\"_blank\" rel=\"noopener\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/web-assets.esetstatic.com\/wls\/eti-eset-threat-intelligence.png\" alt=\"\" width=\"915\" height=\"296\"\/><\/a><\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>ESET researchers examined CVE\u20112025\u201150165, a serious Windows vulnerability described to grant remote code execution by merely opening a<\/p>\n","protected":false},"author":1,"featured_media":104,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-103","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-security"],"_links":{"self":[{"href":"https:\/\/escudodigital.uy\/index.php\/wp-json\/wp\/v2\/posts\/103","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/escudodigital.uy\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/escudodigital.uy\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/escudodigital.uy\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/escudodigital.uy\/index.php\/wp-json\/wp\/v2\/comments?post=103"}],"version-history":[{"count":0,"href":"https:\/\/escudodigital.uy\/index.php\/wp-json\/wp\/v2\/posts\/103\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/escudodigital.uy\/index.php\/wp-json\/wp\/v2\/media\/104"}],"wp:attachment":[{"href":"https:\/\/escudodigital.uy\/index.php\/wp-json\/wp\/v2\/media?parent=103"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/escudodigital.uy\/index.php\/wp-json\/wp\/v2\/categories?post=103"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/escudodigital.uy\/index.php\/wp-json\/wp\/v2\/tags?post=103"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}