From this point on, we will walk you through the vulnerabilities we discovered during our bug hunting journey. To give you a quick preview: by the end of this journey, we reported over 10 vulnerabilities to MSRC and successfully earned several CVEs.

4.1 Four Key Vulnerabilities

Next, we’ll introduce the four vulnerabilities we discovered.

• Case 87975: Type Confusion in LxpSvc

• CVE-2025-27475: Double Free Bug in InstallService

• CVE-2024-49095: Use-After-Free in PrintWorkflowUserSvc

• CVE-2025-21234: Improper Input Validation in PrintWorkflowUserSvc

4.1.1 Case 87975: Type Confusion in LxpSvc

Let's move on to the first vulnerability. This vulnerability is a type confusion issue that occurs in the Windows LxpSvc (Language Experience Service). The vulnerability is triggered in the SetLanguageOperationState method of an internal class called DeviceLanguageManager.

The SetLanguageOperationState method takes four parameters, and the fourth parameter is a pointer to a VARIANT structure provided by the user. At steps [1] and [2], the method stores the vt field (the type information of the VARIANT) and the associated data field into v12 and v12 + 0x8, respectively. Later, this data is passed as the third argument to the SetLanguageOperationStateInRegistry method, where it is used without proper validation.

In the SetLanguageOperationStateInRegistry method, if a2 is zero at step [1], the method stores the user-provided VARIANT data field into the data variable at step [2].

Then, the address of data is passed as the fifth argument to the SetRegValue function

So, what is the RegSetKeyValueW function? The RegSetKeyValueW function is used to create or modify a value under a specified registry key.

In other words, at this point, the Status registry key is updated by writing 4 bytes of data from the VARIANT's data field that we provided.

But doesn’t something seem strange here? If you think back to the code we’ve seen so far, you’ll notice that when a2 is zero in the SetLanguageOperationStateInRegistry method, there is no validation of the VARIANT's data type at all!

Now, what would happen if the VARIANT's type was something like BSTR, which holds a pointer instead of a simple integer? This is exactly where Type Confusion occurs. Instead of writing an integer value like 0 or 1, the lower 4 bytes of the pointer address are written into the registry key.

Since this registry path is readable from a user-level context, it allows an attacker to leak the lower 4 bytes of a pointer address.

Personally, I think this was a really interesting vulnerability. Although MSRC determined that the report did not meet their bar for immediate security servicing, they committed to addressing the issue in a future version

4.1.2 CVE-2025-27475: Double Free Bug in InstallService

The next vulnerability is a Double Free Bug found in the Windows Update Stack. The vulnerability occurs in the put_CrossGenSetId method of an internal class called FulfillmentDataInfo.

To trigger the vulnerable function, we first need to call the CreateFulfillmentData method of the InstallControl class, which will return an IFulfillmentDataInfo object. The condition for obtaining this object is very simple: At step [1], it checks whether the length of the string we provide as a2 is exactly 12. If the condition is met, the object is created at step [2] and returned to the client.

// Hidden C++ exception states: #wind=63
__int64 __fastcall WindowsUpdate::Internal::InstallControl::CreateFulfillmentData(
        WindowsUpdate::Internal::InstallControl *this,
        HSTRING a2,
        struct WindowsUpdate::Internal::IFulfillmentDataInfo **a3)
{
  HSTRING v5; // [rsp+38h] [rbp+10h] BYREF

  v5 = a2;
  if ( Utils::IsValidProductId(a2, a2) ) // [1] Verify that a2 is 0xC bytes 
    return Microsoft::WRL::Details::MakeAndInitialize<WindowsUpdate::Internal::FulfillmentDataInfo,WindowsUpdate::Internal::IFulfillmentDataInfo,HSTRING__ *>(
             a3,
             &v5); // [2] Return IFulfillmentDataInfo object
  *a3 = 0LL;
  return 2147942487LL;
}

