Wednesday, February 11, 2026

Micropatches released for Windows Telephony Service Elevation of Privilege Vulnerability (CVE-2024-43626)

 


Our new CVE tracking app has been working hard these days, finding things our poor human eyes were unable or too tired to see. In this case, it alerted us about a vulnerability that was described in an article about another vulnerability we had long since patched.

CVE-2024-43626, a privilege escalation vulnerability in Windows Telephony Service, was described in an article by Đào Tuấn Linh of Starlabs. The article was primarily about CVE-2024-26230, which we had patched in August 2024, but it also mentioned a related issue CVE-2024-43626, reportedly co-analyzed by Chen Le Qi of Starlabs. While the proof-of-concept was only provided for the "main" vulnerability, we were able to modify it to trigger the secondary one.

 

The Vulnerability 

The vulnerability is in the way Windows Telephony Service reads some registry value to the memory, whereby such value could be loaded without the trailing zero terminator. Should this happen, a subsequent _wcsupr operation would upper-case a string beyond the end of the buffer - potentially corrupting the memory there in such a way as to lead to arbitrary code execution.

 

Microsoft's Patch

Microsoft's patch modified the vulnerable code so that it correctly reads the registry value and makes sure it is zero-terminated.

 

Our Patch

Our patch is logically identical to Microsoft's. 

Let's see our patch in action. First, a low-privileged user launches the POC while 0patch is disabled, which results in crashing the Telephony Service. With 0patch enabled, the POC fails to crash the service.


 

 

Micropatch Availability

Micropatches were written for the following security-adopted Windows versions:

  1. Windows 11 v21H2 - fully updated
  2. Windows 10 v21H2 - fully updated
  3. Windows 10 v21H1 - fully updated
  4. Windows 10 v20H2 - fully updated
  5. Windows 10 v2004 - fully updated
  6. Windows 10 v1909 - fully updated
  7. Windows 10 v1809 - fully updated
  8. Windows 10 v1803 - fully updated
  9. Windows 7 - fully updated with no ESU, ESU 1, ESU 2 or ESU 3
  10. Windows Server 2008 R2 - fully updated with no ESU, ESU 1, ESU 2, ESU 3 or ESU 4
  11. Windows Server 2012 - fully updated with no ESU or ESU 1
  12. Windows Server 2012 R2 - fully updated with no ESU or ESU 1 


Micropatches have already been distributed to, and applied on, all affected online computers with 0patch Agent in PRO or Enterprise accounts (unless Enterprise group settings prevented that).

Vulnerabilities like these get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things. 

We'd like to thank Đào Tuấn Linh and Chen Le Qi of Starlabs for discovering this vulnerability and publishing their analysis, which allowed us to create a patch and protect 0patch users against this issue.

If you're new to 0patch, create a free account in 0patch Central, start a free trial, then install and register 0patch Agent. Everything else will happen automatically. No computer reboot will be needed.

Did you know 0patch security-adopted Windows 10 and Office 2016 and 2019 when they went out of support this month, allowing you to keep using them for at least 3 more years (5 years for Windows 10)? Read more about it here and here

To learn more about 0patch, please visit our Help Center.








 

Tuesday, February 3, 2026

Micropatches released for Microsoft Excel Remote Code Execution Vulnerability (CVE-2025-62203)

 

 

November 2025 Windows Updates brought a patch for CVE-2025-62203, a remote code execution vulnerability in Microsoft Excel that could allow a remote attacker to have their malicious code executed on user's computer upon opening an Excel file.

The vulnerability was discovered and reported to Microsoft by Quan Jin with DBAPPSecurity

 

The Vulnerability 

The vulnerability is a use-after-free issue, whereby opening a malicious Excel document results in an already freed memory block being freed again, corrupting the heap. A carefully constructed document could potentially exploit this fact for arbitrary code execution.

The attacker would have to convince the user to open their malicious Excel document. Upon opening the document, Excel complains that the document was damaged and offers to recover it; choosing "Yes" to start the recovery process leads to the vulnerability being triggered. 

