E2Pdf WordPress Plugin CVE-2026-111410

Exploitation requires an attacker to hold a low-privileged authenticated account on the target WordPress site (PR:L) with access to an e2pdf input field or form that the plugin stores and later renders, in e2pdf versions up to and including 1.32.57. Execution additionally depends on victim user interaction (UI:R) - a higher-privileged user such as an administrator must view the page or content containing the stored payload. These two limiting factors (required authentication and required victim action) mean the flaw cannot be triggered remotely against an unauthenticated default install; it is gated on both account access and social/operational conditions that get an admin to load the malicious content.

This is a moderate, not critical, priority. The CVSS 3.1 vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L, base 6.5) describes a network-exploitable but conditional flaw: it requires an authenticated low-privilege account (PR:L) and victim user interaction (UI:R), with only Low impact to confidentiality, integrity, and availability, offset by a changed scope (S:C) typical of stored XSS executing in another user's browser session. No EPSS score, no CISA KEV listing, and no public POC are present in the supplied intelligence, so there is no public exploit identified at time of analysis. The combination of required authentication plus required user interaction materially lowers real-world risk below what the 6.5 score alone might suggest - this is a realistic but not wormable, not mass-exploitable issue. Note a signal gap: the Low availability impact (A:L) assigned in the input vector is atypical for a stored XSS (CWE-79) and appears to be a conservative/automated scoring choice rather than a demonstrated DoS - verify against the Patchstack advisory.

A low-privileged authenticated user (e.g., a WordPress contributor or a user able to submit data processed by the e2pdf plugin) injects a malicious script payload that is persistently stored by the plugin. When a higher-privileged user such as an administrator later views the affected page or generated content, the stored script executes in their browser session. No public exploit code is identified, so exploitation would currently require an attacker to develop the payload independently.