Now, let's take a look at the put_CrossGenSetId method of the FulfillmentDataInfo object. At step [1], the method loads the HSTRING variable stored at this + 200 into v3. Then, at step [2], it frees the memory pointed to by v3. Wait.. doesn’t this look like a pattern we've seen before?

__int64 __fastcall WindowsUpdate::Internal::FulfillmentDataInfo::put_CrossGenSetId(
        WindowsUpdate::Internal::FulfillmentDataInfo *this,
        HSTRING a2)
{
  unsigned int v2; // ebx
  HSTRING *v3; // rdi

  v2 = 0;
  v3 = (HSTRING *)((char *)this + 200); // [1] Get HSTRING from this + 200
  if ( !a2 || a2 != *v3 )
  {
    WindowsDeleteString(*v3); // [2] Free HSTRING
    *v3 = 0LL;
    return (unsigned int)WindowsDuplicateString(a2, v3);
  }
  return v2;
}

This issue is very similar to CVE-2020-1146, which was previously introduced in COMRace paper. Even after five years, vulnerabilities following the same pattern still remain. This was the moment when our initial suspicions, based on prior work, turned into certainty — there are still many types of race condition vulnerabilities left to be discovered.

Windows::System::Internal::SignInContext::put_AuthData(*this, HSTRING a2) {
    Microsoft::WRL::Wrappers::HString::Set(this + 15, &a2);
}

__int64 HString::Set(HSTRING *newString, HSTRING *a2) {
    unsigned int v2;
    v2 = 0;
    if(!*a2 || *a2 != *newString) {
        WindowsDeleteString(*newString); // Delete
        *newString = 0;
        v2 = WindowsDuplicateString(*a2, newString);
    }
}

4.1.3 CVE-2024-49095: Use-After-Free in PrintWorkflowUserSvc

To continue hunting for race condition vulnerabilities, we turned our attention to PrintWorkflowUserSvc, the service responsible for managing the Windows Print Workflow. In this service, we were able to discover several vulnerabilities. Among them, we will introduce two of the most interesting cases.

The first vulnerability is a Use-After-Free issue. It occurs in the SetPrintTicket method of the CWorkflowSession object.

Looking at the code, we can see that *((_QWORD *)this + 10) holds a heap address that was allocated during a previous call to SetPrintTicket. However, because the CWorkflowSession COM interface belongs to the MTA (Multi-Threaded Apartment) model, the object can be accessed concurrently by different threads.

We attempted to exploit this vulnerability, but due to several constraints, we were not able to achieve a successful exploitation.

However, based on our analysis, we believe that with certain techniques and ideas, exploitation could be conceptually possible.

First, let's talk about bypass ASLR. In the case of ASLR, if the attacker-controlled process and the higher-privileged process load the same DLL, the DLL will be mapped at the same virtual address in both processes. This allows the attacker to infer a sufficient amount of address information.

This idea forms the fundamental basis for many LPE and sandbox escape techniques using IPC mechanisms.

Second, we needed a leak some heap addresss. Since the CWorkflowSession object exposes several other methods, I checked whether any of them could access the this + 10 address.

Eventually, I found a function that does exactly that. By using the GetPrintTicket method, we can copy the value located at this + 10 — which may already have been freed — into a output buffer. In other words, we can leak useful heap addresses through the following scenario.

First, we need a of three threads. Each thread will call different COM interface methods, as illustrated in the diagram. In Thread 2, if a value already exists at this + 10, calling SetPrintTicket will free the heap memory that was previously allocated there. Then, before a new allocation occurs, Thread 3 may allocate an object — such as one containing a vtable or any heap address — into the freed space.

After that, when Thread 1 calls GetPrintTicket, it will reference the this + 10 address, effectively leaking the value from the victim object back to the attacker. Since the size field for heap allocation can be fully controlled through SetPrintTicket, we can reliably place a victim object into the freed hole within the race window, without any size constraints.