Among our security-adopted Office versions, we found this vulnerability to affect not only Office 2016 and 2019 click-to-run, but also Office 2013. Office 2010 is not affected. 

 

Microsoft's Patch

Microsoft changed a lot of code in excel.exe, making it hard to identify which of the changes were associated with this issue. Fixing use-after-free issues "by the book" sometimes requires many changes in various parts of the code; instead of trying to untangle these changes, we decided to take our time-tested approach to patching this type of issues.

 

Our Patch

Our time-tested approach is to remove the superfluous free call. We've done this many times before, and arguably, this approach can lead to a small memory leak (unused memory being left allocated, leading to Excel consuming a little bit more memory each time the execution goes through our patch). However, we assessed that under normal circumstances, the accumulated leak would be very small, and of course reset to zero upon each closing of the Excel application. In addition, the memory leak is likely to only occur in the additional excel.exe process launched for recovering the document in the background, which gets closed after recovery anyway.

Let's see our patch in action on a fully updated Excel 2019 click-to-run, which we have security-adopted last October when it received its last official security patches. First, the user opens the malicious poc.xls document while 0patch is disabled and agrees to have Excel recover it, which results in Excel crashing (as indicated in the Application Event log). With 0patch enabled, doing the same fails to crash Excel.


 

 

Micropatch Availability

Micropatches were written for the following 32-bit and 64-bit security-adopted Microsoft Office versions:

  1. Microsoft Office 2019 click-to-run - updated with all available updates (version 2508, build 19127.20302)
  2. Microsoft Office 2016 click-to-run - updated with all available updates (version 2508, build 19127.20302)
  3. Microsoft Office 2013 - updated with all available updates

Micropatches have already been distributed to, and applied on, all affected online computers with 0patch Agent in PRO or Enterprise accounts (unless Enterprise group settings prevented that).

Vulnerabilities like these get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things. 

We'd like to thank Quan Jin with DBAPPSecurity for sharing vulnerability details and POC, which allowed us to create a patch for this issue and protect our users.

If you're new to 0patch, create a free account in 0patch Central, start a free trial, then install and register 0patch Agent. Everything else will happen automatically. No computer reboot will be needed.

Did you know 0patch security-adopted Windows 10 and Office 2016 and 2019 when they went out of support in October 2025, allowing you to keep using them for at least 3 more years (5 years for Windows 10)? Read more about it here and here

To learn more about 0patch, please visit our Help Center.

Wednesday, January 28, 2026

Micropatches Released for Microsoft Office Security Feature Bypass Vulnerability (CVE-2026-21509)


Two days ago, Microsoft released an emergency update for Microsoft Office, resolving CVE-2026-21509, a vulnerability in Office that was found to be exploited in the wild. Microsoft's advisory initially stated that vulnerability details were publicly disclosed, but later reversed that claim. The advisory provided very little information on the vulnerability but it did provide mitigation recommendations for those who can't immediately apply the update.

These recommendations indicate the vulnerability relies on the ability to embed a Shell.Explorer.1 OLE object (Windows Class ID {EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}) in an Office document. This object is actually an embedded Internet Explorer or Windows Explorer component, and has been an instrument of various exploits and security tricks in the past. Most notably, Yorick Koster wrote a very good article about embedding such objects in Office documents back in 2018, and how double-clicking such embedded object and confirming an (admittedly not too scary-looking) security warning resulted in launching arbitrary executable on user's computer.

Interestingly, exploits described in Yorick's 2018 article still worked on fully updated Microsoft Office until two days ago*, with the January 26, 2026 update disabling them - either intentionally or as a side effect.

So did Microsoft decide to patch Yorick's 2018 exploits in 2026 once exploitation has been detected? Only they know, but it seems unlikely that they'd urgently patch something that required a user to double-click something in a document and then also click through a security warning.

(* As Will Dormann noticed, Microsoft did provide some form of protection against this issue outside of Office updates, likely through Windows Defender, but we have no information on when they did that.)


Microsoft's Patch

