Escalating All The Privileges With Foxit PDF Reader (CVE-2026-57239)

Executive Summary

CVE-2026-57239 is a local privilege escalation vulnerability discovered in Foxit PDF Reader that allows an unprivileged user to escalate privileges to NT AUTHORITY\SYSTEM through a combination of DLL sideloading and cryptographic exploitation. The vulnerability exists in the FoxitPDFReaderUpdateService.exe process, which runs with SYSTEM privileges and monitors a user-writable directory for configuration files. By crafting a specially formatted encrypted configuration file and positioning a malicious proxy DLL in a predictable location, an attacker can achieve arbitrary code execution with SYSTEM privileges. The vulnerability requires prior code execution on the machine but chains trivially into a full system compromise.

This technical analysis documents the vulnerability discovery process, including the reverse engineering of the Foxit update mechanism, the identification and exploitation of the DLL sideloading vector, and the cryptographic analysis required to craft valid IPC messages. The article also covers detection strategies, mitigation techniques, and a complete responsible disclosure timeline spanning from March 25 through July 15, 2026.

The Hunt Begins

Initial reconnaissance using Procmon and API Explorer revealed suspicious behavior in the Foxit PDF Reader installation directory. The updater program, FoxitPDFReaderUpdateService.exe, located in the user’s %APPDATA% folder, performs operations as NT AUTHORITY\SYSTEM. This immediately raised red flags, as the service required write access to %PROGRAMFILES%, a protected system directory.

Close monitoring with Procmon showed the updater performing numerous DLL lookups in the AppData folder, returning PATH NOT FOUND errors for most queries. This pattern strongly suggested DLL search order exploitation opportunities. The first successful sideload used CRYPTBASE.DLL, a proxy DLL that intercepted the loader and enabled code execution within the updater’s SYSTEM context.

However, anti-sideload checks quickly mitigated this initial vector. Further analysis revealed a critical gap in the implementation: while most DLLs were protected, WINSPOOL.DRV (the print spooler driver) was loaded earlier in the execution chain, before the anti-sideload protections engaged. Since driver DLLs are loaded with LoadLibraryEx using the LOAD_LIBRARY_AS_DATAFILE flag, a proxy WINSPOOL.DRV would not execute DllMain. Nevertheless, this became the vector for the second exploitation attempt.

Escalation Path: From DLL Sideloading to Privilege Escalation

After the initial sideload was patched, the focus shifted to finding an alternative attack surface. The breakthrough came when monitoring file operations revealed that FoxitPDFReaderUpdateService.exe (running as SYSTEM) continuously checked for and executed a binary from the user-writable location:

C:\ProgramData\Foxit Software\Foxit PDF Reader\FoxitData.txt

The directory had write permissions for the Users group, meaning an unprivileged user could place files there. The service would read this configuration file and execute a process from a location in %APPDATA% with SYSTEM privileges. Initial attempts to simply replace the binary with cmd.exe failed due to filename and certificate validation checks hardcoded into the service.

Reverse Engineering the Encryption Scheme

Detailed reverse engineering of FoxitPDFReaderUpdateService.exe revealed the service performs the following steps:

1. Enumerates processes looking for winlogon.exe in the current session
2. Opens the winlogon.exe process and duplicates its token
3. Creates an environment block inheriting from the current user’s process with inheritance set to TRUE
4. Creates a new process with the duplicated token (impersonating the user’s security context but running under SYSTEM privileges)

Filename and certificate checks validate that only legitimate Foxit binaries are executed. Additionally, AES-128 CBC encryption protects the inter-process communication (IPC) messages. The hardcoded encryption key was discovered in the binary:

(&encryption_key, "c6c7702dbcbf4678", 0x10u);

The critical mistake in the implementation was the use of UTF-16 LE encoding. Initial decryption attempts failed because the plaintext and ciphertext were not properly aligned. Once UTF-16 LE encoding was applied, the decryption succeeded, revealing the binary path and execution parameters.

