Popup Builder EUVD-2026-114593

Exploitable against default configurations of the Popup Builder plugin (≤4.4.5) that have one or more published popups, via a single unauthenticated remote GET request carrying the sg_popup_preview_id parameter - no authentication (PR:N), no user interaction (UI:N), and no non-default setting are required. The only practical precondition is that the target site runs a vulnerable plugin version and has published popups to destroy; the SGPopup::find() behavior with sg_popup_preview_id present is what expands the action from one popup to all popups. Limiting factors are minimal: the impact is confined to popup content (integrity/availability), there is no confidentiality exposure, and sites with no published popups have nothing for the attack to trash.

This is a genuine high-priority issue, not an inflated CVSS number. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H, 9.1) describes network-reachable, low-complexity, unauthenticated, no-interaction exploitation, and the description corroborates every one of those metrics: a single unauthenticated GET request trashes all published popups. The vuln.today decision label is act_now and the finding was reported by Wordfence, both of which reinforce urgency. There is no confidentiality impact (C:N) - this is an integrity/availability attack (I:H/A:H), consistent with mass-trashing content rather than data theft. Two signals are MISSING from the input: there is no EPSS exploitation-probability score and no CISA KEV entry, so active exploitation is NOT confirmed. POC/exploit status is also not asserted as confirmed working code; the references are the Wordfence advisory, the WordPress.org plugin page, source-code lines in the WordPress trac browser, and the fix changeset - not a packaged exploit. The practical risk driver here is the trivially low barrier (unauthenticated GET) combined with the amplification flaw in SGPopup::find(), which the description states causes the trash branch to fire against every popup simultaneously when sg_popup_preview_id is present. In short: low technical barrier plus destructive blast radius justify prioritization even though widespread automated exploitation is not yet evidenced.

A remote, unauthenticated attacker sends a single crafted GET request to a WordPress site running Popup Builder ≤4.4.5 with the sg_popup_preview_id parameter set, which causes the plugin's authorization-missing action to move every published popup into the trash at once. Because SGPopup::find() returns false for each normally published popup when that parameter is present, the trash branch fires against all of them simultaneously, removing the site's popups in one shot. No special exploit code is required and no authentication or user interaction is needed; no confirmed working public exploit is listed in the input, only the vendor advisory and source references.