We don't know what exactly Microsoft patched with the January 26, 2026 Office update. There are multiple changes in Office binaries, none of which immediately seems like an obvious patch, and said update also didn't set a "kill bit" for Class ID {EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}. We therefore decided not to investigate that further, also because even if we did locate their patch, we'd still need a POC to reproduce the vulnerability and test our own patch. No POC was available at the time of this writing - or if it was available in some malware repository such as Virus Total, it could not be identified based on available information.

Importantly, Microsoft patched this issue for still-supported Office versions, but also for "volume licensed" (MSI) versions of Office 2016 and 2019 - even if they went out of support in October 2025. Remember, volume licensed Office versions are getting updates via Windows Update, and Microsoft announced that these versions may still receive additional security patches after their end-of-support date.

In contrast, click-to-run Office 2016 and 2019 versions actually stopped receiving Microsoft's patches after October 2025, and have not received official patches for this vulnerability (nor did Office 2010 and Office 2013, which we're still providing security patches for). Therefore, we developed our own patches for these versions and issued them today.

 

Our Patch

Our patch implements Microsoft's workaround from their advisory: it emulates the kill bit for Class ID {EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B}, effectively preventing embedded OLE objects of this class from being launched. This is presumably a wider countermeasure that prevents exploitation of CVE-2026-21509 but may also block some other uses of the same OLE object. We find it hard to imagine a legitimate and functional use of this object in an Office document, so we actually prefer such wider approach.

After our patch is applied, opening an embedded Shell.Explorer.1 OLE object in an Office document will be blocked and will result in the following dialog:  

 


 
Note that our patches are the only available patches for Office 2016 and 2019 click-to-run, which we had security-adopted last October. We will provide these security patches for at least 3 years (longer if demand lasts) to help Office 2016 and 2019 users keep their security posture up. Note that at some point, Microsoft will stop providing security updates for volume licensed 2016 and 2019 versions as well, at which point our security patches will be the only patches for these as well. If you're using volume licensed Office versions, keep applying Microsoft's updates, as our future patches for these will be written for "fully-updated" Office.


Micropatch Availability

Micropatches were written for the following 32-bit and 64-bit security-adopted Microsoft Office versions:

  1. Microsoft Office 2019 click-to-run - updated with all available updates (version 2508, build 19127.20302)
  2. Microsoft Office 2016 click-to-run - updated with all available updates (version 2508, build 19127.20302)
  3. Microsoft Office 2013 - updated with all available updates
  4. Microsoft Office 2010 - updated with all available updates 

Micropatches have already been distributed to, and applied on, all affected online computers with 0patch Agent in PRO or Enterprise accounts (unless Enterprise group settings prevented that).

Vulnerabilities like these get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things. 

If you're new to 0patch, create a free account in 0patch Central, start a free trial, then install and register 0patch Agent. Everything else will happen automatically. No computer reboot will be needed.

Did you know 0patch security-adopted Windows 10 and Office 2016 and 2019 when they went out of support in October 2025, allowing you to keep using them for at least 3 more years (5 years for Windows 10)? Read more about it here and here

To learn more about 0patch, please visit our Help Center.








 

Tuesday, January 6, 2026

Micropatches Released for Credential Security Support Provider Protocol (CredSSP) Elevation of Privilege Vulnerability (CVE-2025-47987)

 


July 2025 Windows Updates brought a patch for CVE-2025-47987, a privilege escalation vulnerability in Windows Credential Security Support Provider that could allow a local low-privileged attacker to execute arbitrary code as Local System user. The vulnerability was discovered and reported to Microsoft by Erik Egsgard with Field Effect.

Subsequently, security researcher Kryptoenix reverse-engineered Microsoft's patch and published a detailed analysis of this vulnerability and shared a proof-of-concept.

 

The Vulnerability 

The vulnerability is a heap-based buffer overflow that occurs because of a numeric overflow when length of user-supplied data is calculated. The numeric overflow leads to the result being a small number, so the allocated buffer for the user-supplied data ends up being too small for the data. When the data is copied to the buffer, adjacent memory blocks on the heap are overwritten, which in the case of the proof-of-concept (POC) results in memory corruption and crashing of lsass.exe, but a carefully crafted data block could lead to arbitrary code execution as Local System.

 

Microsoft's Patch

