WordPress Plugin CVEs: What to Patch Now

WordPress core still comes first. CVE-2026-119977, the unauthenticated upgrade-window race condition, is in CISA’s Known Exploited Vulnerabilities catalog, and CISA set a federal remediation deadline of November 6. If the site is not on 7.1.4, stop here and fix that first. The core details are in our WordPress 7.1.4 security post.

This post is about the plugin layer. Three plugin CVEs matter right now because each one lands in a different operational bucket: one is already exploited and has a patch, one has a patch but is easy to miss, and one has no fixed release listed in NVD. That last bucket is the one that turns a plugin update into an incident-response task.

An affected version is not the same thing as a compromised site. The plugin has to be installed and active, and the vulnerable path has to be reachable. The point of the table is triage, not panic: check the inventory, then act on the versions that are present.

Bricksforge: exploited, patched, still worth checking

Bricksforge has the clearest “patch now” signal. CVE-2026-85097 is an unauthenticated arbitrary file upload in versions through 3.1.8.9. The flaw is in the handling of the temporaryFileUploads parameter during form submission. An attacker can obtain a nonce from the plugin’s AJAX endpoint, upload a GIF/PHP polyglot that passes MIME validation, then submit a form whose server-side file path points at the validated GIF while the attacker-controlled URL ends in .php. The result is PHP execution on the server.

The severity is 9.8, and the exploit is not theoretical. SecurityWeek reported that Patchstack saw in-the-wild exploitation attempts starting October 7. The plugin is used by roughly 6,000 websites, according to the same report. Bricksforge fixed the issue in 3.1.8.10.

Update to 3.1.8.10 or later. If the site cannot update immediately, deactivate and remove the plugin until it can. Then check the upload and temporary directories for unexpected .php files, review administrator accounts, and compare plugin files against a clean copy. A file upload bug that reaches PHP execution is a code-execution bug, not a spam or defacement bug.

Popup Builder: one request can wipe every popup

Popup Builder is the “patch, but do not assume it is low impact” case. CVE-2026-89270 is an authorization bypass in versions through 4.4.5. The plugin does not properly verify that a user is allowed to perform the action, so an unauthenticated attacker can trash all published popups on the site with a single GET request. The NVD description also notes a second flaw in SGPopup::find(): when the preview parameter is present, the function returns false for every normally published popup, which causes the trash branch to fire against every popup at once.

The CVSS score is 9.1, with high integrity and availability impact and no confidentiality impact. In plain terms: this is not a data-theft bug, but it can remove the site’s conversion and announcement layer in one request. If popups are part of checkout, lead capture, or a launch, the business impact can outlast the technical fix.

Update past 4.4.5. If the site cannot update, deactivate the plugin and restore the popups from a known-good backup. Check the access logs for unauthenticated requests to the plugin’s preview path, and check the popup list for unexpected trash events. Restoring the popups without fixing the authorization check just resets the target.

CryptoPayment Gateway: no fixed release listed, so remove it

CryptoPayment Gateway is the worst case in this set because there is no fixed release to point to. CVE-2026-81648 affects versions 1.2.1 through 1.2.2 and carries a CVSS score of 10.0. The plugin does not apply an authorization check on one of its AJAX endpoints. An unauthenticated user can invoke administrative operations, including deleting arbitrary files on the server, overwriting the payment gateway configuration, and recovering stored wallet credentials in cleartext.

NVD lists no fixed version for this record as of November 10, 2026. That changes the response from “patch” to “remove and contain.” If the plugin is still installed, treat the site as potentially compromised until the evidence says otherwise. Remove the plugin, take the payment gateway offline if it is still connected, rotate wallet keys and any API secrets that were stored in the plugin, and review the gateway configuration for changes. Check wp-config.php, administrator accounts, and recently modified files for signs of persistence.