Next, we move on to RIP control. Again, three threads are used. Unlike the previous leak scenario, here two of the threads start a race by both calling SetPrintTicket.

First, if this + 10 is not NULL, SetPrintTicket will free the heap memory stored there. During this window, an attacker can allocate an arbitrary object to occupy the freed hole. After that, the attacker can overwrite the victim object with fully controlled data and size. If the victim object contains a vtable, this can lead to successful control flow hijacking.

Even though we came up with these ideas, we were not able to develop a fully working exploit. We encountered several challenges:

First, even if we successfully allocated a victim object into the freed space through the race condition and managed to overwrite it, it was extremely difficult to avoid a double free situation.

Second, because both threads must call the same interface to trigger the race, and the race window is extremely narrow, precise control over the timing was very difficult to achieve.

4.1.4 CVE-2025-21234: Improper Input Validation in PrintWorkflowUserSvc

Now, we would like to introduce the final vulnerability. Just like the previous cases, this vulnerability was also found in PrintWorkflowUserSvc.

Let's take a closer look at the RequestSpoolingHandlesForWrite method of the IPrintSupportSourceSession class. This method takes six parameters, from a2 to a7, and all of them are used as output parameters. Now, let me ask you:When you're hunting for bugs, do you usually bother analyzing functions that have no input parameters at all? Our answer was no — at least, until we discovered this vulnerability.

In this function, at step [1], the address of the WorkflowSessionCommon's vftable, which is stored in this, is loaded into v9. Then, using this address as an argument, the RequestSpoolingHandlesForWrite method of the WorkflowSessionCommon class is called at step [2].

In this method, at step [1], it retrieves the client's PID (Process ID). At step [2], it obtains a handle to the client's process. Then, at step [3], it references this again through v22 and stores some value. Finally, at step [4], it calls the DuplicateHandle function. Now it's time to see what Duplicatehandle function really works.

The DuplicateHandle function is a Windows API that duplicates a handle to an object. To briefly summarize the function arguments: the first and second parameters are the handle to the source process and the handle to be duplicated, respectively. The third parameter is the handle to the target process that will receive the duplicated handle, and the fourth parameter is where the newly duplicated handle will be returned. According to the MSDN documentation, this operation effectively means that the handle from v22 inside PrintWorkflowUserSvc is duplicated into the client process. While this pattern can sometimes be seen in COM, it is usually used to return event handles to the client process for implementing callbacks or method notifications.

It was confirmed by simple reverse engineering that the v22 value was actually set where. Through analysis, we found that it is initialized in the constructor of the PrintSupportSession class. The v22 value is set to -1. In Windows, a handle value of -1 represents a pseudo-handle that points to the current process itself.

This means that in the DuplicateHandle call, the handle of the PrintWorkflowUserSvc process is duplicated into the client process. In other words, if a lower-privileged client calls this method, it can successfully duplicate the PrintWorkflowUserSvc process handle into its own process.

Next, we checked which processes could access PrintWorkflowUserSvc by reviewing its access permissions. As a result, we found that this COM object is accessible not only by all UWP apps, but also by low-privileged AppContainer processes that have specific capabilities. This means that even a sandboxed process can duplicate the PrintWorkflowUserSvc process handle into its own process.

This vulnerability is truly a perfect logic bug. There is no need to exploit the complex Use-After-Free vulnerabilities we discussed earlier to achieve privilege escalation. Now, by using the duplicated process handle, we can write shellcode into the memory space of PrintWorkflowUserSvc and execute it by calling the CreateRemoteThread API.

Now it’s time for the demo. To demonstrate the vulnerability, we assumed a compromised renderer in the Adobe Acrobat sandbox and performed a sandbox escape by injecting shellcode, achieving a privilege escalation from AppContainer to Medium integrity level.

Surprisingly, the bug was declared "Exploit Less Likelly." We still don't know why the MSRC made this decision :D