Microsoft's patch replaced the unsafe addition operation with a call to a safe addition function that detects an overflow and terminates the processing of such user-supplied data.

 

Our Patch

Our patch is logically identical to Microsoft's. 

Let's see our patch in action. First, a low-privileged user launches the POC while 0patch is disabled, which results in crashing lsass.exe. With 0patch enabled, the POC fails to crash lsass.exe (although it reports success).


 

 

Micropatch Availability

Micropatches were written for the following security-adopted Windows versions:

  1. Windows 11 v21H2 - fully updated
  2. Windows 10 v21H2 - fully updated
  3. Windows 10 v21H1 - fully updated
  4. Windows 10 v20H2 - fully updated
  5. Windows 10 v2004 - fully updated
  6. Windows 10 v1909 - fully updated
  7. Windows 10 v1809 - fully updated
  8. Windows 10 v1803 - fully updated
  9. Windows 7 - fully updated with no ESU, ESU 1, ESU 2 or ESU 3
  10. Windows Server 2008 R2 - fully updated with no ESU, ESU 1, ESU 2, ESU 3 or ESU 4
  11. Windows Server 2012 - fully updated with no ESU or ESU 1
  12. Windows Server 2012 R2 - fully updated with no ESU or ESU 1 


Micropatches have already been distributed to, and applied on, all affected online computers with 0patch Agent in PRO or Enterprise accounts (unless Enterprise group settings prevented that).

Vulnerabilities like these get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things. 

We'd like to thank Erik Egsgard with Field Effect for discovering this vulnerability, and Kryptoenix for analyzing it and publishing their analysis and proof-of-concept, which allowed us to create a patch and protect 0patch users against this issue.

If you're new to 0patch, create a free account in 0patch Central, start a free trial, then install and register 0patch Agent. Everything else will happen automatically. No computer reboot will be needed.

Did you know 0patch security-adopted Windows 10 and Office 2016 and 2019 when they went out of support this month, allowing you to keep using them for at least 3 more years (5 years for Windows 10)? Read more about it here and here

To learn more about 0patch, please visit our Help Center.








 

Friday, December 12, 2025

Free Micropatches for Windows Remote Access Connection Manager DoS (0day)


 

[Update 2/10/2026] With February 10, 2026 Windows Updates, Microsoft patched this vulnerability on still-supported affected Windows versions and assigned it CVE-2026-21525. By that time, our users on both supported and legacy Windows versions have had this vulnerability already patched for 60 days.

During our investigation of CVE-2025-59230, a Windows Remote Access Connection Manager elevation of privilege vulnerability that was patched by Microsoft with October 2025 Windows updates, we found an exploit for it that nicely demonstrated local arbitrary code execution as Local System when launched as a non-admin Windows user.

Interestingly though, this exploit - while exploiting CVE-2025-59230 - also included an exploit for another vulnerability that turned out to have remained unpatched to this day. Let's take a closer look.

CVE-2025-59230 is a fairly simple vulnerability, conceptually similar to CVE-2025-49760, which we had recently patched. Upon startup, the Remote Access Connection Manager ("RasMan") service registers an RPC endpoint that other services subsequently connect to and trust. The vulnerability lies in the fact that when RasMan is not running, any process - even attacker's unprivileged exploit - can register the same RPC endpoint and have privileged services connect to it and trust its responses. This trust can be abused to instruct a connecting service to execute attacker's code.

So much for CVE-2025-59230. But you probably noticed the "when RasMan is not running" part; the RasMan service usually gets stared automatically upon Windows startup (even though it may be configured as "manual" on Windows 11), and even a scheduled task created by a local attacker would not be quick enough to find it in a "not running" state and outrun it towards registering its RPC endpoint.

Consequently, a working exploit must therefore be able to (also) stop the RasMan service to release said RPC endpoint. And this was the second, non-obvious vulnerability that the CVE-2025-59230 exploit we had found utilizes: one that allows an unprivileged user to crash the RasMan service. Without this capability, CVE-2025-59230 could hardly be exploited. 

We alerted Microsoft about this issue; they will likely provide an official patch for still-supported Windows versions in one of future Windows updates.