If removing the plugin immediately would break checkout, put the site into a maintenance mode or disable the payment path first. A broken checkout is recoverable; exposed wallet credentials are not. Do not restore the plugin from a backup without first confirming that the backup predates the exposure and that the vulnerability is actually gone.

Core is still the first item

The core bug deserves its own sentence because it is the one with a federal deadline. CVE-2026-119977 affects WordPress 4.7 through 7.1.3. Predictable, web-accessible staging paths during full-package upgrades let an unauthenticated attacker execute code during the upgrade window. CISA added it to KEV on November 3 with a November 6 due date. WordPress fixed it in 7.1.4.

If the site is still on an affected branch, update to 7.1.4 or the fixed release for that branch. The earlier post covers the full 7.1.4 set, including the stored XSS cluster and the other fixes. Do not let the plugin work below distract from the core update.

The triage order

1. Core first. Confirm WordPress 7.1.4 (or the fixed release for the branch). CISA KEV means this is not a “next maintenance window” item.
2. Bricksforge second. Confirm 3.1.8.10 or later, then check for PHP in upload and temporary directories. This one has confirmed in-the-wild attempts.
3. CryptoPayment Gateway third. Remove it, rotate wallet and API secrets, and audit the gateway configuration. There is no fixed release to install.
4. Popup Builder fourth. Update past 4.4.5, then restore any popups that were trashed and review the logs.

The order is not a statement that the lower items are harmless. It is a statement about what can be fixed versus what has to be contained. A patch you can apply in ten minutes outranks a removal that needs a checkout migration, but the removal cannot wait indefinitely.

Detection and response checks

Start with an inventory, not a scanner. List every installed plugin and its version, then compare that list against the affected ranges above. Pay particular attention to plugins that are active but not updated by the site’s normal maintenance process: bundled plugins, agency-managed plugins, and plugins installed for a single campaign are the ones that get missed.

For Bricksforge, check the uploads and temporary directories for PHP files that do not belong there, review administrator accounts for additions, and compare the plugin directory against a clean copy of 3.1.8.10. For Popup Builder, review the popup list and access logs for unexpected trash operations. For CryptoPayment Gateway, review the gateway configuration, wallet addresses, API keys, and any outbound requests the site made while the plugin was active.

Rotate secrets after containment, not before. If the site is still exposing the vulnerable endpoint, changing keys just gives the attacker a new set to recover. Take the plugin offline, then rotate the wallet keys, gateway API credentials, WordPress salts, and any application passwords that could have been exposed. Review the user list for new administrators and check wp-config.php for unexpected constants or injected code.

A web application firewall or virtual patch can reduce exposure while a change is scheduled, but it is not a substitute for removing an unpatched plugin that can recover wallet credentials. Treat WAF coverage as a temporary control, and verify it against the actual request path rather than assuming the rule is active.

The bottom line

Patch Bricksforge to 3.1.8.10 or later. Update Popup Builder past 4.4.5. Remove CryptoPayment Gateway and rotate the secrets it could have exposed. Then confirm that WordPress core is on 7.1.4. Two of those are updates; one is an incident-response action. The sites that treat all three as “plugin maintenance” are the ones most likely to miss the one with no patch.

Sources and References

• NVD: CVE-2026-119977 (WordPress Core)
• CISA KEV: CVE-2026-119977
• SesameDisk: WordPress 7.1.4 Patches 22 Security Flaws
• NVD: CVE-2026-85097 (Bricksforge)
• SecurityWeek: Bricksforge vulnerability exploited in the wild
• NVD: CVE-2026-89270 (Popup Builder)
• NVD: CVE-2026-81648 (CryptoPayment Gateway)

Verification note: CVE IDs, CVSS scores, affected version ranges, and fixed-version claims were checked against NVD records on November 10, 2026. Exploitation and site-count claims are attributed to the linked SecurityWeek reporting. CISA KEV dates are from the KEV catalog. This post does not include exploit payloads or scanner commands.