Published October 24, 2026. Based on public CVE records available on that date; details may change.

CVE-2026-112230, published October 23, 2026, affects the Popup Builder WordPress plugin before version 4.4.6: a missing authorization check lets unauthenticated requests move popups to the Trash and overwrite their stored preview data. It is rated low severity and the records do not report exploitation. Update Popup Builder to 4.4.6, then check the plugin's Trash for popups nobody on your team removed.

What happened

The flaw is a missing authorization check in a maintenance routine. According to the CVE record, which WPScan assigned, Popup Builder before 4.4.6 "does not perform authorization checks before trashing popup content in a maintenance routine that runs on unauthenticated requests." The result is that an unauthenticated attacker can move affected popups into the Trash and overwrite their stored preview data. The record's title adds that this happens via a post_type parameter. The weakness is classified as CWE-862, Missing Authorization.

The finder is credited as Raphael P. Cigana, with WPScan as coordinator.

The plugin's own 4.4.6 changelog lines up with the record. It lists "Fixed an issue where an unauthenticated request could move published popups to the trash," along with a fix so popup preview mode no longer affects other popups. It also notes a behavior change: popups with a disabled popup type are no longer trashed automatically, and an admin notice now lets administrators move them to the Trash manually.

Severity and exploitation status

This is a low-severity issue, and it is fair to treat it that way. The CVE record from WPScan does not include a CVSS score of its own. CISA's ADP enrichment, added to the record on October 23, 2026, scores it 3.7 (low) with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N. In plain terms:

  • No login is required (privileges required: none) and no user interaction is needed.
  • Attack complexity is rated high.
  • There is no confidentiality or availability impact in the score, and a low integrity impact.

CISA's SSVC assessment in the same record lists exploitation as "none," automatable as "no," and technical impact as "partial." The records reviewed for this article do not report exploitation in the wild. WPScan's entry is linked from the record and is tagged as including exploit details; we do not reproduce them here.

The practical effect is a nuisance rather than a breach: a popup that disappears from the front end because it was moved to the Trash, and preview data that may need to be checked. That still matters if your popups carry a newsletter signup, a cookie or consent notice, or a promotion you are paying to drive traffic to.

Who is affected

Any site running Popup Builder older than 4.4.6 has the vulnerable code. Popup Builder lists 200,000+ active installations on WordPress.org as of October 24, 2026, so the number of sites in scope is large even though the impact per site is small.

Because the record says the routine runs on unauthenticated requests, user registration settings do not change exposure here. A site with no accounts beyond the administrator is just as affected as a membership site.

Sites already on 4.4.6 are not affected by this CVE.

How to check your site

Start by confirming the installed version.

  1. In the WordPress admin, open Plugins and find Popup Builder. Note the version number.
  2. With WP-CLI, run wp plugin get popup-builder --field=version from the WordPress directory.
  3. Run wp plugin list --name=popup-builder if you also want to see whether the plugin is active and whether an update is available.
  4. Repeat for staging and development copies, which often lag behind production.

If the version is lower than 4.4.6, the site is affected.

Next, look for popups that may have been moved to the Trash.

  1. In the admin, open the Popup Builder menu, go to the list of all popups, and switch to the Trash view.
  2. For each trashed popup, ask whether someone on your team deleted it on purpose.
  3. With WP-CLI, wp post list --post_status=trash --fields=ID,post_title,post_type,post_modified lists every trashed item on the site. Scan the post_type column for popups and the post_modified column for dates that do not match any work your team did.

Keep in mind that, before 4.4.6, the plugin could also trash popups on its own as part of normal maintenance (the changelog describes popups with a disabled popup type being trashed automatically). A trashed popup is not proof of an attack. It is a reason to check.

What to do now

The fix is to update Popup Builder to 4.4.6, which is the current version on WordPress.org. Use Dashboard > Updates, the Plugins screen, or wp plugin update popup-builder. The 4.4.6 changelog also lists a separate security fix for stored cross-site scripting through the subscription form's first and last name fields, which is another reason not to put the update off.

After updating:

  • Restore any popup that was trashed without your team's knowledge, using Restore in the Trash view.
  • Open each restored or active popup and preview it, since the record says preview data could be overwritten. Confirm the content, display rules and form settings are what you expect.
  • Watch for the new admin notice the changelog describes. If it lists popups with a disabled popup type, decide whether to move them to the Trash yourself.
  • Turn on automatic updates for the plugin on the Plugins screen if your change process allows it, so the next fix does not wait for someone to notice.

If you cannot update right away, the low severity gives you some room, but schedule the update rather than leaving it open-ended. Keeping marketing plugins such as popup builders current belongs on the same list as core and security plugins; our WordPress maintenance plan checklist covers how to keep that routine.

A trashed popup on its own does not suggest a wider compromise. If you also see things like unfamiliar admin accounts or plugin changes nobody made, work through finding hidden WordPress admin users and scanning WordPress for malware before assuming the popup issue is the whole story.

When to get help

Most sites can handle this CVE with a plugin update and a quick look at the Trash. Get help if you find signs of activity beyond trashed popups, or if you manage many sites and want plugin updates handled consistently. A security audit can review your plugin inventory and update process, and WordPress hardening covers the settings around it.

Sources