The Vulnerability  

We traced the vulnerability to a flawed coding logic, whereby a circular linked list is being traversed in a loop, and the loop is exited if the current element of the list points to the first element, meaning that the entire list has been traversed. Inside the loop, the pointer to the current element is compared with NULL - which is a reasonable sanity check. If the pointer is not NULL, some value of the current element is read and can potentially also exit the loop. But if the pointer is NULL...

... the loop is not exited - rather, the execution continues by reading the pointer to the next list element from this NULL pointer. This causes memory access violation and crashes the RasMan service.

Let's look at the vulnerable code on the latest Windows 11 version. The image below shows the code traversing the linked list, including a flawed sanity check. 


To be fair, it's easy to imagine how this error was made: when expecting a circular linked list, this function could - justifiably - rely on whoever had built the list to have done it properly, guaranteeing that each element will point to an actual next element, not NULL. The programmer here was extra cautious to have decided to add a check for a NULL pointer. However, this check probably could never have been tested for correctness because in test cases, all linked lists have been valid and did not contain elements pointing to NULL.

What the check should have done is exit the loop if a NULL were encountered.

 

Our Patch

Our patch does exactly that. As shown on the image below, our patch (code added in blue and green code blocks) injects another check for a NULL pointer that exits the loop.

 


 

Let's see the vulnerability and our patch in action. On the video you can see that with 0patch enabled., the exploit is able to crash the RasMan service, and with 0patch enabled, the crash does not occur. (Errata: the video highlights the "Remote Access Auto Connection Manager" instead of the "Remote Access Connection Manager".)


 

 

Micropatch Availability

Micropatches were written for the following security-adopted as well as still-supported Windows versions:

  1. Windows 11 v25H2 - fully updated
  2. Windows 11 v24H2 - fully updated
  3. Windows 11 v23H2 - fully updated
  4. Windows 11 v22H2 - fully updated
  5. Windows 11 v21H2 - fully updated
  6. Windows 10 v22H2 - fully updated
  7. Windows 10 v21H2 - fully updated
  8. Windows 10 v21H1 - fully updated
  9. Windows 10 v20H2 - fully updated
  10. Windows 10 v2004 - fully updated
  11. Windows 10 v1909 - fully updated
  12. Windows 10 v1809 - fully updated
  13. Windows 10 v1803 - fully updated
  14. Windows 7 - fully updated with no ESU, ESU 1, ESU 2 or ESU 3
  15. Windows Server 2008 R2 - fully updated with no ESU, ESU 1, ESU 2, ESU 3 or ESU 4
  16. Windows Server 2012 - fully updated with no ESU or ESU 1
  17. Windows Server 2012 R2 - fully updated with no ESU or ESU 1
  18. Windows Server 2016 - fully updated
  19. Windows Server 2019 - fully updated
  20. Windows Server 2022 - fully updated
  21. Windows Server 2025 - fully updated

 

Micropatches have already been distributed to, and applied on, all affected online computers with 0patch Agent in FREE, PRO or Enterprise accounts (unless Enterprise group settings prevented that). 

As always, we included these 0day patches in our FREE plan until the original vendor has provided their official patch. 

Note that about 40% of our customers are using 0patch on still-supported Windows versions like Windows 11 25H2 and Server 2025 as an additional defense against 0days. 

Vulnerabilities like these get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, start a free trial, then install and register 0patch Agent. Everything else will happen automatically. No computer reboot will be needed.

Did you know 0patch security-adopted Windows 10 and Office 2016 and 2019 when they went out of support last October, allowing you to keep using them for at least 3 more years (5 years for Windows 10)? Read more about it here and here

To learn more about 0patch, please visit our Help Center.

Tuesday, December 2, 2025

Microsoft Silently Patched CVE-2025-9491 - We Think Our Patch Provides More Security

Patching What You See vs. Patching What You Execute


Summary: Trend Micro discovered that attackers have long been using a trick to hide what a Windows shortcut actually does, preventing users from seeing malicious commands. Microsoft decided this was not patch-worthy. Others then found this same trick still being exploited, and the issue got a CVE. Microsoft doubled down, but silently patched the issue so that malicious commands can no longer be hidden. We created a different patch that actually blocks discovered attacks.


