CVE-2026-50458: Finding a UAF in the Windows Brokering File System Contents CVE-2026-50458: Finding a UAF in the Windows Brokering File System On Tuesday, July 14, Microsoft released the largest Patch Tuesday update in its history, fixing more than 600 vulnerabilities. A bug I reported to Microsoft on May 17 was patched as CVE-2026-50458 in this release, so I am publishing the writeup I wrote at the time, while the details were still fresh. I hope you enjoy it! Introduction After spending some time learning and researching Windows minifilter drivers, I decided to audit one of them. I chose the Windows Brokering File System ( bfs.sys , build 26100.8328) because it caught my attention as a component related to sandboxes, in the broad sense of the word. I also noticed that it had several CVEs from late 2025 and early 2026 and that it was a small component (153 KB), which made it look like a good target. After finding a few minor issues (user mode memory corruption, reference leaks, etc.), I found a UAF triggerable through a race condition. This post presents the RCA for this vulnerability and the methodology I used during the analysis. Windows Brokering File System The Microsoft Brokering File System ( bfs.sys ) is a Windows minifilter driver that acts as a trusted broker. It manages and intercepts file, pipe, and registry operations between restricted user mode applications, such as AppContainer or UWP apps, and the broader operating system. After a fairly tedious investigation (ahem, downloading cvelist locally and asking Codex to find and sort every CVE related to the component), I ended up with the following data: Direct Microsoft Brokering File System CVEs found: 21. By year: Year Count 2024 5 2025 12 2026 4 By bug class / CWE: Class Count CWE-416: Use After Free 12 CWE-362: Race condition / improper synchronization 5 CWE-269: Improper Privilege Management 3 CWE-415: Double Free 3 CWE-822: Untrusted Pointer Dereference 1 CWE-59: Improper Link Resolution Before File Access 1 CWE-476: NULL Pointer Dereference 1 CVE Public date Main class Local JSON CVE-2024-26213 2024-04-09 CWE-822: Untrusted Pointer Dereference cves/2024/26xxx/CVE-2024-26213.json CVE-2024-28904 2024-04-09 CWE-269: Improper Privilege Management cves/2024/28xxx/CVE-2024-28904.json CVE-2024-28905 2024-04-09 CWE-269: Improper Privilege Management cves/2024/28xxx/CVE-2024-28905.json CVE-2024-28907 2024-04-09 CWE-59: Improper Link Resolution Before File Access cves/2024/28xxx/CVE-2024-28907.json CVE-2024-30007 2024-05-14 CWE-269: Improper Privilege Management cves/2024/30xxx/CVE-2024-30007.json CVE-2025-21315 2025-01-14 CWE-416: Use After Free cves/2025/21xxx/CVE-2025-21315.json CVE-2025-21372 2025-01-14 CWE-416: Use After Free cves/2025/21xxx/CVE-2025-21372.json CVE-2025-29970 2025-05-13 CWE-416: Use After Free cves/2025/29xxx/CVE-2025-29970.json CVE-2025-49677 2025-07-08 CWE-416: Use After Free cves/2025/49xxx/CVE-2025-49677.json CVE-2025-49693 2025-07-08 CWE-415: Double Free cves/2025/49xxx/CVE-2025-49693.json CVE-2025-49694 2025-07-08 CWE-476: NULL Pointer Dereference cves/2025/49xxx/CVE-2025-49694.json CVE-2025-53142 2025-08-12 CWE-416: Use After Free cves/2025/53xxx/CVE-2025-53142.json CVE-2025-54105 2025-09-09 CWE-362 + CWE-416 cves/2025/54xxx/CVE-2025-54105.json CVE-2025-48004 2025-10-14 CWE-416: Use After Free cves/2025/48xxx/CVE-2025-48004.json CVE-2025-59189 2025-10-14 CWE-416: Use After Free cves/2025/59xxx/CVE-2025-59189.json CVE-2025-62469 2025-12-09 CWE-362 + CWE-415 cves/2025/62xxx/CVE-2025-62469.json CVE-2025-62569 2025-12-09 CWE-416: Use After Free cves/2025/62xxx/CVE-2025-62569.json CVE-2026-25167 2026-03-10 CWE-416: Use After Free cves/2026/25xxx/CVE-2026-25167.json CVE-2026-26181 2026-04-14 CWE-416 + CWE-362 cves/2026/26xxx/CVE-2026-26181.json CVE-2026-32091 2026-04-14 CWE-362 + CWE-416 cves/2026/32xxx/CVE-2026-32091.json CVE-2026-32219 2026-04-14 CWE-415 + CWE-362 cves/2026/32xxx/CVE-2026-32219.json With this information, I started patch diffing as many of the vulnerabilities as I could, although I was unable to find some older driver versions. I saw the following patterns quite often: Misplaced push locks: calls to ExAcquirePushLockSharedEx(...) around code that modified global variables, or ExAcquirePushLockExclusiveEx(...) calls released too early, again allowing global state to be modified without the lock. Misplaced ExAcquireRundownProtection(...) calls, causing synchronization problems between pre and post callbacks. Functions prefixed with Get* or Query* that actually modify state without any lock. Incorrect use of BfsDereference* , leading to double frees or UAFs. The important result of this initial analysis was that it clarified the most common bug patterns in this component: issues related to race conditions that ended in UAFs, usually because of incorrect locking or dereferencing. If that does not convince you, take another look at the CVE history above. Root Cause Analysis During bfs.sys initialization, inside ...