Foxit PDF Editor Cloud XSS Flaws

Foxit Software fixed two moderate-severity cross-site scripting (XSS) vulnerabilities in its PDF Editor Cloud platform today, February 3, 2026, in a quiet but important update.

These vulnerabilities, known as CVE-2026-1591 and CVE-2026-1592, could allow attackers to insert and execute arbitrary JavaScript in victims’ browsers, possibly stealing sensitive document data, session tokens, or keystrokes.

Novee, a researcher, found and reported the bugs, which are caused by careless input validation in common UI elements like layer panels and file attachments.

With a CVSS v3.1 score of 6.3 (AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:L/A: N), both are classified as moderately dangerous but cunning threats that necessitate user interaction and low-privilege access.

Foxit has experience with XSS. Although eSign received a similar fix on January 15, these problems with the Cloud editor are more problematic for workflows that rely heavily on documents.

Let’s examine their operation, significance, and Foxit’s actions to close the door. Just the technology, no hype.

CVE-2026-1591: Layers Panel XSS

Imagine using Foxit PDF Editor Cloud to edit a shared PDF. You are navigating through the Layers panel to change the naming or visibility of the document. Layer names are extracted from the document metadata by that panel.

Using a layer name such as , attackers create a malicious PDF. The name renders directly into the DOM without sanitization when you open the file and select the Layers panel.

This is essentially a traditional reflected XSS through DOM-based injection. Without HTML-encoding special characters like <, >, or “,” the application takes the untrusted layer name string and inserts it into an innerHTML or comparable sink. CWE-79 in action: incorrect output encoding is combined with inadequate input validation.

The browser parses it as an executable script on the exact origin, sidestepping the same-origin policy since it’s all client-side.

Exploit flow? The attacker emails or shares the poisoned PDF via a collab link. Victim (with at least basic auth, hence PR:L) opens it, clicks Layers JavaScript fires. Impact skews toward confidentiality (C: H): cookie theft via document: cookie, keylogging with addEventListener on keydown, or even clipboard hijacking.

Integrity’s low (I:L) because it can’t entirely rewrite the page without escalation, and there is no availability hit (A: N). The attack vector needs low complexity (AC:L), network access (AV: N), but user interaction (UI: R), like panel access, keeps it from being wormable.

Proof-of-concept? Novee likely fed something like “><script>alert(1)</script> into a layer name via a hex editor or PDF toolkit like qpdf. No server-side eval needed; it’s a pure client rendering flaw.

Foxit’s patch? They rolled in strict sanitization, think HTML entity encoding (e.g., < for <), plus allowlisting for layer name chars, stripping script tags at the source before DOM insertion.

CVE-2026-1592: File Attachments List Gets Hacked

Sibling to the first, this one’s in the File Attachments list. Same vibe: poisoned attachment filename, like invoice.pdf<script>evil()</script>, listed without escaping. Click or hover the list, and the script executes in context.

Mechanically identical DOM XSS from filename metadata embedded raw into HTML. PDF specs (ISO 32000) allow attachments with names up to 255 chars, no inherent sanitization mandated.

Foxit’s viewer parses the /Names array from the PDF catalog and injects it into a table or ul/li element, without encodeURIComponent or a textContent fallback. Result: arbitrary JS same as above.

CVSS mirrors 1591 because the prerequisites align: authenticated user (PR:L) views a crafted attachment list: no privilege escalation (S: U), but high conf impact from session riding.

Real-world angle? Phish a finance team with a “Q4 report” PDF embedding attachments named to trigger on list view. Steal OAuth tokens for Cloud storage access, exfil docs en masse.

Novee’s report nailed the repro: embed the attachment via Acrobat or muttool, name it maliciously, and host on a share.

Foxit fixed by validating filenames against a regex allowlist (alphanum, spaces, dots, hyphens?) and double-encoding outputs in the list renderer. Client-side now uses DOMPurify-like filtering or createTextNode to neuter payloads.

Echoes from Foxit eSign: CVE-2025-66523 Refresher

For context, Foxit’s January 15 patch in eSign (CVE-2025-66523, CVSS 6.1: AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A: N) shares DNA. Here, no auth needed (PR: N), just trick a victim into clicking a crafted link with URL params like ?callback=<script>alert(1)</script>.

Improper param handling injected untrusted input into JS contexts (e.g., eval(param) or innerHTML = decodeURIComponent (param)), changing scope to S: C for cross-site scripting chaining.

Fix was textbook: input val on params (reject <>”‘), output encoding in JS strings (e.g., JSON.stringify + escape), and Content-Security-Policy tweaks to block inline scripts. Moderate severity, but broader reach since unauth.

Why These Matter in the Wild

XSS like this thrives in doc ecosystems. Foxit PDF Editor Cloud powers enterprise collab, think legal reviews, and invoice workflows.

A compromised session lets attackers pivot: read Cloud-stored PDFs, forge signatures if chained, or beacon to C2 for persistence. CVSS undersells it; in phishing chains, it’s a beachhead.

Stats back the pain: Verizon DBIR 2025 pegs XSS as 8% of breaches, up from miscat web apps. PDF vectors? OWASP lists ’em under A7:2017 (now A03:2021 Injection).

Tools like Burp or PDFiD spot payloads, but prevention’s on vendors.

Mitigations for users pre-patch? Don’t open untrusted PDFs in Cloud viewers.

Use sandboxed readers (e.g., Chrome’s PDFium with site isolation). Enterprise? Enforce PDF allowlisting, monitor JS network fetches via EDR.

Foxit’s advisory stresses “no action needed” post-update auto-patched for Cloud subs.

But hunt your logs: grep for Foxit UA strings with anomalous JS fetches.

Broader Lessons for PDF Security

These bugs spotlight PDF viewer pitfalls. Specs permit rich embeds, JS, forms, and annotations, but renderers must sanitize them.

Foxit joins Adobe (Reader XSS galore) and others in the club. Best practice? Never trust metadata: hash-validate names, use Content Security Policy (script-src ‘self’), and CSP reporting to catch slips.

For devs: Audit sinks like innerHTML and setAttribute(‘title’, …). Libs like DOMPurify or sanitize-html are gold. Test with XSStrike or prompt(1) fuzzers on file handlers.

Said: https://www.foxit.com/support/security-bulletins.html

Site: cybersecuritypath.com