A Python script was developed to automate the encryption/decryption process, allowing attackers to craft valid IPC messages that instruct the service to execute arbitrary binaries:

from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2
import os

# Hardcoded encryption key from binary analysis
key = bytes.fromhex('c6c7702dbcbf4678')

def encrypt_foxit_message(plaintext):
    # UTF-16 LE encoding (critical for proper cipher alignment)
    message = plaintext.encode('utf-16-le')
    
    # Generate random IV
    iv = os.urandom(16)
    
    # AES-128 CBC encryption
    cipher = Cipher(
        algorithms.AES(key),
        modes.CBC(iv),
        backend=default_backend()
    )
    encryptor = cipher.encryptor()
    
    # Pad message to 16-byte blocks (PKCS7)
    block_size = 16
    padding_len = block_size - (len(message) % block_size)
    padded = message + bytes([padding_len] * padding_len)
    
    ciphertext = encryptor.update(padded) + encryptor.finalize()
    
    return iv + ciphertext

def decrypt_foxit_message(ciphertext):
    iv = ciphertext[:16]
    encrypted = ciphertext[16:]
    
    cipher = Cipher(
        algorithms.AES(key),
        modes.CBC(iv),
        backend=default_backend()
    )
    decryptor = cipher.decryptor()
    
    plaintext = decryptor.update(encrypted) + decryptor.finalize()
    
    # Remove PKCS7 padding
    padding_len = plaintext[-1]
    plaintext = plaintext[:-padding_len]
    
    return plaintext.decode('utf-16-le')

The DLL Sideloading Vector Revisited

With the encryption mechanism understood, the exploit was nearly complete. However, a critical issue remained: the service validated that executable files were signed by Foxit and verified their certificates. This prevented direct execution of attacker-controlled binaries. The solution leveraged the DLL sideloading vector that had been patched earlier.

By crafting an encrypted IPC message that instructed the service to execute FoxitPDFReaderUpdater.exe from a user-writable location (with a malicious WINSPOOL.DRV proxy DLL positioned nearby), the service would load the malicious DLL during the updater’s initialization. The combination of the encryption bypass and DLL sideloading created a complete exploit chain.

A Rust-based automated proof-of-concept was developed to fully automate this exploitation chain, handling encryption, DLL proxy generation, process placement, and trigger automation.

Disclosure Timeline

1. March 25, 2026 — Begin research
2. March 26, 2026 — Sideload technique discovered using WINSPOOL.DRV; unsure how to trigger in elevated context
3. March 27, 2026 — Research paused for other priorities
4. April 1, 2026 — Foxit PDF Reader 2026.1 released with anti-sideload measures for WINSPOOL.DRV (CVE-2026–3775/CVE-2026–3776)
5. April 2–13, 2026 — Paused for work priorities
6. April 14, 2026 — Successfully reverse engineered the cryptography for IPC messages; discovered patched vulnerability before exploitation completed
7. April 15, 2026 — Alternate sideload technique discovered
8. April 16, 2026 — Disclosure report written
9. April 17, 2026 — Findings reported to Foxit; exploitation post begun
10. April 20, 2026 — Foxit confirms receipt and states they are investigating
11. May 14, 2026 — Status update request sent to Foxit
12. May 14, 2026 — Foxit confirms they have reproduced the vulnerability
13. June 16, 2026 — Foxit indicates patch scheduled for next month
14. July 1, 2026 — Foxit notifies of July 8 release date for patch
15. July 8, 2026 — Patch released publicly on Foxit security bulletins page
16. July 15, 2026 — This blog post and proof-of-concept code released on GitHub

Detection Strategies

Defenders can implement the following detection methods to identify exploitation attempts:

• Monitor for processes other than those signed by Foxit Software Inc. (signed by DigiCert) writing data to C:\ProgramData\Foxit Software\Foxit PDF Reader\FoxitData.txt
• Hunt for .dll and .drv files placed in %APPDATA%\Foxit Software\Continuous\Addon\Foxit PDF Reader\ by non-Foxit processes
• Monitor for unexpected child processes spawned from FoxitPDFReaderUpdateService.exe or FoxitPDFReaderUpdater.exe running as NT AUTHORITY\SYSTEM
• Correlate DLL load events with suspicious file write operations to Foxit-related ProgramData directories