The story - or at least its public part - begins on March 18, 2025, with Trend Micro's publication of Advisory ZDI-25-148 and an associated article titled Windows Shortcut Exploit Abused as Zero-Day in Widespread APT Campaigns. This article by Peter Girnus and Aliakbar Zahravi describes how they observed close to a thousand malicious Windows shortcut (.lnk) files being used in various offensive campaigns dating back to 2017. These shortcut files were crafted such that viewing their properties in Windows, one could not see the entire commands the shortcuts executed. The trick was an old one: using various "whitespace" characters to move the malicious part of the command out of user's sight.

For instance, the article shows how Windows 11 would show properties of a shortcut file with a target like this:

conhost.exe<265 spaces>calc.exe

 

Windows 11 showing an obfuscated target in a Windows shortcut
(Image borrowed from Trend Micro's article)

As you can see, the Target field shows only space characters (selected, therefore in blue), and even scrolling left or right would not reveal the presence of "calc.exe", or whatever malicious command there might be at the end. Instead of space characters, various other characters could be used to achieve a similar effect.

As Peter and Aliakbar explained, Microsoft was notified about this issue but decided it didn't meet their bar for servicing. In other words, they would not consider it a vulnerability worth patching.

At this point we have to admit we (too?) misunderstood the problem Trend Micro was presenting in April. We thought the issue was just that padding a malicious command with spaces would not show the malicious command in the dialog because the dialog always showed the end of the command - and when padded with spaces, the end is just all spaces. We considered that a bit silly as the user could always scroll back to the start of the field and see everything - and we found Microsoft's decision to not fix this reasonable, albeit the trick was actually being used in malicious campaigns.

After all, what could be done? One can't ban whitespace characters from the command string, and if the Properties dialog showed the beginning of the target instead of the end, malicious code could then be hidden at the end. In addition to these technical details, there was also a social engineering aspect: what profile of user gets a PDF-lookalike Windows shortcut file, checks its properties, sees something like "powershell.exe" - without the hidden malicious arguments - and based on that still decides to double-click it? Most users, we thought, would either be non-IT persons and not look at properties at all, or would be somewhat IT persons and probably concerned by seeing some script there, likely also scrolling left and right in the Target field to see the whole thing.

Following this reasoning, we also decided not to patch this issue.

Case closed.

Until end of October, that is, when Arctic Wolf published an article titled UNC6384 Weaponizes ZDI-CAN-25373 Vulnerability to Deploy PlugX Against Hungarian and Belgian Diplomatic Entities. UNC6384 is code name for a Chinese-affiliated threat actor, and ZDI-CAN-25373 is Trend Micro's working ID for the described issue.

Arctic Wolf identified a campaign by threat actor UNC6384 specifically targeting Hungarian and Belgian diplomatic entities during September and October 2025 - using Windows shortcuts exploiting the described vulnerability. This discovery revived the interest in this issue, which was by then assigned CVE-2025-9491. Microsoft was under some heat in the media for not having patched this exploited-in-the-wild issue yet, but they doubled-down with and advisory titled Microsoft Guidance on CVE-2025-9491 Windows LNK File UI Behavior.

In this advisory, Microsoft claimed that "during the user experience, the user is warned several times that proceeding may be harmful."

Now, "several times" is a bit of an exaggeration for what must have been just once in described actual attacks, but fact is, if one downloads a .lnk file from the Internet (which has to be packaged in a ZIP archive as browsers deliberately mangle its file name to protect users), it will have Mark of the Web and double-clicking it will warn the user about opening a potentially harmful file from the Internet. That is, unless the attacker knows of some vulnerability that bypasses Mark of the Web like this one.

The advisory concludes: "Due to the user interaction involved and the fact that the system already warns users that this format is untrusted, Microsoft does not consider this a vulnerability."

Having read this advisory with our then-current understanding of the issue, we still agreed with Microsoft's conclusion. 

But then we looked again. And finally saw what the issue really was: it was not just the sliding of malicious content out of the Target field's default focus. Instead, a .lnk file structure allows the Target arguments to be a very long string (tens of thousands of characters), but the Properties dialog only shows the first 260 characters, silently cutting off the rest.

So it is possible to construct a .lnk file that runs a reeeeealy long PowerShell or BAT script, but only the first 260 characters of it would be shown to the user who viewed its properties. And these characters could be mostly "whitespace" characters to push the interesting bits entirely out of the Target field - even if the user scrolled to the very end.

Now this makes it more interesting: it's now a matter of trust in the user interface. The string that Windows are showing to you -- is not the entire string that will actually be executed. Even if you're an IT person, you can be fooled by this issue because you rightfully expect the UI can be trusted to show you the whole command.

This did look patch-worthy, so we decided to analyze the issue deeper in order to come up with a good patch.

While we were developing our patch, the November Patch Tuesday brought new Windows Updates. And as expected ("Microsoft does not consider this a vulnerability"), there was no mention of anything remotely akin to this issue among its 63 patched vulnerabilities. [Update 12/4/2025: see * below]

However...

 

Microsoft's Patch

However, we noticed something did change with November* Windows Updates: now, the Properties dialog of a .lnk file shows the entire Target command with arguments, no matter how long it is. The theoretically-up-to-32k-character-long string is now shown in the same single-line field that can't even reveal an entire modest-sized command without selecting some text and moving the mouse left or right. But okay, at least one can select all, copy and paste the string to a text editor.

* [Update 12/4/2025: A friend in the know subsequently pointed out that this change had been deployed by Microsoft already in June 2025 but it may have been activated gradually. For instance, one of our testing Windows 11 24H2 computers we re-inspected had it activated in August. Our claim that it was deployed in November was therefore incorrect. Props to said friend for pointing this out.] 

The issue was apparently demoted from vulnerability to functional bug, silently fixed without an advisory, and trust in the user interface was restored.

Arguably, if the problem was defined as "The properties dialog does not always show exactly what will be executed," it would indeed have been resolved. But this approach was weird: namely, it has always been the case that the "ordinary" way to create or modify a Windows shortcut - via Explorer user interface - only allowed you to enter up to 260 characters to the Target field. The only way for this string to be longer is to create the shortcut programmatically, e.g. using Windows API. (And some application may be creating such legitimate shortcuts for its own use.) So how much would showing all Target characters in a small field improve chances for victims targeted in actual attacks?

 

Our Patch

We decided to take a different route: Our premise was that a legitimate non-malicious .lnk file that regular Windows users come across would be created manually and would therefore never have a Target with more than 260 characters. However, we still accept that shortcut files with more than 260 character Target can be valid, just not meant for manual opening by users. Consequently, our patch has the following logic:

If the process opening the .lnk file is Windows Explorer, AND the Target has more than 260 characters, then we cut the Target at 260 characters and alert the user that a suspicious .lnk file was shortened.

 


 

Our patch would break the 1000+ malicious shortcuts identified by Trend Micro for all targeted users, while Microsoft's patch would only allow the most cautious among these users - who would probably not launch such shortcuts anyway - to see the entire malicious command string. Even though malicious shortcuts could be constructed with fewer than 260 characters, we believe disrupting actual attacks detected in the wild can make a big difference for those targeted.

Let's see our patch in action. On the video below you can see that a shortcut file looking like a PDF document has a Target that doesn't fully show in the Properties dialog, while a hex editor reveals its full content. Launching it with 0patch disabled results in spawning the calculator (which was hidden from the Properties dialog), but launching it with 0patch enabled results in a security notification and the execution of only the first 260 characters of the shortcut's Target.


 

 

Micropatch Availability

Micropatches were written for the following security-adopted Windows versions:

  1. Windows 11 v22H2 - fully updated
  2. Windows 11 v21H2 - fully updated
  3. Windows 10 v22H2 - fully updated
  4. Windows 10 v21H2 - fully updated
  5. Windows 10 v21H1 - fully updated
  6. Windows 10 v20H2 - fully updated
  7. Windows 10 v2004 - fully updated
  8. Windows 10 v1909 - fully updated
  9. Windows 10 v1809 - fully updated
  10. Windows 10 v1803 - fully updated
  11. Windows 7 - fully updated with no ESU, ESU 1, ESU 2 or ESU 3
  12. Windows Server 2008 R2 - fully updated with no ESU, ESU 1, ESU 2, ESU 3 or ESU 4
  13. Windows Server 2012 - fully updated with no ESU or ESU 1
  14. Windows Server 2012 R2 - fully updated with no ESU or ESU 1 

In addition, patches were written for the following still-supported fully updated Windows Server versions, which for some reason did not receive a patch from Microsoft (note that Server 2025 did get the patch for some reason):

  1. Windows Server 2016 
  2. Windows Server 2019
  3. Windows Server 2022 


We'd like to thank Peter Girnus and Aliakbar Zahravi with Trend Micro for sharing the details, which allowed us to create a patch for our users.

Micropatches have already been distributed to, and applied on, all affected online computers with 0patch Agent in PRO or Enterprise accounts (unless Enterprise group settings prevented that).

Vulnerabilities like these get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, start a free trial, then install and register 0patch Agent. Everything else will happen automatically. No computer reboot will be needed.

Did you know 0patch security-adopted Windows 10 and Office 2016 and 2019 when they went out of support last October, allowing you to keep using them for at least 3 more years (5 years for Windows 10)? Read more about it here and here

To learn more about 0patch, please visit our Help Center.

Thursday, October 30, 2025

Micropatches Released for Windows Installer Elevation of Privilege Vulnerability (CVE-2025-50173)


August 2025 Windows Updates brought a patch for CVE-2025-50173, a privilege escalation vulnerability in Windows Installer that could allow a local low-privileged attacker to execute arbitrary code as Local System user.

This vulnerability is really an extension (or bypass, if you will), of CVE-2024-38014, which we had patched a year ago

 

The Vulnerability 

The vulnerability was again in the "Repair" operation of Windows Installer, which has been patched many times in the past (see this article for context). Much like before, under certain conditions a non-admin user could perform the repair operation on an installed application and exploit the resulting elevated processes.

 

Microsoft's Patch

Microsoft's patch changes the behavior of Windows Installer such that it requires elevation (i.e., admin credentials) when a repair operation is initiated.

 

Our Patch

Our patch is logically identical to Microsoft's. 

Let's see our patch in action. First, a low-privileged user initiates a repair operation on an already installed application that fulfills conditions for this vulnerability. Without 0patch, the repair operation concludes without a UAC (elevation) prompt. When the repair operation is attempted with 0patch enabled (and our patch for CVE-2025-50173 therefore applied), the user is required to provide administrative credentials.


 

 

Micropatch Availability

Micropatches were written for the following security-adopted Windows versions:

  1. Windows 11 v21H2 - fully updated
  2. Windows 10 v22H2 - fully updated
  3. Windows 10 v21H2 - fully updated
  4. Windows 10 v21H1 - fully updated
  5. Windows 10 v20H2 - fully updated
  6. Windows 10 v2004 - fully updated
  7. Windows 10 v1909 - fully updated
  8. Windows 10 v1809 - fully updated
  9. Windows 10 v1803 - fully updated
  10. Windows 7 - fully updated with no ESU, ESU 1, ESU 2 or ESU 3
  11. Windows Server 2008 R2 - fully updated with no ESU, ESU 1, ESU 2, ESU 3 or ESU 4
  12. Windows Server 2012 - fully updated with no ESU or ESU 1
  13. Windows Server 2012 R2 - fully updated with no ESU or ESU 1 


Micropatches have already been distributed to, and applied on, all affected online computers with 0patch Agent in PRO or Enterprise accounts (unless Enterprise group settings prevented that).

Vulnerabilities like these get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, start a free trial, then install and register 0patch Agent. Everything else will happen automatically. No computer reboot will be needed.

Did you know 0patch security-adopted Windows 10 and Office 2016 and 2019 when they went out of support this month, allowing you to keep using them for at least 3 more years (5 years for Windows 10)? Read more about it here and here

To learn more about 0patch, please visit our Help Center.