Privilege Escalation Red Team Pentesting Information Security Security Escalating All The Privileges With Foxit PDF Reader ( CVE-2026–57239 ) Luke Paris 15 min read · 5 days ago -- Listen Share TL;DR: it was possible to obtain NT AUTHORITY\SYSTEM privileges from the perspective of an unprivileged user using Foxit PDF Reader. The vulnerability has reported and has been assigned CVE-2026–57239 and requires some form of code execution on the machine already to exploit. Detection and remediation steps can be found at the end of this blog post. Back towards the end of March in 2026 I took a jab at Foxit’s PDF Reader. The program had been on my research list for quite a while, especially back when I worked at Fox-IT (because, I mean, having Fox-IT credited as finding a vulnerability in Foxit’s software was pretty funny to me). Unfortunately, other work, deadlines and muh’ work-life balance always got in the way for my meme project of choice. When I switched jobs earlier this year I finally got some more research time, so I picked the project back up and got to work! The Hunt Begins I fired up Procmon and API explorer, installed the software and got to work. From the get go I was looking for three things: either a local privilege escalation bug, some form of easy persistence technique using the PDF reader, or some kind of format error that would let met get RCE by simply opening a document. Given that I‘m not great at buffer overflows and other forms of binary exploitation, I set my sights on the privilege escalation or the persistence part since I have a bit more experience there. Almost immediately I flocked towards the updater program stored in the user’s %APPDATA% folder (totally oblivious at this point there’s an FoxitPDFReaderUpdateService.exe process, which ran with NT AUTHORITY\SYSTEM privileges), as updates generally mean elevated privileges (because how would you otherwise write to %PROGRAMFILES% ?) . I tried running the FoxitPDFReaderUpdater.exe a bunch of times and quickly noted that it performed a lot of CreateFile operations in the current working directory for .dll files with a result of PATH NOT FOUND (which if you’ve done any form of malware development or red teaming in the past 5 years you’ll know is always a lovely sight). Press enter or click to view image in full size Updater does a bunch of DLL lookups in the AppData folder So I created a nice proxy DLL¹ of CRYPTBASE.DLL , dropped it alongside the FoxitPDFReaderUpdater.exe , ran the program again hoping to get a nice “Hello world” popup, just to be greeted by: Press enter or click to view image in full size Turns out they were anti-sideload checks Press enter or click to view image in full size Yep, turns out they were anti-sideloading checks. However, one thing stuck out to me: Between the big list of CreateFileW operations, I saw one stray .DRV file being referenced as well. Moreover, when disabling some of my filters I noted that the .DRV file was referenced before all of the other DLL’s, meaning it might be different from the other libraries that get referenced by the program! Press enter or click to view image in full size Program gets loaded and references `winspool.drv` and `oleaccrc.dll` Press enter or click to view image in full size Only later do the other DLL’s get referenced While I know from experience that OLEACCRC.DLL is a resource DLL, which is useless for sideloading as it generally gets loaded with LoadLibraryEx with the LOAD_LIBRARY_AS_DATAFILE flag, meaning no executable code gets loaded. The, WINSPOOL.DRV is a driver file, which is just a PE file that also runs DllMain calls on load, meaning if you can sideload this, you should have successful code execution. So, just like last time, I created a nice proof of concept file, compiled it, dropped it in the right location and restarted the updater program and.. Press enter or click to view image in full size Successfully side-loading the FoxitPDFReaderUpdater.exe process All hail the dubious Microsoft DLL search order design choices Fun extra: d uring my later reverse engineering efforts I found the exact place where the check takes place, and indeed, we don’t see any checks for the winspool.drv file: Press enter or click to view image in full size Code responsible for the DLL sideloads Up Next: Privilege Escalation! After finding a way to side-load the updater process, I was still left with the fact that I didn’t have a way to elevate privileges. It was at this point that I noticed the existence of the FoxitPDFReaderUpdateService.exe process, which ran with NT AUTHORITY\SYSTEM privileges (don’t ask me how I hadn’t spotted it yet at this point). While zooming in on the process a bit more with Procmon, I could see that it continuously checks for the existence of a couple of files: C:\ProgramData\Foxit Software\Foxit PDF Reader\Foxit Service\Log\log.lib C:\ProgramData\Foxit Software\Foxit PDF Reader\FoxitData.txt C:\Program Files\Foxit Software\Foxit PDF Reader\ProfStore\ProfS...