The following YARA rule can detect potentially malicious payloads:

import "pe"

rule MRLN_SRT_Foxit_Pdf_Reader_LPE_Dropper {
    meta:
        description = "MRLN SRT - Possible Foxit PDF Reader LPE Dropper"
        author = "Mandiant / Luke Paris"
        date = "2026-07-15"
        hash = "pending disclosure coordination"
    strings:
        $winspool = "WINSPOOL.DRV" nocase
        $foxit = "Foxit" nocase
        $appdata = "%APPDATA%" nocase
        $system_check = { 4E 54 20 41 55 54 48 4F 52 49 54 59 5C 53 59 53 54 45 4D } // "NT AUTHORITY\SYSTEM"
    condition:
        ($winspool or $foxit) and uint16(0) == 0x5a4d and any of them
}

Mitigation and Patching

Foxit released patch version 2026.2 that addresses CVE-2026-57239. Key remediations include:

• Eliminating the DLL sideloading vector by hardening the DLL search order
• Restricting write permissions to the ProgramData\Foxit Software directory
• Implementing additional integrity checks on configuration files
• Removing or rewriting the IPC mechanism to use Windows RPC instead of custom encryption

Users should immediately update to Foxit PDF Reader version 2026.2 or later. Organizations should prioritize patching all Foxit installations, particularly on systems where unprivileged users have local access.

Key Takeaways

• DLL sideloading remains a powerful primitive for privilege escalation when combined with SYSTEM-level processes that lack robust validation
• Custom cryptographic implementations are high-risk; mistakes (like UTF-16 LE encoding confusion) can completely undermine security assumptions
• Security-critical file operations should use file permissions and integrity checks, not just filename validation and signatures
• Windows services that monitor user-writable directories for configuration files create inherent risk; these should be redesigned to use system directories or authenticated IPC channels
• The responsible disclosure process, while lengthy, is essential for coordinating patches before public exploitation
• A minor two-week delay in exploitation attempts resulted in an unintended race condition with the vendor’s patch timeline

Defensive Recommendations

• Principle of Least Privilege: Run GUI applications and third-party software with minimal required privileges; avoid running Foxit PDF Reader or other document readers as administrator or SYSTEM unless absolutely necessary
• File Integrity Monitoring: Deploy file integrity monitoring on critical directories, particularly ProgramData and Program Files, to detect unauthorized file creation
• Application Whitelisting: Implement application whitelisting policies that restrict DLL loading from user-writable locations
• Process Monitoring: Monitor for suspicious process creation from updater/service processes, especially those with unexpected privileges or parent-child relationships
• Update Management: Maintain a rigorous patching schedule for third-party applications, particularly those with elevated privileges or file system access
• Security Audits: Conduct regular security audits of third-party software configurations, focusing on privilege escalation paths and file access patterns
• EDR Deployment: Deploy Endpoint Detection and Response (EDR) solutions capable of detecting DLL injection, token duplication, and SYSTEM-level process execution anomalies

Conclusion

CVE-2026-57239 exemplifies how seemingly minor design decisions in privileged processes can cascade into critical vulnerabilities. The combination of user-writable configuration directories, inadequate file validation, and weak custom cryptography created a complete privilege escalation path from an unprivileged user to SYSTEM. The exploit required reverse engineering, cryptographic analysis, and exploitation of legacy DLL search order behavior—demonstrating that even mature, widely-used applications remain vulnerable to creative attack vectors. This case study underscores the importance of secure design principles, rigorous code review for security-sensitive components, and timely patching of identified vulnerabilities.

Original text: “Escalating All The Privileges With Foxit PDF Reader (CVE-2026–57239)” by Luke Paris at Paradoxis.