CVE-2026-91798: Foxit PDF local privilege escalation
TL;DR - CVE-2026-91798 is a high-severity local privilege-escalation flaw in the Foxit PDF Editor and Reader update daemon. - Affected version ranges and a fixed release are not yet published in the reviewed records. - No verified public PoC or active exploitation was identified. Restrict updater configuration changes and monitor Foxit advisories.
Vulnerability at a Glance
| Field | Details |
|---|---|
| CVE | CVE-2026-91798 |
| Affected products | Foxit PDF Editor and Foxit PDF Reader |
| Component | Product update daemon |
| CVSS score | 8.8, high severity |
| Attack vector | Local, based on the vulnerability description |
| Authentication or privileges required | An attacker needs local access and an existing ordinary-user foothold; the complete CVSS authentication requirement is not available |
| Patch available | No confirmed fixed release was identified in the reviewed NVD or Foxit material |
| CISA KEV status | Not listed |
| Public PoC | No verified public PoC identified |
| Active exploitation | No verified in-the-wild exploitation identified |
CVE-2026-91798 may allow a standard local user to obtain higher privileges through a trusted application component. It is not described as a remote, unauthenticated vulnerability. An attacker would first need local access, such as a user account, malware foothold, interactive session, or another local execution path.
The available record is incomplete because the CVE was newly published on September 23, 2026. It includes the vulnerability description and a CVSS score, but not the affected version range, fixed version, complete CVSS vector, or CVE-specific vendor advisory. Vulnerability-management records should keep those omissions explicit rather than filling them with assumptions.
Analyst’s Take: Treat this as a post-compromise escalation risk until Foxit publishes the affected and fixed versions. The first practical step is to inventory Foxit installations and review updater configuration-file permissions, while keeping the missing file path, daemon details, and CVSS vector clearly marked as unconfirmed.
What Is This Vulnerability?
The NVD description attributes the issue to an insecure permission configuration in the Foxit PDF Editor and Reader update daemon. A configuration file used by the update component can reportedly be modified by regular users. If the daemon trusts that file and processes attacker-controlled settings, an attacker may be able to cause arbitrary script execution with higher privileges.
The security boundary failure is an authorization and file-permission problem. The updater appears to perform an operation with more authority than the user who can alter its configuration. The available data does not identify the exact file path, daemon executable, script interpreter, operating-system-specific behavior, or privilege level obtained after exploitation. Defenders should avoid treating any particular filename or process name as confirmed until Foxit publishes technical details.
Potential impact includes local privilege escalation, persistence, tampering with update behavior, execution of attacker-controlled code, and further compromise of the host. The vulnerability description does not establish that exploitation is possible remotely, nor does it prove that every installation exposes the same permissions. Those questions require vendor clarification or controlled validation on representative systems.
Technical Notes
A practical validation approach is to identify Foxit installation and updater directories, enumerate configuration files, and review whether ordinary users have write access. Do not modify production systems during testing. On Windows, administrators can start with a read-only inventory:
$roots = @(
"$env:ProgramFiles\Foxit Software",
"${env:ProgramFiles(x86)}\Foxit Software",
"$env:ProgramData\Foxit Software"
)
Get-ChildItem -Path $roots -Recurse -File -ErrorAction SilentlyContinue |
Where-Object { $_.Name -match 'config|update|upgrade|\.ini$|\.xml$|\.json$' } |
ForEach-Object {
"`n$($_.FullName)"
icacls.exe $_.FullName
}
This command is an investigative aid, not a substitute for the vendor’s affected-file identification. Preserve permissions and file hashes before making changes so that an incident-response team can distinguish a vulnerable configuration from evidence of tampering.
Who Is Affected?
The identified vendor is Foxit Software. The named products are Foxit PDF Editor and Foxit PDF Reader, with the affected component described as the product update daemon. The available NVD record does not specify operating-system editions, product release channels, architecture, installation type, or whether both Reader and Editor share the same updater implementation.
No affected version range is currently confirmed. The reviewed material does not establish that all Foxit PDF Editor or Foxit PDF Reader releases are vulnerable, nor does it identify a minimum vulnerable version. Organizations should inventory both products rather than relying on product names alone, because centrally managed, per-user, portable, and machine-wide installations may have different updater files and permissions.
The fixed version is also unknown. Foxit’s security-bulletin landing page was identified as a reference, but the retrieved content did not provide a CVE-specific bulletin or remediation release. Until Foxit publishes version guidance, vulnerability scanners and software inventories should record the status as “affected range unknown, remediation pending vendor confirmation,” not as either fully vulnerable or confirmed remediated.
Technical Notes
A Windows inventory can help identify installed Foxit products and versions while the advisory remains incomplete:
$paths = @(
'HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKCU:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
Get-ItemProperty $paths -ErrorAction SilentlyContinue |
Where-Object { $_.DisplayName -match 'Foxit.*(PDF|Reader|Editor)' } |
Select-Object DisplayName, DisplayVersion, Publisher, InstallLocation
Treat the resulting versions as inventory data only. There is no published affected-version boundary in the reviewed sources against which to compare them. Asset owners should retain the output and re-evaluate it when Foxit releases a CVE-specific advisory.
CVSS Score Breakdown
The published CVSS base score is 8.8, which falls in the high-severity range. The vulnerability description supports a local attack model: exploitation requires access to the affected host and the ability to interact with or modify a local configuration file. The likely business concern is not remote entry but escalation after an attacker has already obtained ordinary local execution.
The complete CVSS vector was not returned in the reviewed NVD response. Consequently, the values for attack complexity, privileges required, user interaction, scope, confidentiality impact, integrity impact, and availability impact cannot be stated as confirmed CVSS components. The phrase “regular users” describes the vulnerability mechanics, but it does not by itself prove the exact CVSS Privileges Required metric.
The 8.8 score should therefore be used for prioritization with a data-quality note attached. Security teams should not reconstruct a vector string from the score or infer missing metrics solely from the prose description. A later NVD update or Foxit advisory may revise the score, provide the vector, or add affected-product metadata.
Technical Notes
For asset-priority decisions, combine the published score with environmental context:
- Prioritize systems where untrusted users can log on or run code.
- Elevate priority for shared workstations, terminal servers, developer systems, and systems handling sensitive data.
- Treat systems with existing malware indicators as incident-response cases, not ordinary patching tickets.
- Recheck the NVD record after vendor publication because the CVSS vector and product ranges may change.
Organizations reviewing broader access-control exposure can also consult this guide to how network segmentation reduces PCI scope, particularly for shared systems and sensitive environments.
Exploitation Status
No verified in-the-wild exploitation was identified in the reviewed sources. CVE-2026-91798 is not listed in the CISA Known Exploited Vulnerabilities catalog. CISA therefore has not cataloged it as a confirmed exploited vulnerability through the KEV program at the time of the check.
No verified public exploit or proof-of-concept repository was identified. The reviewed research did not find a credible researcher advisory containing weaponized code, a vendor exploit demonstration, or a GitHub repository specifically tied to this CVE. The absence of a public PoC is not evidence that exploitation is impossible, particularly for a local file-permission weakness that may be straightforward to reproduce after technical details become available.
Defenders should distinguish “not confirmed” from “not occurring.” Newly published vulnerabilities can be exploited before public reporting, and KEV inclusion is not an exhaustive measure of all attacks. Monitor endpoint telemetry and update the assessment when Foxit, NVD, CISA, or a credible incident-response source publishes new information.
How to Detect It
Detection should focus on unauthorized changes to Foxit updater configuration files and unusual script or process execution associated with the update component. Because the exact path and daemon name are not available, organizations should first baseline legitimate Foxit installation directories and updater activity. Alerting should be more aggressive on systems where standard users normally do not administer software.
A useful investigation sequence is to identify recent file modifications, compare files with known-good baselines, review the modifying process and user, and then examine child-process activity. Suspicious indicators include a configuration file changed by an interactive user, a script interpreter launched by a Foxit-related updater process, execution from a user-writable directory, or updater activity outside an approved maintenance window.
Endpoint security products such as Get Malwarebytes → may provide additional malware detection and monitoring capabilities, but they should supplement—not replace—file-permission auditing and process telemetry.
Technical Notes
For environments collecting Sysmon, the following Sigma-style logic can be adapted to local telemetry. The Foxit process and path conditions are intentionally broad because the authoritative executable names and configuration paths have not been published:
title: Possible Foxit Updater Configuration Modification
logsource:
product: windows
service: sysmon
detection:
selection:
EventID: 11
TargetFilename|contains:
- '\\Foxit'
- '\\Foxit Software'
config_file:
TargetFilename|endswith:
- '.ini'
- '.xml'
- '.json'
- '.config'
condition: selection and config_file
level: medium
A second analytic should correlate Sysmon process-creation events with updater-related paths and script interpreters:
EventID=1
AND ParentImage contains_any ("Foxit", "Foxit Software")
AND Image endswith_any ("powershell.exe", "wscript.exe", "cscript.exe", "mshta.exe", "cmd.exe")
This is a detection hypothesis, not a confirmed Foxit-specific signature. Tune it against known-good update behavior and investigate any event where the initiating user is not an approved administrator or software-management service.
Mitigation and Patching
There is no confirmed fixed version in the reviewed NVD data or retrieved Foxit security-bulletin content. Administrators should monitor Foxit’s security-bulletin page and obtain the fixed release directly from Foxit or an approved enterprise software-distribution channel. Once Foxit publishes the affected and fixed versions, deploy the fixed release according to the organization’s tested change process and verify the installed version afterward.
Until version guidance is available, reduce exposure by limiting local access to affected systems, removing unnecessary local administrator rights, and preventing standard users from modifying application and updater configuration files. Endpoint application control can also restrict script interpreters or prevent unapproved child processes launched by Foxit-related executables. These controls reduce risk but do not repair the underlying product defect.
Disabling automatic updates may be considered only as a temporary, documented measure when the updater is demonstrably exposed and compensating controls are in place. It can increase exposure to unrelated vulnerabilities, so organizations should not disable updates broadly without an alternative patch-delivery process.
Technical Notes
The following command can locate candidate Foxit configuration files and remove write access for the built-in Users group after the path has been validated. It is a workaround example, not a vendor-approved remediation. Test it on a nonproduction system first and preserve the original ACL:
$cfg = 'C:\ProgramData\Foxit Software\<validated-updater-config-file>'
icacls.exe $cfg /save "$cfg.acl-backup" /c
icacls.exe $cfg /inheritance:r
icacls.exe $cfg /remove:g 'Users' 'Authenticated Users'
icacls.exe $cfg
Do not run this command with the placeholder path unchanged. The exact configuration filename and required updater permissions have not been published. Removing permissions incorrectly can break updates or create a false sense of security. A safer interim control is to use endpoint policy to alert on, or block, nonadministrative writes to the validated file while allowing the approved update service to operate.
When a vendor-fixed installer becomes available, use the vendor’s documented package and deployment method. For an organization-managed MSI package, a conditional deployment command would be:
msiexec.exe /i .\Foxit-Fixed-Version.msi /qn /norestart
The filename above is illustrative because Foxit has not yet published the fixed version or package name. Do not substitute an unverified installer. Validate its signature, source, version, and release notes before deployment.
For a broader explanation of security hardening in automated software-delivery environments, see this CI/CD security hardening checklist.
References
The primary record is the NVD API entry for CVE-2026-91798. It provides the CVE description, publication metadata, CVSS score, and reference information, but the reviewed response does not provide the complete CVSS vector, affected version ranges, or fixed release.
Foxit’s security-bulletin page is the relevant vendor source and should be checked for a CVE-specific advisory, affected product versions, fixed builds, and supported deployment instructions. The available page content did not include those details at publication time.
CISA’s Known Exploited Vulnerabilities catalog is useful for tracking confirmed exploitation under the KEV program. CVE-2026-91798 was not listed at the time of review; that status should be rechecked because catalog membership can change.
| Source | URL | Relevance |
|---|---|---|
| NVD CVE API | https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-91798 | CVE description, publication data, and CVSS score |
| Foxit Security Bulletins | https://www.foxit.com/support/security-bulletins.html | Vendor advisories and future fixed-version guidance |
| CISA KEV Catalog | https://www.cisa.gov/known-exploited-vulnerabilities-catalog | Exploitation-status verification |
Start by inventorying Foxit Editor and Reader installations and checking updater configuration-file permissions on systems where untrusted users can log on or run code. Apply compensating controls where exposure is confirmed, then update the records and deployment plan when Foxit or NVD publishes authoritative technical details.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.