Hi, I’m Ricardo Narvaja, working as Principal Exploit Writer at Fortra , researching and
developing exploits for Core Impact. I have been working on this new vulnerability, CVE-2026-81963, published on September Patch Tuesday, for which there is currently no technical information available (at least as of the time of writing this blog post); I would like to share the work I have done involving reverse engineering, patch diffing, and the creation of a proof-of-concept (PoC) for this vulnerability.
It is a local privilege escalation vulnerability in the Windows Component Based Servicing (CBS) OnePackage applicability path. It was added to CISA KEV catalog on Sept 8th 2026
A local, non-administrative user can reach a TrustedInstaller-backed TiWorker.exe session through the public CBS Session COM endpoint. During applicability evaluation, CBS extracts a signed UpdateAgent.dll into a caller-controlled sandbox. That signed component then loads dpx.dll from the same caller-controlled directory without applying equivalent signature verification.
On an affected system, this trust gap can cause a controlled dpx.dll to execute inside TiWorker.exe with SYSTEM privileges. The standalone laboratory PoC demonstrated the condition by evaluating a genuine Microsoft MSU and replacing the extracted dpx.dll in the controlled sandbox during a debugger-assisted test. No package installation, staging, or commit operation is required.
Microsoft’s fix adds an administrator check before the vulnerable external applicability path can be reached. The same medium-integrity test that succeeds on the vulnerable target returns E_ACCESSDENIED after the update.
Background
Windows CBS is responsible for servicing operating system components. Much of this work is performed by TrustedInstaller.exe and TiWorker.exe, which run with privileges that aren’t available to a medium-integrity interactive user.
The interesting attack surface was not a package installation operation. It was the earlier applicability evaluation path: the code that determines whether a Windows update package applies to the current system. This distinction matters because the test never invoked InitiateChanges, staged a package, installed it, or committed servicing state.
The investigation used Windows 11 23H2 x64. The vulnerable control target ran build 22631.7079 with servicing stack 10.0.22621.6937. The Core Impact exploit version was tested successfully on newer Windows 11, and also on Windows Server 2025.
Figure 1. Servicing-stack inventory on the prepatch system
Tested scope and prerequisites
The standalone PoC described here was validated in an isolated x64 virtual machine from a medium-integrity, non-administrative account. The positively tested configuration was Windows 11 23H2 build 22631.7079 with servicing stack and UpdateAgent.dll version 10.0.22621.6937. The patched comparison system was Windows 11 23H2 build 22631.7584 with KB5129242 and CbsCore version 10.0.22621.7578.
The PoC depends on undocumented COM interfaces and version-specific CBS behavior. Its source MSU must contain Microsoft-supplied OnePackage metadata, catalog data, and deployment components compatible with the target servicing family. An MSU selected for one servicing baseline should not be assumed to work on another.
Run the test only in a disposable lab . The suppliedDLL is deliberately non-destructive, but the execution path runs inside the privileged Windows servicing process.
Finding the reachable CBS path
Direct activation of the internal CBS worker was not useful, but the public CBS Session COM endpoint was available to a medium-integrity user. The relevant sequence was:
CoCreateInstance(CLSID_CbsSession, IID_ICbsSession10)
-> ICbsSession::Initialize
-> ICbsSession::GetSessionId
-> ICbsSession10::CreateWindowsUpdatePackage
-> QueryInterface(IID_ICbsPackage)
-> ICbsPackage::EvaluateApplicability
GetSessionId caused TrustedInstaller to create a TiWorker-backed CBS session. Supplying a genuine OnePackage root container then reached CCbsPackage::ExternalEvaluateApplicability in the privileged worker.
The root package used by the standalone PoC was the original approximately 1.1 GB Microsoft MSU, including its WIM and PSF payloads. Keeping the genuine package intact ensured that CBS processed the same version-compatible metadata and signed deployment components used during normal servicing.
For the Core Impact exploit, I have reduced the carrier from roughly 1.1 GB to approximately 1 MB while preserving the complete path from public COM activation to the sibling DPX load.
Understanding the patch
Binary comparison showed changes around the OnePackage applicability path, including token handling, scoped impersonation, and security-reset logic.
Figure 2. Patch diff around the applicability path
The diff also exposed a WIL _private_IsEnabled feature gate. This was a useful marker that led us to a separate mitigation involving scoped impersonation around the DPX cabinet-extraction path.
Figure 3. WIL feature gate associated with the impersonation-related mitigation
_private_IsEnabled refers to one of the two included fixes, which performs impersonation within the scope where the .CAB file is extracted; however, since our dpx.dll library is loaded subsequently, this does not prevent that load. What actually prevents the load is the second fix, as it blocks execution unless the user has administrator privileges.
The second fix—which checks for administrator privileges and is described later—rejects any caller with a medium integrity level early on, before execution reaches this branch. Consequently, it was not possible to activate it dynamically via the public CBS COM connection point. Static analysis indicates that the impersonation scope ends before the ExtractUpdateAgentFromCab` and `OnepackageCheckApplicabilityFromSandbox` functions.
One patched path obtains the caller token and introduces an impersonation scope before extracting the package contents:
Figure 4. Patched token and impersonation flow
The extraction occurs while that scoped impersonation is active.
Figure 5. Impersonation immediately before cabinet extraction
The patched function subsequently reverts the impersonation and resets security information.
Figure 6. Revert and security reset flow
At first, this raised an important question: does the later dpx.dll load occur while TiWorker is impersonating the caller, or after it has returned to its process token? Static analysis established that the impersonation scope ends before ExtractUpdateAgentFromCab and the nested UpdateAgent loads. However, that is not the primary protection applied by the final patch.
The decisive change is earlier in CCbsPublicPackage::EvaluateApplicability: the patched implementation calls EnsureCallerIsAdministrator before it can invoke the external applicability path.
Figure 7. Patched administrator check before applicability evaluation
This new gate prevents a non-administrative caller from reaching the vulnerable operations at all.
Following the vulnerable OnePackage flow
On the prepatch target, a medium-integrity client reached the OnePackage branch in CCbsPackage::ExternalEvaluateApplicability. The code accepted both the package source and an explicit sandbox, then called the DPX extraction routine.
Figure 8. Prepatch OnePackage DPX extraction path
The original .msu was an MSWIM container rather than a conventional cabinet. CBS recognized it and redirected extraction through the ESD/WIM path. Once applied to the sandbox, the container exposed DesktopDeployment.cab and the OnePackage metadata used by the next stage.
ExtractUpdateAgentFromCab then extracted the deployment components into a metadata directory below the selected sandbox.
Figure 9. Extraction of UpdateAgent from DesktopDeployment.cab
The resulting directory contained, among other files:
- UpdateAgent.dll
- UAOneSettings.dll
- dpx.dll
The signed UpdateAgent and the unsigned DLL in the same directory
CBS explicitly validates UpdateAgent.dll with CbsVerifyFileSignature.
Figure 10. UpdateAgent signature verification
After the signature check succeeds, CbsCore loads that Microsoft-signed DLL from the sandbox metadata directory.
Figure 11. UpdateAgent loaded from the controlled metadata directory
The trust boundary changes inside UpdateAgent. Its DPX initialization routine first constructs the full path of a file named dpx.dll in the same directory and calls:
LoadLibraryExW(fullDpxPath, NULL, LOAD_WITH_ALTERED_SEARCH_PATH)
If that load fails, it tries a servicing fallback and finally a name-only Dpx.dll load. Once loaded, the module resolves the DpxNewJob export.
Figure 12. UpdateAgent same-directory DPX resolution and servicing fallback
No equivalent Authenticode or CBS signature verification occurs between construction of that path and LoadLibraryExW. At runtime, the argument pointed directly into the controlled metadata directory.
Figure 13. Controlled dpx.dll path passed to LoadLibraryExW
The register state was captured immediately before the call. Under the Windows x64 calling convention, the first three LoadLibraryExW arguments are passed in RCX, RDX, and R8: RCX points to the fully qualified controlled dpx.dll path, RDX is 0 (hFile = NULL), and R8 is 8 (dwFlags = LOAD_WITH_ALTERED_SEARCH_PATH). This confirms that the observed load used the attacker-controlled absolute path while applying the altered dependency-search behavior associated with that flag.
Figure 14. LoadLibraryExW argument registers immediately before the call
The loader returned a valid module handle for that DLL.
Figure 15. dpx.dll loaded successfully from the controlled sandbox
Process inspection confirmed that TiWorker had mapped UpdateAgent and its associated metadata components from the selected sandbox rather than from the normal servicing-stack location.
Figure 16. TiWorker modules loaded from the controlled metadata directory
Preparing the standalone PoC inputs
The standalone PoC requires version-compatible OnePackage metadata and Microsoft-signed deployment components. For the documented Windows 11 23H2 test, the input was the genuine Microsoft Update Standalone package windows11.0-kb5122880-x64.msu.
Figure 17. Microsoft Update Standalone package used as the source of the OnePackage metadata
The MSU does not need to be installed to run the PoC. During analysis, the relevant top-level contents were:
- Update.mum
- Update.cat
- Onepackage.AggregatedMetadata.cab
- DesktopDeployment.cab
These metadata and catalog files must originate from a genuine MSU that matches the target’s servicing family. DesktopDeployment.cab contains the Microsoft-signed, version-compatible deployment components needed by that build. The files relevant to the observed load path were:
- UpdateAgent.dll
- UAOneSettings.dll
- dpx.dll
The Microsoft-supplied metadata, catalog, and signed binaries must remain mutually version-compatible. They are not included with the PoC; the genuine MSU supplies them during the test. DpxMarker.cpp builds the only controlled test component, an unsigned dpx.dll used solely to prove that native initialization code executes in the privileged process.
The source is an .msu (Microsoft Update Standalone package), not an .msi. Do not mix files taken from unrelated cumulative updates: a valid Microsoft signature does not, by itself, establish that the component matches the target’s CBS/servicing baseline.
In the standalone debugger-assisted validation, CBS first extracted the genuine deployment content into the fixed sandbox. The extracted Microsoft dpx.dll was then replaced with the non-destructive marker after extraction and before the observed LoadLibraryExW call. Minimizing and rebuilding this material as a self-contained compact carrier was later engineering work and is outside the scope of the standalone PoC published here.
Standalone proof of concept
The publication bundle contains the exact standalone sources used during the debugger-assisted validation:
- CVE_2026_81963_CbsWorker_ComReachability test poc.cpp implements the public CBS Session COM client and invokes only applicability evaluation.
- DpxMarker.cpp builds a non-destructive DLL that reports its load through OutputDebugStringW and returns E_NOTIMPL from DpxNewJob.[DL1]
The marker does not create a process, display UI, write a file, stage or install an update, or modify committed servicing state. Its debugger message is the success condition for this PoC.
The tested PoC uses C:\CVE-2026-81963 as its fixed CBS sandbox; that directory must exist and contain the prepared test inputs described above. The program pauses immediately before ICbsPackage::EvaluateApplicability, allowing a debugger to be attached to TiWorker.exe. The displayed CbsCore.dll+0xFB88 breakpoint is specific to the prepatch binary analyzed during this investigation and must not be treated as a portable offset.
The PoC was launched against the original approximately 1.1 GB Microsoft MSU with this command:
"C:\CVE-2026-81963\CVE_2026_81963_CbsWorker_ComReachability.exe" "C:\CVE-2026-81963\windows11.0-kb5122880-x64.msu" --evaluate
When the program pauses, attach the debugger to the newly created TiWorker.exe and configure the relevant breakpoints for the tested binary. Continue the evaluation until CBS has extracted the deployment files into C:\CVE-2026-81963\metadata, but before UpdateAgent calls LoadLibraryExW for dpx.dll. Replace the extracted dpx.dll with the compiled non-destructive marker, then resume execution. This controlled debugger procedure is the standalone proof described in this article.
The console-side success leading into the debugger-assisted test was the following sequence:
CoCreateInstance(CLSID_CbsSession, IID_ICbsSession10): S_OK
ICbsSession::Initialize: S_OK
ICbsSession::GetSessionId: S_OK
ICbsSession10::CreateWindowsUpdatePackage: S_OK
QueryInterface(IID_ICbsPackage): S_OK
These results establish that the medium-integrity client reached the package object; they do not establish code execution on their own. For the --evaluate run, the authoritative success signal was the marker message emitted when the controlled DLL was mapped into TiWorker.exe.
The standalone validation flow is:
Medium-integrity local user
-> public CBS Session COM endpoint
-> TrustedInstaller-backed TiWorker session
-> CreateWindowsUpdatePackage(original Microsoft MSU)
-> EvaluateApplicability
-> extract DesktopDeployment.cab
-> verify and load signed UpdateAgent.dll
-> replace the extracted dpx.dll with DpxMarker.dll during the controlled debugger pause
-> load dpx.dll from the same controlled directory without an equivalent trust check
-> execute DpxMarker.dll in the privileged servicing process
-> emit the controlled debugger marker
The debugger captured the controlled DLL mapped from C:\CVE-2026-81963\metadata\dpx.dll. The returned module handle, loaded-module list, and OutputDebugStringW message provide independent confirmation that the load occurred.
Figure 18. Dynamic confirmation of dpx.dll loaded by NT AUTHORITY/SYSTEM Tiworker process
Patch validation
The patched target ran Windows 11 23H2 build 22631.7584 with KB5129242 installed and CbsCore version 10.0.22621.7578.
The same medium-integrity client and full-MSU applicability flow produced:
ICbsSession10::CreateWindowsUpdatePackage: S_OK
ICbsPackage::EvaluateApplicability: 0x80070005 (E_ACCESSDENIED)
CbsCore logged:
Failed administrator access check.
Failed to ensure caller is an administrator for applicability evaluation.
Dynamic analysis confirmed that execution returned from the new administrator check and never reached CCbsPackage::ExternalEvaluateApplicability. No controlled dpx.dll was loaded. The tested PoC path is therefore blocked by the update; no patch bypass was demonstrated.
Security impact
An authenticated local attacker able to execute code as a standard user can elevate privileges to SYSTEM on an affected machine. Successful exploitation provides arbitrary native code execution in the Windows servicing process without installing an update or modifying committed servicing state.
The root cause is a broken trust transition: CBS verifies and loads a signed deployment component from package-controlled content, but that component subsequently loads another DLL from the same controlled directory without enforcing an equivalent trust decision.
Detection and remediation
Systems should install the Microsoft update that introduces the administrator check before external applicability evaluation.
Defenders investigating possible exploitation can look for unusual combinations of:
- non-administrative processes activating the CBS Session COM endpoint;
- unexpected OnePackage applicability evaluations initiated from user-writable locations;
- TiWorker.exe loading UpdateAgent.dll or dpx.dll from a user’s temporary directory rather than the Windows servicing store;
- short-lived update metadata trees containing update.mum, update.cat, onepackage.AggregatedMetadata.cab, and DesktopDeployment.cab; and
- unexpected native-code, child-process, or outbound-network activity originating from TiWorker.exe shortly after such evaluation.
The robust remediation is to prevent non-administrative callers from entering this privileged applicability workflow and to ensure that every native dependency loaded into TiWorker is bound to an appropriate trust verification.
Conclusion
This blog post shows how to analyze the patch and offers a basic proof-of-concept (PoC) demonstrating how to exploit the vulnerability using an auxiliary MSU file larger than one gigabyte, as well as how the TiWorker process—running with NT AUTHORITY\SYSTEM privileges—ends up loading dpx.dll from a controlled OnePackage directory.
It also notes that the large original MSU file, as distributed, makes exploitation difficult; however, simply creating a minimal MSU containing only a few specific files and making minor adjustments to the PoC is enough to exploit the same vulnerability and load the DLL with NT AUTHORITY\SYSTEM privileges.
In the exploit released by Fortra for Core Impact, the auxiliary files take around 2 megabytes but support more builds than the PoC in this blog post, which serves solely as a basic reference to demonstrate the vulnerability.
References
