BugShield WordPress Security

Ghostscript vulnerability WordPress owners need to check: is CVE-2026-39919 patched?

Wed, 14 Oct 2026 00:00:00 GMT

Ghostscript vulnerability WordPress owners need to understand: CVE-2026-39919 matters because WordPress can hand uploaded PDFs to Ghostscript to create preview images. No plugin update will fix it, because the repair comes from your server's operating system, your hosting provider or your container image. The practical job is to find out whether PDFs reach Ghostscript on your site and whether the installed package carries the fix.

WordPress Site Health Info screen with the Media Handling section expanded, showing the active image editor as GD, ImageMagick and Imagick marked not available, and Ghostscript version not available on this example site WordPress.org. Source details. Resized and converted to WebP.

How Ghostscript connects to your WordPress site

Ghostscript is a document engine. It reads PDF files and turns their pages into images, and it sits quietly underneath many applications that never mention it by name, which is why many site owners run it without knowing they do.

Since WordPress 4.7, core can generate an image of a PDF's first page when it creates attachment details. On a server with the PHP Imagick extension, the chain runs from WordPress to Imagick, then ImageMagick, then Ghostscript. Ghostscript only starts when something asks for a picture of the PDF, so a form that simply saves a file to disk never wakes it up.

According to the Wordfence disclosure, the flaw is a heap buffer overflow: a crafted PDF containing a JPEG 2000 image makes Ghostscript write data past the end of a memory area. The bug lives in Ghostscript itself. WordPress and any form plugin are only the route a file takes to reach it.

Who is exposed to the Ghostscript vulnerability on WordPress

Stock WordPress does not let anonymous visitors upload PDFs to the Media Library. An attack therefore needs a plugin, form, application route or low-privileged account that accepts PDFs. Your site is exposed only when all of the following are true at once:

If visitors or limited users can upload PDFs and you are unsure what happens next, treat the site as affected until your host confirms otherwise. Upload routes deserve attention for other reasons too, as the recent form upload flaws in popular plugins showed.

A visitor or low-privileged user can upload a PDF.
Something on the site then asks for a preview or thumbnail of that PDF.
The server has Imagick, or another tool that calls Ghostscript to make the picture.
The installed Ghostscript package does not include the fix. Affected code spans Ghostscript 9.21 through 10.07.1 where the OpenJPEG decoder path is present.

Severity, patch status and exploitation status

Artifex fixed the flaw in Ghostscript 10.08.0, released on 8th September 2026. The CVE carries a CVSS 3.1 score of 9.8, which describes a worst case: a network-facing application that accepts PDFs without a login. Successful code execution runs with the permissions of the account processing the PDF, which is not automatically full control of the server.

Wordfence reached unauthenticated remote code execution on one purpose-built WordPress test site. Its two proof-of-concept files worked only against the exact Ghostscript build they were prepared for and failed in 10,240 attempts across ten other package environments. At the time of its disclosure, Wordfence said it had found no public evidence that the flaw was being exploited. Build-specific exploits still matter when many sites share one hosting image, so the right response is to patch rather than wait.

Read the full package revision, not gs --version

Linux distributions add security fixes to the older Ghostscript version they already ship. Ubuntu 22.04, for example, fixed the flaw in a package that still reports Ghostscript 9.55.0, so gs --version alone cannot tell you whether you are patched. Run dpkg -s ghostscript on Debian and Ubuntu, or rpm -q ghostscript on Fedora and the Red Hat family, and compare the full revision with your distribution's advisory.

The Ubuntu advisory (USN-8791-1) and the Debian tracker list these fixed revisions:

Not every release has a fix yet. Debian 12 bookworm, at 10.0.0~dfsg-11+deb12u8, is still listed as vulnerable, and Ubuntu 20.04 and older are marked as needing evaluation. AlmaLinux 10 published a fix on 2nd October 2026. As of 9th October 2026, Fedora 44, Alpine 3.22 and Alpine 3.23 still listed older revisions, so check their current pages. Watch for the release candidate as well, because the 10.08.0 release candidate also reports 10.08.0 but is not fixed.

Ubuntu 22.04: 9.55.0~dfsg1-0ubuntu5.14
Ubuntu 24.04: 10.02.1~dfsg1-0ubuntu7.9
Ubuntu 26.04: 10.06.0~dfsg-3ubuntu1.1
Debian 13 trixie (security): 10.05.1~dfsg-1+deb13u3. The tracker records the fix as first arriving in 10.05.1~dfsg-1+deb13u2 through DSA-6516-1, so deb13u2 or any later revision from the security repository carries it. The plain trixie package, 10.05.1~dfsg-1+deb13u1, is still listed as vulnerable, so Debian 13 needs the update from the security repository.

What to do now

If your site is on shared or managed hosting where you cannot run package commands yourself, your host's confirmation of what is installed carries the weight, so work through these steps in order:

Sites that run in containers take a different route to the fix, which is why the container step asks for a rebuild. When Wordfence tested an official WordPress Docker image snapshot on 15th September 2026, it contained a vulnerable Ghostscript package, Imagick and a working PDF preview path. Restarting an old container keeps whatever package it was built with, so rebuild from an updated image and check the Ghostscript revision in the image you actually deploy.

Ask your host whether uploaded PDFs reach Ghostscript through Imagick, and which Ghostscript package revision is installed.
Open Tools > Site Health > Info > Media Handling to see whether Imagick lists PDF as a supported format. Treat the result as a clue only.
If you manage the server, install the fixed Ghostscript package from your distribution and follow the vendor or host restart guidance.
For containers, pull an updated base image, rebuild without relying on cached layers and redeploy.
Run dpkg -s ghostscript or rpm -q ghostscript again, or ask your host to confirm, and match the revision against the advisory.

Interim protection if you cannot patch yet

Every step above depends on a fixed package being available, so Debian 12 users, along with anyone still waiting on a host, need a stopgap in the meantime. Your strongest option is to stop accepting PDFs from visitors and low-privileged users, which keeps those files away from the converter entirely.

Disabling PDF reads in ImageMagick's security policy also blocks the path, at the cost of PDF previews. On shared or managed hosting, ask your host to make that change, and our guide to PHP and server settings explains how to prepare and test server-level changes with them.

Limiting files per submission and rate-limiting upload forms reduces an attacker's opportunities without closing the hole. WordPress retries a failed PDF preview with a different setting, so one crashing PDF starts two Ghostscript processes, and a failed attempt still returned a successful upload response in Wordfence's test.

Verifying the fix: observation versus proof

A quiet server proves nothing on its own. Wordfence's test PDF rendered without crashing on Debian 12, yet 28 of 40 altered versions of that file did crash it, and Debian 12 remains unpatched. Any single file that fails to crash your site tells you about that file, not about your server.

Proof comes from the installed package revision matching your distribution's fixed version, or written confirmation from your host naming that revision. Site Health showing PDF support confirms only that Imagick recognises the format; it says nothing about ImageMagick policy or the Ghostscript fix. If you would rather have server packages, plugins and upload routes reviewed as part of regular upkeep, our managed updates service covers tested rollouts with backups.

Sources

Ghostscript vulnerability WordPress FAQs

Is there a WordPress plugin update for CVE-2026-39919?

No. The flaw is in Ghostscript, which your operating system, host or container image supplies. The fix arrives as a system package update or a rebuilt container image.

Why does gs --version still show an old number after patching?

Distributions add the fix to the version they already ship. Ubuntu 22.04's fixed package still reports 9.55.0, so check the full revision with dpkg -s ghostscript or rpm -q ghostscript instead.

Is my site safe if nobody can upload PDFs?

If no visitor or low-privileged user can upload a PDF that then gets previewed, this attack route is not open on your site. You should still ask your host to patch, because other tools on the same server can process PDFs.

Has this Ghostscript flaw been exploited against real sites?

At the time of its disclosure, Wordfence said it had found no public evidence that the flaw was being exploited. Its exploits worked on one build-matched test site, which is why patching matters for shared hosting images even without known attacks.

What can Debian 12 users do while bookworm is still listed as vulnerable?

Stop accepting PDFs from untrusted users, ask your host to disable PDF reads in the ImageMagick policy, and rate-limit upload forms. Keep checking the Debian tracker for a fixed bookworm package.

Originally published on BugShield.

WordPress 7.1.3 security release: seven fixes sorted by who can exploit them

Mon, 12 Oct 2026 00:00:00 GMT

The WordPress 7.1.3 security release arrived on 6th October 2026 with seven security fixes and four bug fixes. Patchstack does not class it as a drop-everything emergency, but several fixes depend on who can log in to your site, so installing the update is the first step rather than the whole job.

Older WordPress Users screen (version 5.0.3 shown) listing three accounts with Administrator, Author and Subscriber roles, as an example of the role list to review WordPress.org. Source details. Resized and converted to WebP.

What the WordPress 7.1.3 security release changes

WordPress recommends updating immediately because 7.1.3 is a security release. Patchstack, which reviewed the fixes in detail, advises updating as soon as you can while describing the release as something other than a drop-everything emergency. Both views fit together once you see what each flaw needs: the comment-feed leak needs nothing beyond reaching the feed, the comments XSS needs a visitor plus a moderator's click, three fixes need a Contributor or Author account, one needs an administrator to run an export, and the last depends on a plugin.

The release follows 7.1.2, which fixed a local file inclusion flaw, tracked as CVE-2026-87902, that Patchstack says could lead to remote code execution under the right PHP configuration. If you skipped that update, installing 7.1.3 brings both sets of fixes in one step. Neither source reports exploitation of the 7.1.3 issues.

Two fixes begin with a visitor who has no account

A comment feed leak is the simpler of the two. On single-post comment feeds, WordPress loaded a post's comments before checking whether the visitor was allowed to see that post. The post itself was then hidden, yet its comments were still printed in the feed, which Patchstack's review confirms. Comments on private and unpublished posts could therefore have been readable through the feed before you updated.

Stored cross-site scripting, known as stored XSS, accounts for the other: an attack that saves harmful code somewhere a trusted user later triggers it in their own browser. Here, a visitor without an account leaves a pending comment containing a crafted link, but that alone achieves nothing. The attack also needs a moderator with Editor rights or higher to click the link on the Comments admin page, and the crafted markup has to sit inside a wrapper carrying the contextual-help-tabs class. Patchstack places this pending-comment route in versions 7.1.0 to 7.1.2, because 7.1.0 added the formatting support the attack relies on. According to Patchstack, the older backports harden the same code, though WordPress describes those backports as still in progress.

Installing 7.1.3 is the actual fix. Until every site you manage is on it, have moderators approve or delete pending comments based on the text they can read, without clicking links inside them. Treat that habit as a sensible precaution while you schedule the update, not as a substitute for it.

Three fixes need a Contributor or Author account

The next three fixes need someone logged in with a Contributor or Author role. Reviewing those accounts alongside the update is a sensible step, particularly where they belong to guest writers, former staff or old agency logins.

By pointing the block editor's link preview at a page they controlled, a Contributor was able to trigger a denial of service, meaning an attack that makes a site slow down or stop responding. Patchstack explains that a loop inside WP_Http::make_absolute_url() never exits when it meets certain relative paths, so the code keeps running instead of returning a result.

Embedded content accounts for the next fix, which both sources list as Imgur embeds vulnerable to XSS. Imgur sat on the WordPress trusted embed list, so whatever Imgur's API returned was printed directly onto the page instead of being reduced to a sandboxed frame. Patchstack notes that the response includes text the uploader controls, for example from their own image or album, which meant attacker-controlled content reached the page unfiltered. The attacker here needs Contributor access or higher, and Patchstack lists one further condition: a target has to view that page for the attack to land. Version 7.1.3 removes Imgur from the trusted list.

Last in this group comes a smaller permissions slip. Authors were able to make posts sticky, pinning them to the top of the blog, through the REST API, because the check passed for anyone holding the publish_posts capability, which Authors have. The fix tightens that capability check, and neither source describes any impact beyond making posts sticky.

One fix needs an admin export and one depends on plugins

The WXR export is the file produced by Tools > Export. A second-order SQL injection, where bad data already stored in the database is later run as part of a query, affected how that export collected featured-image IDs. Exploiting it needs an administrator to export a single content type while a malicious _thumbnail_id value already sits in the database. The default All content export does not reach the vulnerable code, and the code only exists from 6.5.0 onwards.

The final fix is hardening. WordPress builds some action names from a post's status and type, so publishing a post fires publish_post. A plugin passing raw values into wp_insert_post() could create a post whose status and type combined into an unrelated action. Patchstack's example is a post saved with the status delete and the type post, which fires delete_post, so any callbacks hooked to that action run as if a post had been deleted. WordPress 7.1.3 only fires these hooks when the status and post type are registered. Your exposure here depends on the plugins you run, and the update closes the gap either way.

Update-and-audit checklist for WordPress 7.1.3

Work through these steps in order and keep a note of what you checked on each site. After updating, Patchstack advises clearing the site cache, and it notes that the update leaves oEmbed data already stored in the database as _oembed_* post meta and oembed_cache posts in place.

Because that stored data survives, we recommend going a step further than Patchstack's advice: clear every cache layer, including any host or CDN cache you use, so visitors receive fresh pages, and ask a developer or your host to check and remove the stored data behind any suspicious Imgur embed. Alongside the update, review who holds Contributor or higher roles.

Take a backup you know you can restore, then go to Dashboard > Updates and update to 7.1.3. If the site has automatic background updates, confirm the installed version on that screen instead of assuming the update has run.
Open Users > All Users and filter by Contributor, Author, Editor and Administrator. Remove or downgrade any account that no longer needs that level of access.
Clear your site's cache, as Patchstack advises, along with any server cache from your host and any CDN cache your site uses.
Review posts that embed Imgur content, starting with any added by Contributors you do not fully trust. Patchstack says the existing embed keeps rendering after the update, so have a developer or host remove its stored data.
For sites on older WordPress branches, check whether a backport for that branch has shipped, and plan a move to the current version.

Older branches and backports

WordPress backports security fixes, as a courtesy, to every branch still eligible for them, which currently reaches back to 4.7. Only the most recent version is actively supported. As Patchstack reported on release day, backports had shipped through the 6.6 releases while branches 4.7 to 6.5 were still waiting, and WordPress said the remaining backports would ship as they became ready.

A site pinned to an older branch because of a plugin or theme dependency needs two things: a check of Dashboard > Updates for a new minor release on its branch, and a plan to reach the current version. If your branch is still waiting for its backport, start that plan now.

How to confirm the update worked

Open Dashboard > Updates and check that it reports WordPress 7.1.3 as installed. The screen confirms the code running now, and it says nothing about whether anyone used one of these flaws before you updated.

To look beyond the version number, check for signs of misuse: unfamiliar accounts in Users > All Users, posts you did not expect, or Imgur embeds from unknown authors. A past read of the comment feed leaves nothing in the dashboard, so no check there can show whether comments on private posts were seen. Finding nothing is reassuring, but an empty result does not establish safety on its own. If you spot an administrator you did not create, our guide to how hidden admins were created in a recent plugin attack explains how to check for rogue administrator accounts.

Core releases do not fix plugin flaws, so finish by running your plugin list through our vulnerability lookup using each plugin's slug and installed version. Treat any result it returns as a record to act on, and an unknown result as a gap rather than a clean bill of health.

Sources

WordPress 7.1.3 security release FAQs

Is WordPress 7.1.3 an emergency update?

WordPress recommends updating immediately because it is a security release. Patchstack advises updating as soon as you can but does not class it as a drop-everything emergency. The comment-feed leak needs nothing beyond reaching the feed, the comments XSS needs a visitor plus a moderator's click, three fixes need Contributor or Author access, one needs an admin export and one depends on a plugin. Neither source reports exploitation.

Will automatic updates install WordPress 7.1.3 for me?

Sites that support automatic background updates begin the update on their own. Starting is not the same as finishing, so check the installed version on Dashboard > Updates to confirm 7.1.3 is in place.

Does clearing my cache remove a malicious Imgur embed?

Clearing your site's cache is the step Patchstack recommends after updating. Patchstack also notes that the update does not remove oEmbed data already stored in the database as _oembed_* post meta and oembed_cache posts, and that a malicious embed saved before 7.1.3 keeps rendering. Review posts with Imgur embeds as well, and ask a developer or host to remove the stored data behind any suspicious ones.

My site runs an older WordPress branch. Is it protected?

On 6th October 2026, backports had shipped through the 6.6 releases, while branches 4.7 to 6.5 were still waiting. WordPress says those backports will ship as they become ready. Check Dashboard > Updates for a new minor release on your branch, and plan a move to the current version.

Which user accounts should I review after updating?

Review everyone with Contributor, Author, Editor or Administrator roles under Users > All Users. Three fixes involve Contributor or Author access, and the comments XSS relies, among other conditions, on an Editor or higher clicking a link, so remove or downgrade any account that no longer needs its current role.

Originally published on BugShield.

Bricksforge vulnerability: update to 3.1.8.10 as attacks target file uploads

Sun, 11 Oct 2026 00:00:00 GMT

The Bricksforge vulnerability tracked as CVE-2026-85097 lets an attacker who has no login plant PHP code on your server through the plugin's form uploads. Security firm Patchstack reports attack attempts in its own monitoring since 7th October 2026 and says Bricksforge 3.1.8.10 closes the flaw. If your Bricks Builder site uses the Bricksforge add-on, update it now, then check your uploads folders and logs, because the update stops new attacks without removing anything already planted.

Screenshot of an older WordPress 5.2.4 dashboard for a sample blog, showing a PHP update notice, Quick Draft and At a Glance panels Gmoran6. CC BY-SA 4.0. Resized and converted to WebP.

How the Bricksforge vulnerability works

Bricksforge adds extra features to Bricks Builder, including forms that accept file uploads. Patchstack's advisory describes a problem that unfolds in two stages. When a visitor first uploads a file, Bricksforge checks the file type. A genuine image with PHP code hidden inside passes that check, because it really is an image.

The second stage comes when the form is submitted. At that point the plugin trusts the file details sent by the visitor's browser, including the address where the file should be saved. An attacker can change that destination to a PHP filename, and Bricksforge writes the image's contents there. The hidden code then sits in a file the server is willing to run.

PHP is the programming language WordPress runs on, so a PHP file planted this way hands control to whoever placed it. Patchstack lists the possible consequences as web shells (hidden control panels that let an attacker run commands on the server), changed site content, reading sensitive data and persistent access to the site.

No login is required to attempt the attack. Patchstack tracks the flaw as CVE-2026-85097 and gives it a CVSS score of 10.0. CVSS is the common scale for rating how severe a vulnerability is, and 10.0 sits at the very top of it.

Which sites are affected and what Patchstack has seen

The exposure covers WordPress sites running the Bricksforge plugin at version 3.1.8.9 or earlier. Bricksforge is a separate add-on for Bricks Builder, so a site built with Bricks alone falls outside this advisory. Patchstack states no extra condition for exposure, such as a published form or a file upload field, so the installed version alone decides whether you need to update.

Patchstack first saw exploitation attempts in its own telemetry at 21:47 UTC on 7th October 2026 and published the advisory on 8th October 2026. That time marks the earliest activity Patchstack observed, not a confirmed start date for attacks everywhere. The attempts show attackers are actively trying the flaw, yet they do not mean any particular site, including yours, has been broken into.

According to Patchstack, version 3.1.8.10 contains the fix. The vendor's changelog, referenced in Patchstack's advisory, is the place to confirm the security fix for the copy you install.

Upload flaws have featured in our recent coverage of Elementor Pro and the Gravity Forms issue, and the same lesson applies here: patching is only half the job when attackers can leave files behind. Bricksforge still needs its own response, with a different CVE, a different fixed version and its own folders and log entries to check.

Check whether Bricksforge is installed on your site

The quickest check is in the WordPress dashboard. Go to Plugins > Installed Plugins and look for Bricksforge in the list. The version number appears under the plugin's description, and that number decides what you do next.

Inherited sites deserve extra care. When a freelancer or former agency built the site, you may not know every plugin they added, and an add-on can be installed to power a single form or layout feature. Check the plugin list on every site they handed over, not only the one you think uses forms.

Locked out of wp-admin? Ask your host, or open the hosting file manager and look inside wp-content/plugins for a folder named after Bricksforge. Our guide to website file management explains where those folders sit and how to approach file changes safely.

For a quick outside view, our free plugin detector looks for plugin clues in public page assets. A match is a useful hint. An empty result proves nothing, because a plugin does not always leave traces in public pages, so the dashboard or file check remains the real answer.

How to update Bricksforge to 3.1.8.10

With active attempts under way, the update comes first. A careful update routine includes a backup and a staging test, and a recent backup is still worth having, but holding the patch back for a full staging cycle leaves the upload hole open in the meantime. Work through these steps in order.

Bear in mind that any backup, recent or older, can contain files an attacker has already uploaded. Patchstack's 7th October date marks only the earliest activity it observed, so no backup is clean simply because of its date.

Take or confirm a recent backup of your files and database so you have a recovery point if the update causes a problem.
Open Plugins > Installed Plugins and note the current Bricksforge version.
Update Bricksforge to 3.1.8.10 or later using the vendor's own update route.
Reload the plugins screen and confirm the version now reads 3.1.8.10 or higher.
Check the vendor's changelog to confirm the release you installed includes the security fix.
Submit a test entry on each Bricksforge form, including one with a file upload, and check the entry arrives as expected.

If you cannot update straight away

Patchstack states that its RapidMitigate rule blocks these exploitation attempts for the sites it protects. That protection applies only to sites covered by Patchstack, and it does not repair the plugin.

The rule is not a substitute for updating. The vulnerable code stays on the server until Bricksforge is updated, so plan the update for the same day if you can, and run the file and log checks below whether or not a rule was in place.

Updating closes the hole but leaves planted files behind

The update stops new uploads through the flaw. Any file an attacker managed to place before you patched remains on the server, ready to run, which is why the checks after the update matter as much as the update itself.

Start in the folder Patchstack highlights: wp-content/uploads/bricksforge/tmp/. Any PHP file there is a red flag, and files following the pattern login_admin_*.php (login_admin_ followed by other characters) match the indicators Patchstack lists. Patchstack also gives /wp-content/uploads/2026/10/ as an example of where login_admin files were aimed, so widen the search to the rest of wp-content/uploads, which normally holds images, documents and other media rather than PHP code.

Your hosting file manager or an SFTP client will show these folders. Sorting by modification date helps you spot recent changes, but treat dates with caution. Patchstack's 7th October date is only the earliest activity it saw, so an earlier date does not clear a file, and file dates can be altered.

Found something suspicious? Resist deleting it on the spot. Note the file name, location and date, download a copy for the record, and then follow a structured clean-up. Our guide to fixing a hacked site covers documenting symptoms and closing the entry point, while the manual malware removal guide walks through containment and replacing affected files.

Check your server logs for Bricksforge attack requests

Your host's access logs record the requests made to your site, and Patchstack lists several indicators worth searching for. A POST request, mentioned below, is the kind a browser sends when someone submits a form.

Treat a match on the form address with care. Genuine visitors submitting your Bricksforge forms use the same /wp-json/bricksforge/v1/form_submit address, so a bare match proves nothing. The stronger signs are submissions containing temporaryFileUploads and follow-up requests to PHP files that have newly appeared in your uploads folders.

Standard access logs record the address requested rather than the contents of the form, so the temporaryFileUploads detail will only show in more detailed logs from your host, a firewall or a security plugin. Ask your host what they keep if you cannot see it yourself.

Hosts keep logs for different lengths of time, so check how far back yours go. An empty search covers only the period your logs retain, and it cannot rule out activity before then.

POST requests to /wp-json/bricksforge/v1/form_submit, especially where the submitted data includes temporaryFileUploads.
Requests to admin-ajax.php using the bricksforge_form_submit action.
Calls to the bricksforge_regenerate_nonce action.
Requests to newly created PHP files in uploads folders, such as a login_admin file under /wp-content/uploads/2026/10/.

What your results do and do not prove

A clean set of checks is good news with limits. No suspicious files and no matching log entries mean you found no evidence of abuse. Proof that the site was never targeted is a different matter, because logs can be incomplete, attackers can rename or move files, and a planted file can create further access elsewhere before anyone notices.

Version numbers carry the same caveat. Seeing 3.1.8.10 on the plugins screen confirms the patched release is installed, yet the number says nothing about what happened before the patch went on.

Any suspicious file or matching request changes the picture. Treat the site as potentially compromised and investigate beyond the update: review administrator accounts under Users > All Users, change passwords for WordPress, hosting and database access, and replace the security keys in wp-config.php so existing logins are signed out.

Restoring a backup brings its own catches. An older copy can already contain planted files, and restoring it also brings back the vulnerable Bricksforge version, so the update must be applied again straight afterwards.

Getting help with a Bricksforge update or clean-up

When the update goes through smoothly and your checks come back clear, keep a short note of what you did and when, including how far back your logs reached. If you would rather not touch the plugin yourself, BugShield can carry out the Bricksforge update as a one-off fix at a confirmed price. Where suspicious files, unknown requests or other signs of compromise have turned up, our hacked site clean-up is the better route, because the work goes beyond the update to closing the entry point.

For sites you look after over the long term, the free plugin vulnerability lookup lets you check a plugin slug and installed version against known records. A brand-new CVE such as this one may not be listed yet, and a missing record is never a clean bill of health, so treat the advisory itself as the authority for now.

Sources

Bricksforge vulnerability FAQs

Is every Bricks Builder site affected by the Bricksforge vulnerability?

No. Only sites with the Bricksforge add-on installed at version 3.1.8.9 or earlier are affected. A site built with Bricks Builder alone falls outside this advisory. Patchstack states no further condition, so if Bricksforge 3.1.8.9 or earlier appears under Plugins > Installed Plugins, update it.

Which Bricksforge version should I install?

Install 3.1.8.10 or later, which Patchstack reports contains the fix for CVE-2026-85097. After updating, reload the plugins screen to confirm the version number and check the vendor's changelog for the security fix.

Does updating Bricksforge remove files an attacker already uploaded?

No. The update stops new uploads through the flaw, but any PHP file planted beforehand stays on the server. Check wp-content/uploads/bricksforge/tmp/ and the wider uploads folders, including dated folders such as /wp-content/uploads/2026/10/, for unexpected PHP files, especially ones named like login_admin_*.php.

What should I search for in my server logs?

Look for POST requests to /wp-json/bricksforge/v1/form_submit containing temporaryFileUploads, admin-ajax.php requests using the bricksforge_form_submit action, calls to bricksforge_regenerate_nonce and requests to new PHP files in uploads folders. Genuine form submissions use the same form_submit address, so a match on that address alone proves nothing.

My files and logs look clean. Does that prove my site is safe?

No. A clean result means you found no evidence of abuse, not that the site was never targeted. Your logs only cover the period your host retains, Patchstack's 7th October date is just the earliest activity it observed, and files can be renamed or moved. Keep the plugin updated and treat any later sign of trouble seriously.

Originally published on BugShield.

BugShield scanned 100,000 WordPress sites for the Gravity Forms vulnerability

Wed, 23 Sep 2026 00:00:00 GMT

BugShield AI automatically scans the web for WordPress vulnerabilities. For the recent Gravity Forms vulnerability, we ran a targeted scan across 100,000 WordPress URLs. It found 4,697 sites that appeared to be running an affected plugin version, with many still on Gravity Forms 2.x. That is not proof that every site could be exploited, but it is a much larger patching gap than any site owner should ignore.

Check your Gravity Forms version Versions up to and including 3.1.0.4 are affected by CVE-2026-84434. Gravity Forms 3.1.1 is the first patched release, but site owners should install the latest version available through their licence. Get help updating

Why we ran a targeted scan

BugShield AI continuously scans the web for WordPress vulnerabilities. When it finds a site that appears to be running vulnerable software, BugShield Bot automatically warns the owner so there is a chance to fix the problem before somebody abuses it.

The process became especially relevant when CVE-2026-84434 was disclosed in Gravity Forms. The flaw can allow an unauthenticated visitor to upload a dangerous file when an affected site has a public form containing a File Upload field whose visibility is set to Hidden. In the wrong server setup, that file could be executed as code.

We had already published a full explanation of how the Gravity Forms vulnerability works. The next question was broader: now that a fixed release existed, how many WordPress sites still appeared to be running a vulnerable version? We ran a dedicated scan across a list of 100,000 WordPress URLs to find out.

4,697 sites matched the affected version range

The scan identified 4,697 sites running a Gravity Forms version up to and including 3.1.0.4. Put another way, 4.697% of the 100,000 URLs we checked matched the vulnerable version range. Rounded for a simpler comparison, that is about 4.7%, or roughly one in every 21 sites in the scanned list.

Scan result	Finding
WordPress URLs checked	100,000
Sites matching the affected version range	4,697
Share of the scanned list	4.697%, or about one in 21
Affected version range	Gravity Forms 3.1.0.4 and earlier
First patched release	Gravity Forms 3.1.1
Notable pattern	Many affected sites were still running a 2.x release

The denominator matters. We are not saying that 4.7% of all Gravity Forms installations are vulnerable, or that this is a global market-share estimate. It is the result from the specific list of 100,000 WordPress URLs we scanned. Even with that boundary, 4,697 sites is a substantial number of owners left with a known weakness in production.

What the number does and does not prove

A vulnerable plugin version is not the same as a confirmed vulnerable form, and neither is proof of a hacked website. The disclosed attack route also needs a public form with a File Upload field set to Hidden. The server must then be willing to execute the file for the attack to progress to code execution.

Our 4,697 result establishes the part we could identify across the list: those sites appeared to be running Gravity Forms within the affected version range. It does not tell us that each one had the required form configuration, that somebody tried the attack, or that an upload succeeded.

That distinction prevents a useful warning from becoming a frightening but unsupported claim. It should not become an excuse to leave the old plugin installed. Site owners can forget about a form on an old landing page, a draft campaign, or a page built by a previous agency. Updating removes the known weakness without relying on a perfect inventory of every form that has ever been published.

The number of Gravity Forms 2.x sites stood out

A lot of the affected sites were not just one small security release behind. They were still on version 2.x, while Gravity Forms has moved to the 3.x line. Those installations need the same urgent security response, but their owners may face more update work than somebody moving from 3.1.0.4 to a patched 3.1 release.

The official Gravity Forms changelog describes the move from 2.x to 3.x as a major upgrade that may include breaking changes, and recommends testing it in a sandbox. That is sensible advice. A busy site may have custom form code, payment feeds, CRM connections, or styling that needs to be checked before the update reaches live.

Compatibility work explains why an update can be delayed. It does not make the vulnerable version safer. Take a current backup, copy the site to staging, test the newest release there, and set a short deadline for the live upgrade. If a problem appears, fix that problem instead of allowing the old branch to remain indefinitely.

Finding the issue is only half the job

A scan result has little value if it sits in a dashboard nobody checks. BugShield Bot turns the finding into a warning for the site owner. The message can explain which vulnerable software was detected, why it matters, and what the owner can do next.

Careful wording matters here too. The useful message is not that a website has definitely been hacked. It is that the site appears to be running an affected Gravity Forms version and needs an update. If the required form setup was public during that vulnerable period, the owner can then make an informed decision about reviewing the files and logs.

That is the reason we keep the monitoring continuous. New vulnerabilities appear, sites drift out of date, and a clean result from last month cannot describe the software running today. Repeated checks shorten the gap between a problem becoming visible and the person responsible for the site hearing about it.

What Gravity Forms site owners should do now

Start by opening Plugins > Installed Plugins in WordPress and checking the installed Gravity Forms version. Any release up to and including 3.1.0.4 falls inside the affected range. Gravity Forms 3.1.1 contains the first fix, although installing the latest stable release available through the licence is the better target.

Then work through the parts that turn an update into a proper response:

take a current backup before changing the plugin
test the upgrade on staging first if the site is moving from Gravity Forms 2.x
submit every important form after the update, including payments, uploads, notifications, and integrations
check whether any public form used a hidden File Upload field while the affected version was installed
review files and server logs if the known vulnerable configuration was publicly reachable

Updating closes the disclosed route, but it cannot remove a malicious file that may have arrived earlier. Where the vulnerable form configuration existed, check Gravity Forms upload storage, the wider wp-content directory, administrator accounts, must-use plugins, scheduled tasks, and requests made during the exposed period.

The patch gap is the bigger lesson

A security fix can be available and still leave thousands of websites behind. Some owners never see the update notice. Some licences have expired. Others are worried about breaking an old integration, or assume that a quiet site is not interesting to an attacker. The result is the same: vulnerable code stays online after the problem and its fix are public.

The 2.x installations make that gap particularly visible. Updating them may need more care, but postponing the work simply transfers the risk from a planned staging test to an unplanned security incident. Monitoring works best when it identifies that drift early and gives the owner a practical route back to a supported release.

A useful scan should end with a safer website

The headline figure from this scan is 4,697, but the goal is not to collect a larger number next time. It is to help those site owners close the gap. That means detecting the issue, communicating it without exaggeration, and making the update achievable even when an old site needs careful testing.

BugShield maintenance plans include ongoing vulnerability monitoring and managed WordPress plugin updates. If a vulnerable form was public, or the site contains files and users nobody recognises, our WordPress malware removal service can investigate the files, database, accounts, scheduled tasks, and likely entry point.

For a single update or investigation, request a one-off WordPress fix. Whether BugShield handles it or an existing developer does, check the installed version today. A known vulnerability becomes far less useful to an attacker once the affected software is no longer there.

Quick answers about the Gravity Forms scan

What did BugShield find in the scan of 100,000 WordPress sites?

BugShield found 4,697 URLs that appeared to be running a Gravity Forms version affected by CVE-2026-84434. That is 4.697% of the scanned list, or roughly one in every 21 URLs checked. Many of the affected sites were still running a 2.x release.

Does the result mean 4,697 websites were hacked?

No. The scan identified an affected plugin version, not a successful attack. Exploiting this vulnerability also requires a public form with a hidden File Upload field and a server setup that can execute the uploaded file.

Why does finding Gravity Forms 2.x matter?

Gravity Forms treats the move from 2.x to 3.x as a major upgrade that may include breaking changes. Those sites need to patch urgently, but should use a current backup and staging copy to test forms, add-ons, payments, and integrations before updating live.

Which Gravity Forms version fixes CVE-2026-84434?

Gravity Forms 3.1.1 is the first patched release. Sites running 3.1.0.4 or earlier are affected and should install the latest stable version available through their Gravity Forms licence.

What does BugShield Bot do after a vulnerable site is found?

BugShield Bot automatically warns the site owner that vulnerable WordPress software has been detected. The warning gives the owner a chance to update, test the site, and investigate further where the vulnerable configuration may have been publicly reachable.

Originally published on BugShield.

Critical WordPress vulnerability affects versions dating back to 2016

Wed, 23 Sep 2026 00:00:00 GMT

The WordPress CVE-2026-87902 vulnerability can let a visitor make WordPress load a local PHP file that sits outside the active theme. Turning that into control of a website depends on the theme and server setup, but attackers started checking sites within hours of the patch. Update WordPress now, then use the evidence from your own site to decide how much investigation is needed.

Update WordPress now Install the latest WordPress release available for your installation. Version 7.1.2 was the first fix for this vulnerability, but later security releases also need to be installed. A vulnerable version is not proof that the site was hacked, but waiting leaves a known route open while scanning has already begun. Get help with the update

CVE-2026-87902 at a glance

WordPress released the fix on 22nd September 2026 and recommends updating immediately. Its official security advisory gives the flaw a CVSS score of 9.2 out of 10. The rating is Critical because the request does not require a login or a click from an administrator, and a successful chain can end in remote code execution.

Detail	What site owners need to know
Issue	Path traversal leading to local PHP file inclusion and, under the right conditions, remote code execution
Affected releases	Unpatched WordPress releases from 4.7.0 through 7.1.1
First fixed 7.1 release	WordPress 7.1.2
Older branches	Security backports are available for every branch from 7.0 back to 4.7
Severity	CVSS 9.2, Critical
Login required	No
Activity seen	Automated probing, with no attacker-controlled payload delivery observed at publication time

What the flaw changes in WordPress

When somebody opens a page, WordPress works out which template file the active theme should use. The vulnerable part sits in that template resolution. A specially formed request can make get_page_template() step outside the theme directories and include another readable PHP file already present on the same server.

That is serious, but the last part is important. The flaw does not simply let an attacker upload any program and run it on every WordPress website. They need a useful local PHP file to be available, and the active theme must have a particular directory structure. Remote code execution becomes possible when those pieces line up.

The distinction should shape the response. It is not a reason to postpone the update, especially now that the patch is public and probing has started. It is a reason to avoid telling every owner of an outdated site that their website has definitely been taken over.

Which websites meet the known conditions?

The theme condition is a top-level folder whose name begins with page-, in either the active parent or child theme. WordPress names the older Twenty Twelve and Twenty Fourteen themes as examples. The advisory also mentions Neve, Hestia, and Sydney, although the presence of one of those themes does not by itself prove that the full attack chain will work.

The server then needs a readable local PHP file that can be used to move from file inclusion to code execution. One documented route involves a PHP PEAR utility and the register_argc_argv setting. The WordPress advisory says the official PHP Docker image meets that server condition, as does the default cPanel configuration when it runs a PHP version earlier than 8.5.

If either condition is absent, this specific route to remote code execution is incomplete. Checking them can help a developer judge past exposure, but changing a theme or PHP setting is not a substitute for patching WordPress. The vulnerable template handling still belongs in core, and the fixed release removes it there.

Probing began within hours, but probing is not a breach

Patchstack says it first saw attempts at 17:44 UTC on 22nd September, less than five hours after WordPress 7.1.2 was published. The requests matched the encoding addressed by the patch and were sent across several protected sites, which is consistent with somebody building a list of vulnerable hosts.

At the time of publication, every target in those requests was an ordinary WordPress core file. The activity was testing whether the inclusion worked, not delivering attacker-controlled PHP. That does not make the scanning harmless, but it does mean a matching request in an access log is not enough on its own to declare the site compromised.

The timing still matters. Once a security patch is public, the changed code helps attackers understand what was fixed. Here, the gap between release and scanning was measured in hours. Updating before a working attack chain becomes widely automated is much easier than proving what happened afterwards.

Install the right WordPress security release

WordPress 7.1.2 was the first fixed release on the 7.1 branch. The original backports included 7.0.6, 6.9.9, 6.8.10, 6.7.9, 6.6.9 and 6.5.12, continuing down to 4.7.37. These numbers identify the fix for this flaw, not the latest available releases. The WordPress 7.1.3 security release arrived on 6th October with additional security fixes, so install the newest available release rather than stopping at this article's original patch level.

Those backports make a rapid security update possible without combining it with a major-version migration. They are not a promise of long-term support. WordPress only actively supports its latest release, so a site kept on an old branch still needs a separate plan to move forward once the immediate risk is closed.

Take a current backup, then open Dashboard > Updates and install the newest release offered for the site. Confirm the version after WordPress finishes, clear any full-page or edge cache, and check a few important pages, forms, account screens, and checkout steps. If automatic background updates are enabled, verify that the update completed rather than assuming it did.

What to check after the update

Start with access logs for the period before the site was patched. Patchstack highlights requests where pagename contains double-encoded traversal text such as %252e%252e, especially when pagename and page_id appear together on the home page or index.php. Similar requests can arrive through either GET or POST, so checking only the query string may miss part of the picture.

A request in the log shows that somebody knocked on the door. The response tells you more. Unexpected OPML or other core-file output returned from a normal page URL suggests the inclusion succeeded on that host. If you find that response, treat the site as having had a confirmed vulnerable window and widen the review.

A practical review should cover:

unexpected or recently modified PHP files across WordPress, not only inside the active theme
core files that no longer match the clean files from the installed WordPress release
administrator accounts, plugins, themes, and must-use plugins nobody recognises
scheduled tasks, configuration changes, and new files created during the vulnerable period
server and security logs for what happened after a successful probe

Preserve suspicious files and useful logs before cleaning anything. If compromise is confirmed, remove the malicious code, close every persistence route you find, and then rotate affected credentials. Deleting the first odd file without understanding what created it can hide evidence while leaving the attacker another way back.

Patch quickly, then follow the evidence

CVE-2026-87902 has the ingredients that make a core vulnerability uncomfortable: no login is required, the potential impact is high, and probing started on release day. It also has clear preconditions, a complete set of security releases, and no confirmed payload delivery in the activity reported so far. Both sides of that picture matter.

Update first. Then check the theme and server conditions, look at the requests and responses your own site handled, and investigate more deeply where the evidence justifies it. That is a calmer response than assuming the worst, and a safer one than deciding the conditions sound too specific to worry about.

BugShield maintenance plans include monitored plugin, theme, and core updates through our managed WordPress update service. If logs show a successful probe, or the site already contains files and users you do not recognise, our WordPress malware removal service can investigate the files, database, users, scheduled tasks, and likely entry point.

For a single site, you can also request a one-off WordPress fix. Whichever route you choose, the useful finish line is not simply seeing an update notice disappear. It is knowing the fixed release is installed and that the site's own evidence has been checked in proportion to its exposure.

Quick answers about WordPress CVE-2026-87902

Which WordPress versions are affected by CVE-2026-87902?

The advisory covers unpatched WordPress releases from 4.7.0 through 7.1.1. WordPress 7.1.2 was the first fix on the 7.1 branch, with backports through 4.7. Install the latest available release because later versions contain additional security fixes.

Can CVE-2026-87902 affect every outdated WordPress site?

The known route to remote code execution needs both a theme with a top-level directory whose name begins with page- and a suitable readable local PHP file on the server. Sites should still update even when one of those conditions appears to be absent.

Does an attacker need to log in to exploit CVE-2026-87902?

No. The vulnerable template-resolution request is unauthenticated and does not need an administrator to click anything. The theme and server preconditions determine whether it can progress to remote code execution.

Is CVE-2026-87902 being actively exploited?

Patchstack observed automated probing within five hours of the patch. At publication time, the requests tested local WordPress core files and did not deliver attacker-controlled code, so a probe is not proof that a site was compromised.

What should I check after updating WordPress?

Review access logs and responses from the vulnerable period, then check WordPress file integrity, unexpected PHP files, administrator accounts, plugins, themes, must-use plugins, scheduled tasks, and configuration changes. Widen the investigation if a probe returned unexpected core-file output.

Originally published on BugShield.

Self-healing WordPress malware came back after cleanup

Tue, 22 Sep 2026 00:00:00 GMT

We removed a self-healing WordPress malware infection and watched the visible files disappear. By the next day, they were back. The cleanup had reached the symptoms, but the part rebuilding them was still hiding in the database and in code that WordPress loads before an ordinary plugin.

Malware keeps returning? Deleting the file again will not help if another part of the infection can rebuild it. We can trace the persistence, clean the wider site, and check that it stays clean. Ask BugShield to investigate

The site looked clean, until it did not

The first sign was difficult to miss. Some visitors were being shown a fake Cloudflare-style Verify you are human screen instead of the page they expected. Clicking through led to instructions that tried to persuade them to paste a PowerShell command from their clipboard.

That trick is often called ClickFix. It turns a familiar verification step into a piece of social engineering: the visitor is told to run the attacker's command themselves. Microsoft has documented the same broader ClickFix technique, including fake CAPTCHA and human-verification prompts that copy a command for the visitor to run.

We found and removed the files serving the overlay. The website returned to normal, so the result looked promising. Less than 24 hours later, the same malicious pieces had been written back to disk. That return was the useful clue. We were not dealing with one infected plugin file. We were looking at several parts of an infection keeping one another alive.

The files were only the visible part

Self-healing is a descriptive name here, not a special WordPress feature or a formal malware family. The code was not repairing itself in any clever biological sense. It simply had more than one place from which to restart, and every normal page request gave the surviving code another chance to run.

Across the affected sites, the persistence sat in three connected layers:

Layer	What we found	Why a partial cleanup failed
Database	Encoded payload data in `wp_options`, stored under transient names resembling `_site_transient_health_*`	The database still held enough data to rebuild deleted files
Files	Fake plugins, must-use plugins, and copies placed in core-like or writable locations	Removing one copy left other loaders available
Boot and scheduling	Restore code in `wp-config.php` or `wp-content/object-cache.php`, with unfamiliar scheduled hooks	A page load or cron run could write the malicious plugin back

WordPress transients are normally harmless temporary data. Without a persistent object cache, they are commonly stored in the options table, as the WordPress Transients API documentation explains. The attacker was using that ordinary storage mechanism as cover. The name looked like routine health or cache data, while the value carried something the surviving loader could use.

Why the infection returned on the next request

The order in which WordPress starts matters. Configuration and drop-in files can run before the normal plugins you see on the main Plugins screen. Must-use plugins are loaded automatically too. The WordPress must-use plugin documentation notes that they live in wp-content/mu-plugins by default and cannot be switched off like an ordinary plugin. They appear separately under Plugins > Must-Use.

In this infection, code in wp-config.php or an unexpected object-cache.php drop-in checked whether the malicious plugin files were present. When the cleanup removed those files but left the restore code and database payload behind, the next request put them back. Hourly cron hooks provided another way to restart the chain.

That is why the first cleanup appeared to work. The delivery files really had gone, and the bad overlay stopped showing for a while. The quieter persistence layer had not gone with them. A clean homepage proved only that the visible symptom was absent at that moment.

The traces we used to follow it

File names are clues, not a verdict. A host or caching plugin may legitimately install an object-cache.php drop-in, and a well-managed site may have genuine must-use plugins. We compared each item with known-good packages, the site's normal configuration, file history, and the code itself before removing anything.

The more distinctive traces in this incident included:

wp-own-assets.php and files matching wp-feed-normalize-*.php, wp-rest-cache-*.php, wp-rest-hardening-*.php, or wp-rest-optimizer-*.php under wp-content/mu-plugins
plugin directories beginning wp-cache-, security-headers-manager-, or site-performance-toolkit- that did not belong to installed software
files named like class-walker_<hex>.php inside wp-includes/assets, separate from genuine WordPress files
a hidden .own-releases directory and files such as own-stego.php, own-stg.php, qtt-own-core.php.obf, pc_pack.py, or _w10_up.php
code around WP_Core_Integrity or functions named _wp_cuh_restore and _wp_cuh_sql inside wp-config.php
_site_transient_health_* option rows containing large encoded values, unknown cron hooks, and unfamiliar REST routes shaped like check-<hex>
# own-stego-v4 or repeated # BEGIN wp_compat_* blocks in .htaccess

A single matching word is not enough to condemn a file. Broad searches for functions such as base64_decode are useful for finding places to inspect, but legitimate software uses encoding too. The stronger evidence came from several traces agreeing with one another and from watching a surviving loader recreate a deleted component.

The cleanup order changed the outcome

Once we understood the loop, repeatedly deleting the same plugin was no longer useful. The site had to be contained first, then the parts capable of writing files had to be stopped before their output was removed. Working in that order prevented one layer from undoing the next step.

Contain the site and preserve evidence. We restricted public access where possible and took private copies of the files, database, and relevant logs before changing them. An infected copy is evidence, not a backup to restore blindly.
Stop the restore path. We removed the confirmed injection from wp-config.php and dealt with the malicious drop-in before allowing ordinary page requests to keep running.
Remove every confirmed file component. That included the fake must-use and normal plugins, hidden release copies, core-like files, altered rewrite rules, and any secondary locations found during the review.
Clean the database and scheduled hooks. We removed only the confirmed malicious transient data and cron entries after preserving a database copy. Guessing at rows in wp_options can break a site.
Restore trusted application code. WordPress core, plugins, and themes were checked against clean packages or known source, with anything unverifiable reinstalled rather than trusted because its name looked familiar.
Review access and close the entrance. We checked administrators, REST routes, other sites under the same hosting account, logs, and the vulnerable or stolen access that could have allowed the infection in.
Rotate secrets after the code was clean. That covered every WordPress salt, administrator passwords, hosting and SFTP access, database credentials, and other exposed keys. Rotating too early can hand the replacement secrets to malware that is still running.
Watch the site start again. We re-enabled access carefully, triggered normal page loads and cron, rescanned the files and database, and monitored for recreation rather than declaring success after one clean response.

If you cannot safely stop PHP execution, inspect configuration files, or distinguish a legitimate cache drop-in from the malicious one, ask your host or a WordPress security specialist to handle the containment. Removing object-cache.php on a guess can take a working cache offline without touching the real infection.

A returning file changes the question

When malware comes back, the useful question is no longer, “Where is that file?” It becomes, “What had the ability to write it again?” That shift leads naturally into the database, early-loading configuration, drop-ins, must-use plugins, scheduled events, and sometimes neighbouring sites that share the same hosting account.

It also changes what a scan result means. A scanner can correctly remove a malicious file and still leave the site compromised if its view stops at the filesystem. In the opposite direction, an unfamiliar transient or must-use plugin is not automatically malware. Automated findings need enough context to show how the pieces behave together.

For site owners, the simplest warning sign is repetition. If the same file returns, a disabled plugin silently reactivates, rewrite rules reappear, or a fake verification screen vanishes and then comes back, pause the cycle of deleting symptoms. Keep the evidence and investigate the mechanism doing the restoring.

Clean means it stays clean

The important part of this incident was not the strange file name or the fake verification screen. It was the gap between looking clean and being clean. The first pass removed what visitors could see. The successful pass removed the stored payload, the code that rebuilt it, the scheduled route back, and the access that could let the attacker begin again.

Our WordPress malware removal service covers the files, database, users, scheduled tasks, and likely entry point rather than stopping at the first alert. If you need help with one affected site, you can also request a one-off WordPress fix. Whichever route you choose, leave enough time after the cleanup to prove the site no longer rebuilds what was removed.

Quick answers about self-healing WordPress malware

Why does WordPress malware come back after its files are deleted?

Another part of the infection may still be able to recreate them. In the sites we examined, code loaded from WordPress configuration or an object-cache drop-in used payload data stored in the database, while scheduled hooks provided another way to restart the chain.

What is self-healing WordPress malware?

Self-healing is a practical description for malware with more than one persistence layer. A surviving database payload, loader, must-use plugin, drop-in, or scheduled task can restore another malicious component after it is removed.

Is every object-cache.php file malicious?

No. WordPress caching plugins and hosting platforms can install a legitimate object-cache.php drop-in. Check who installed it, compare it with a trusted copy, and review what the code does before removing it.

Is deleting suspicious WordPress transients safe?

Not by name alone. Transients are a normal WordPress feature, and deleting the wrong options may disrupt the site. Preserve a database backup and remove a row only when its value and relationship to the infection have been confirmed.

How do I know a WordPress malware cleanup worked?

Recheck the files, database, users, scheduled events, and logs after normal page requests and cron have run. The site should remain clean over time, with the original access route closed and affected credentials rotated after the malicious code is gone.

Originally published on BugShield.

Gravity Forms vulnerability puts hidden upload fields at risk

Sun, 20 Sep 2026 00:00:00 GMT

A critical Gravity Forms vulnerability can let somebody upload a dangerous file without logging in when a public form contains a hidden File Upload field. Versions up to and including 3.1.0.4 are affected. Update to the latest release now, then check the site if that form setup was publicly available.

Using Gravity Forms? Check the installed version and install the latest stable release available through your licence. Version 3.1.1 was the first fix for this flaw. Updating cannot tell you whether an earlier attack succeeded. Get your site checked

Gravity Forms vulnerability at a glance

The issue is tracked as CVE-2026-84434. Wordfence, which assigned the CVE, gives it a CVSS score of 9.8 out of 10. That Critical rating reflects a difficult combination for site owners: an attacker does not need a WordPress account, does not need an administrator to click anything, and may be able to place executable code on the server.

Detail	What site owners need to know
Affected versions	Gravity Forms 3.1.0.4 and earlier
First patched version	Gravity Forms 3.1.1
Release at original publication	Gravity Forms 3.1.2 at the time of publication
Severity	CVSS 9.8, Critical
Login required	No
Exploitation condition	A public form containing a File Upload field with Visibility set to Hidden

Why a hidden upload field became dangerous

A File Upload field normally checks what a visitor is trying to send before Gravity Forms keeps it. If the file type is not allowed, the submission should stop there. The official CVE record describes a gap between that validation step and the part of the plugin that finally saves the upload.

When the upload field's Visibility setting is Hidden, a rejected file can keep enough of its upload state to reach the saving process without being checked again. A visitor can therefore submit a file that the form was supposed to refuse. If the server will execute that file as code, the attacker may be able to take control of the website.

Hidden does not mean the field has disappeared from the form configuration. It means the field is not shown to an ordinary visitor. The server still receives the form submission, which is why hiding a field is never a replacement for checking what reaches the server.

Which Gravity Forms sites are exposed?

The plugin version matters, but it is not the whole picture. The disclosed route needs an affected version and a form that an unauthenticated visitor can reach. That form must also contain a File Upload field whose Visibility setting is Hidden.

A private form limited to logged-in users does not offer the same unauthenticated route. Nor does a form that has no hidden upload field. Even so, checking every old landing page before deciding not to update is the wrong trade-off. A forgotten form, shortcode, or embedded page is easy to miss, while installing the fixed version removes the known weakness from the plugin.

There is another reason not to wait. Patchstack marks the vulnerability as known to be exploited. That does not mean every exposed site has been attacked, but it does turn the update from routine housekeeping into work that should be handled now.

Update to Gravity Forms 3.1.1 or later

Update checked on 9th October 2026: the vendor changelog lists 3.1.3, released on 1st October with further security enhancements, followed by 3.1.3.1. Use the latest stable package available through your licence. The 3.1.1 minimum below describes this particular vulnerability.

Gravity Forms 3.1.1 is the first patched release. The vendor's official changelog lists security enhancements in 3.1.1, followed by another security-enhancement release, 3.1.2, on 17th September. At the time this article was published, 3.1.2 was the current version, so there is little reason to stop at the minimum fixed release.

Open Plugins > Installed Plugins, find Gravity Forms, and note the version before making a change. Take a current backup, install the latest update available through your Gravity Forms licence, and check the version again when WordPress says the update has finished. Then submit a test entry through each important form, especially forms that accept files or feed a payment, CRM, email, or automation service.

Gravity Forms describes version 3 as a major release and recommends sandbox testing when moving from version 2. If a site is still on the older branch, use a staging copy to catch compatibility problems, but do not let that turn into an open-ended delay. Ask the plugin vendor, your host, or a WordPress developer to help plan the move.

What to do if you cannot update immediately

The update is the proper fix. If it genuinely cannot happen today, reduce the exposed surface while somebody resolves the blocker. Take public forms containing hidden File Upload fields offline, or remove those fields from the published form. Restricting the whole page to authenticated users can also close the unauthenticated route described in the advisory.

A web application firewall may block a known malicious request, and Patchstack says it has issued a mitigation rule. Treat that as a temporary layer rather than evidence that the vulnerable code can remain. Rules differ between providers, plans, and configurations, while an installed update is much simpler to verify.

Updating closes the flaw, but it does not rewind the site

Once the update is installed, new attempts through this route should fail. What the update cannot do is remove a file that arrived beforehand. That distinction matters because the vulnerability may lead to remote code execution, giving an attacker room to add a backdoor somewhere else and return later.

The Gravity Forms file-upload documentation explains that uploads normally sit beneath a dedicated wp-content/uploads/gravity_forms/ area. It also describes an Apache configuration file intended to stop PHP running there. That is useful defence in depth, but server setups vary, upload paths can be changed, and the CVE still carries a Critical rating. It should not be used as a reason to skip the update or review.

If an affected version and the required form setup were public, the review should include:

unexpected executable files in Gravity Forms upload storage
recently added or changed PHP files elsewhere under wp-content
administrator accounts, plugins, themes, and must-use plugins nobody recognises
server access logs around unusual form submissions and direct requests to uploaded files
scheduled tasks, WordPress configuration, and credentials if compromise is confirmed

Do not delete the first unfamiliar file and assume the job is finished. Preserve enough evidence to understand when it appeared and what it did, then check the wider site. If you are not comfortable doing that yourself, ask your host or a security specialist to review it before logs rotate and useful evidence disappears.

A sensible response without the panic

CVE-2026-84434 deserves a prompt response, but a vulnerable version is not proof of a hacked website. Start with what you can establish: the installed version, whether a public form had a hidden upload field, and how long that combination was online. Update first, test the forms, and use that exposure to decide how urgently the site needs a deeper review.

BugShield can handle the update and form checks through our managed WordPress plugin updates. If the affected configuration was public, or the site already contains files and users you do not recognise, our WordPress malware removal service can investigate the files, database, users, and likely route into the site.

For a one-off job, request a WordPress fix. The important part is not whether you use BugShield or handle it with your existing developer. It is making sure Gravity Forms is genuinely beyond 3.1.0.4 and that an exposed site is not declared clean simply because the update button has been pressed.

Quick answers about the Gravity Forms vulnerability

Which Gravity Forms versions are affected by CVE-2026-84434?

Gravity Forms 3.1.0.4 and every earlier version are affected. Version 3.1.1 is the first patched release, and site owners should install the latest release available through their Gravity Forms licence.

Is every website using an affected Gravity Forms version exposed?

The disclosed unauthenticated route also needs a publicly accessible form containing a File Upload field with Visibility set to Hidden. Sites without that setup are not exposed through this specific path, but should still update.

Does an attacker need a WordPress account?

No. The vulnerability is unauthenticated, so an attacker does not need a subscriber, editor, or administrator login to target a suitable public form.

Is updating Gravity Forms enough after possible exploitation?

Updating closes the vulnerable upload route, but it cannot remove a malicious file or backdoor that may already be present. If the affected form setup was public, review the wider site after updating.

What should I check after updating Gravity Forms?

Check Gravity Forms upload storage and the wider wp-content directory for unexpected executable files, then review server logs, administrator accounts, plugins, themes, must-use plugins, and scheduled tasks for changes nobody recognises.

Originally published on BugShield.

Undetected WordPress malware, caught on day one

Fri, 11 Sep 2026 00:00:00 GMT

Most WordPress malware stories begin when something goes visibly wrong. Our latest one began with a customer who thought their website was fine. They had only just connected it to BugShield when our first checks raised a possible infection. A closer look confirmed it was undetected WordPress malware that had been sitting on their server for months.

The alert that changed the picture

There was no broken homepage or dramatic warning from a browser. The customer had been using their site without knowing anything was wrong, which is why the first result inside BugShield mattered so much. It did not say the site was definitely infected. It said there was a possible infection that needed attention.

The cautious wording is deliberate. WordPress sites contain thousands of files, and not every unfamiliar one is malicious. Developers add custom code, plugins generate files of their own, and old installations can accumulate all sorts of forgotten leftovers. A scanner can tell us where to look, but it takes an investigation to understand what has actually been found.

In this case, the warning held up. We reviewed the suspicious files in context, looked at what the code was doing, and confirmed malware. The more unsettling discovery came next: the infection was not recent. It had been on the server for months, sitting quietly behind a website that still looked normal.

We are keeping the customer, the website, and the precise file locations private. The useful part of this story is not who they are. It is how long a compromised site can continue to look perfectly ordinary.

A working website is not necessarily a clean website

When people imagine a hacked WordPress site, they usually imagine something they would notice straight away. Perhaps the homepage has been replaced, visitors are being redirected, or Google is showing a security warning. Visible symptoms do happen, but they are only the noisy end of the problem.

Malware can be much quieter. It might preserve a hidden way back into the server, wait for instructions, or only act when a particular visitor or search engine arrives. Some infections appear intermittently. Others hide inside familiar plugin or upload folders where one unusual file is easy to miss among thousands of legitimate ones.

From the customer's point of view, the site still loaded and the usual work could continue, so it felt healthy. In reality, a successful page load only tells you that one page worked for one visit. It says very little about the rest of the server, the database, administrator accounts, scheduled tasks, or hidden access an attacker may have left behind.

The scan found the clue. The investigation found the answer.

It would have been easy to treat the first alert as proof and rush straight to the word hacked. Calling the site hacked immediately might make a stronger notification, but it would not make a more accurate one. Security checks are most useful when they narrow the search without pretending to know more than the evidence shows.

The real work begins after the alert. A suspicious file needs to be compared with the software that should be there. Its location, contents, history, and behaviour all matter, along with everything around it. An infection may also involve unfamiliar administrators, altered database records, must-use plugins, scheduled jobs, or other files that were never included in the first warning.

Only after completing the review could we say the finding was genuine. The automated check created the opportunity to catch it; human judgement turned that signal into a confirmed problem we could act on for the customer. Neither part is very useful on its own.

Months of infection change what you can trust

Finding malware is bad enough. Learning that it has been present for months makes the response more involved, because the clean point you would normally return to may be much further back than expected.

Take backups. Restoring yesterday's copy feels like a sensible first move until you realise yesterday's copy probably contains the same infection. The same may be true of last week's and last month's. A backup is still valuable, but its date alone does not make it safe. It has to come from a point before the compromise, or be cleaned and checked before it goes back into service.

The trail also gets colder with time. Hosting logs are not always kept for months, and the change that first let an attacker in may now be buried beneath later updates. Even if the original weakness has since been patched, any backdoor planted before the patch can remain. Updating closes a known entrance; it does not automatically remove someone who is already inside.

Then there are credentials. If the incident reached beyond WordPress itself, changing a single administrator password is not enough. Hosting, SFTP, SSH, database, and other privileged access may all need to be reviewed. Credential changes should happen in a sensible order, after the routes into the site have been understood, so fresh credentials are not handed straight back to the same attacker.

Why deleting the flagged file is rarely the end

A malware alert naturally draws attention to the file named in the warning. Delete that file and the visible problem disappears from the scanner, but that does not tell you whether another copy exists or whether the attacker still has a way to recreate it.

A proper cleanup follows the infection through the site. It checks WordPress core, plugins, themes, uploads, must-use plugins, the database, administrator users, scheduled jobs, and server configuration. It also asks how the code arrived, closes that route where it can be established, and verifies the result before a fresh backup is treated as the new clean starting point.

Taking time over the cleanup helps prevent the familiar cycle where a site appears clean for a few days and the malware quietly returns.

If a malware warning appears on your site

The best response is calm and methodical. Do not ignore the warning because the website still works, but do not start removing unfamiliar files at random either. Both reactions can make the eventual investigation harder.

Preserve a private copy of the current site. Keep the files and database for investigation, while remembering that this is evidence and not a clean recovery point.
Have the warning reviewed in context. Confirm what the file is, what it does, and whether anything related has changed elsewhere in WordPress or on the server.
Trace and close the likely access route. Update or remove vulnerable software and review every privileged route into the hosting account and website.
Rotate the credentials that may have been exposed. Make the changes from a device and account you trust, once the environment is ready to protect the new details.
Verify the clean state. Rescan, compare files with trusted copies, test the important parts of the site, and only then create a fresh off-site backup.

Our manual WordPress malware guide goes further into the technical checks. If you would rather have a developer handle the investigation and cleanup, see WordPress malware removal.

What stays with us from this case

The timing is the part that stays with us. BugShield did not spend weeks watching the site before stumbling onto the problem. The warning appeared during the first checks, but the malware had already been there for months before the customer connected the site. Everything looked normal, so nobody knew there was anything to investigate.

Starting with a proper baseline matters. When monitoring begins, the first job is not simply to watch what changes tomorrow. It is to understand what is already there today. Otherwise, an old compromise can quietly become the starting point everyone assumes is safe.

Nobody wants to learn that their website has been infected. Finding out before the homepage breaks, visitors are redirected, or a search engine raises the alarm is still the better moment to discover it. A website does not need to look hacked to be hacked, but it also does not need to stay that way simply because the warning signs were quiet.

Do not wait for visible damage Shield Pro includes daily malware scans, ongoing monitoring, off-site backups, and malware investigation and cleanup when a confirmed infection needs attention. See Shield Pro protection

Quick answers about undetected WordPress malware

Can a WordPress site have malware and still work normally?

Yes. Some malware is designed to stay quiet, preserve hidden access, or affect only certain visitors. The homepage can keep loading while malicious code remains elsewhere in the files, database, user accounts, or scheduled tasks.

Why did the first alert say possible infection?

A scanner can identify an unusual file or pattern, but it cannot always understand the reason it is there. Calling the result possible gives a person time to review the file, its behaviour, and the surrounding site before confirming whether it is malware.

Can WordPress malware stay undetected for months?

It can. Malware that does not break the website or appear for every visitor may sit outside the owner's normal view for a long time. Regular checks create an opportunity to find it before a visible symptom brings the problem to everyone's attention.

Will deleting the flagged file remove the infection?

Not necessarily. The first file may be one part of a wider compromise, and another backdoor may recreate it. The investigation should cover the wider files, database, users, scheduled tasks, credentials, and the route the attacker may have used.

What should I do after a WordPress malware warning?

Keep a private copy for investigation and have the warning reviewed before deleting unfamiliar files. If malware is confirmed, clean the whole site, close the access route, rotate affected credentials, verify the result, and then create a fresh off-site backup.

Originally published on BugShield.

Elementor Pro 4.2.1 vulnerability: active attacks target file uploads

Thu, 03 Sep 2026 00:00:00 GMT

Elementor Pro 4.2.1 and every earlier version contain a critical file upload vulnerability that attackers are actively exploiting. If your site uses Elementor Pro, check the version now and update to 4.2.2 or a newer patched release. If an affected version was online after 19th August, check the site as well as updating it.

Still using Elementor Pro 4.2.1? Update to Elementor Pro 4.2.2 or a newer patched version first. If the site was exposed or anything looks unfamiliar, a security review can check whether somebody uploaded code before the update. Get your site checked

Elementor Pro 4.2.1 vulnerability at a glance

This is not a routine low-risk plugin warning. The vulnerability is tracked as CVE-2026-32475 and carries a CVSS score of 9.8 out of 10, which puts it in the Critical category. The fixed release is Elementor Pro 4.2.2.

Detail	What site owners need to know
Affected versions	Elementor Pro 4.2.1 and earlier
Patched version	Elementor Pro 4.2.2 or newer
Vulnerability	CVE-2026-32475, arbitrary file upload
Severity	CVSS 9.8, Critical
Login required	No WordPress account is required
Exploitation condition	A published Elementor Pro Form with at least one non-required File Upload field

What happened with Elementor Pro 4.2.1

Wordfence disclosed the vulnerability on 19th August 2026. According to its attack report, attackers began targeting websites on the same day. By 2nd September, the Wordfence firewall had blocked more than 190,000 exploit attempts.

That number is not the same as 190,000 compromised sites. It counts blocked attempts, and one website can receive many attempts. It still tells us something important: this is being used in the wild, not sitting quietly in a vulnerability database waiting for somebody to notice it.

Elementor released version 4.2.2 with the fix on 19th August. The safest response is to install that release or a newer patched version, then consider whether the site needs a closer check based on the conditions below.

How the file upload flaw works in plain English

Elementor Pro includes a Form widget that can accept files from visitors. Normally, the plugin checks each upload and rejects file types that should not be placed on the server. A mistake in the validation loop means that a specially arranged upload can make those checks stop too early.

The attacker places an empty item first and a second file after it. When the File Upload field is optional, the empty item can cause validation to end before Elementor checks the remaining file. That second file may then be saved with a dangerous extension such as .php.

A PHP file is code, not an ordinary image or document. If the attacker can request it from the web, they may be able to run commands on the server. Security teams call that remote code execution. For a WordPress owner, the practical meaning is simpler: somebody could take control of the site without first logging in.

Which Elementor Pro sites are exposed?

The disclosed attack path needs these conditions to line up:

Elementor Pro 4.2.1 or an earlier version is active.
A public page contains an Elementor Pro Form widget.
The form has at least one File Upload field.
That File Upload field is not marked as required.

If your site does not have that form configuration, this specific exploitation route should not be available. That is useful context, but it is not a reason to leave Elementor Pro 4.2.1 installed. Forms change, old landing pages are easy to forget, and updating removes the known weakness rather than relying on a page audit staying perfect.

The vulnerability is unauthenticated. An attacker does not need a customer account, an editor login, or a stolen administrator password. They only need to reach a suitable public form on an affected site.

What to do if you have Elementor Pro 4.2.1

Start with the update, then decide how far the review needs to go.

Check the installed version. Open Plugins > Installed Plugins and find Elementor Pro. If it shows 4.2.1 or anything earlier, treat it as affected.
Update to 4.2.2 or newer. Confirm the new version number after WordPress reports that the update has finished.
Test the site and its forms. Check the front end, send a test submission, and confirm any legitimate uploads still arrive where expected.
Review the exposure window. If an affected version was online from 19th August onwards and the site had a suitable upload form, arrange a security check rather than assuming the update tells you what happened before it was installed.
Remove Elementor Pro if it is no longer needed. An unused premium plugin should not remain forgotten on the server. Keep it updated if you need it, or remove it properly if you do not.

Signs that the Elementor Pro vulnerability was exploited

Wordfence says a successful attack writes an executable PHP file beneath /wp-content/uploads/elementor/forms/. That folder is intended for form uploads and should not contain PHP. Any .php file there is a strong warning sign and deserves investigation.

Your hosting provider can also review web server access logs for suspicious requests to /wp-admin/admin-ajax.php involving the Elementor Pro form submission action. Logs are useful, but the absence of a matching entry does not prove the site is clean. Logs may have expired, been rotated, or not captured enough detail.

Because successful exploitation can lead to full site control, the review should also cover:

administrator accounts that nobody on your team created
new or modified plugins, themes, and must-use plugins
unexpected scheduled tasks or changes to WordPress configuration
other recently changed PHP files outside the normal update window
hosting, database, SFTP, and administrator credentials if compromise is confirmed

Do not rely on the WordPress Users screen alone. A backdoor can exist without a visible administrator account. If you find an unfamiliar file, preserve enough information for somebody to investigate it before deleting everything around it.

Is a firewall enough protection?

A web application firewall can block a malicious upload before it reaches the plugin. Wordfence reports that its built-in Malicious File Upload protection blocks attempts against this vulnerability. It also recommends enabling its option that prevents code execution from the uploads directory.

That is useful protection, but it is not a replacement for the Elementor update. Firewall rules can be disabled, misconfigured, or absent from a different site. Updating to Elementor Pro 4.2.2 or later fixes the vulnerable code itself and gives you a much simpler state to verify.

How BugShield can help after the Elementor Pro 4.2.1 warning

Fast security updates are easier when somebody owns the routine. BugShield maintenance plans combine managed plugin updates with WordPress monitoring, off-site backups, and a secure record of the work completed on each site.

If you only need Elementor Pro updated and tested, you can request a one-off fix. If there are suspicious PHP files, unknown administrators, or other signs of access, choose WordPress malware removal so the review covers the wider site rather than stopping at the plugin version.

For most site owners, the immediate job is short: move beyond Elementor Pro 4.2.1, confirm the update, and check whether the affected form setup was publicly available while attacks were active.

Quick answers about the Elementor Pro 4.2.1 vulnerability

Which Elementor Pro versions are affected by CVE-2026-32475?

Elementor Pro 4.2.1 and every earlier version are affected. Version 4.2.2 contains the security fix, so install 4.2.2 or any newer patched release available through your Elementor account.

Does an attacker need a WordPress account?

No. The vulnerability is unauthenticated, which means an attacker does not need a customer, editor, or administrator login to target a suitable public Elementor Pro form.

Is every website using Elementor Pro 4.2.1 exposed to the reported attack?

The disclosed attack also requires a published page containing an Elementor Pro Form widget with at least one non-required File Upload field. Sites without that form setup are not exposed through this specific path, but should still update.

Is updating Elementor Pro enough after possible exploitation?

Updating closes the vulnerable upload path, but it does not remove a PHP file or backdoor that may already be present. If an affected form was public while attacks were active, review the site as well as installing the update.

What should I check after updating Elementor Pro?

Check wp-content/uploads/elementor/forms for unexpected PHP files, review server logs and unfamiliar administrator accounts, and look for plugin, theme, or configuration changes nobody on your team made.

Originally published on BugShield.

All-in-One WP Migration vulnerability: update to version 7.110

Wed, 02 Sep 2026 00:00:00 GMT

A recently disclosed All-in-One WP Migration vulnerability means sites using version 7.109 or earlier should update. The issue does not take effect simply because the plugin is installed. It depends on an attacker placing harmful data on the site, followed by an administrator exporting and restoring it. Version 7.110 closes the weakness.

Using All-in-One WP Migration? It is worth checking the installed version before your next migration or restore. Sites still using 7.109 or earlier should be updated to version 7.110 or the latest release available. See managed updates

What has happened

All-in-One WP Migration and Backup is a familiar tool for moving and restoring WordPress sites, with more than five million active installations. On 1st September 2026, Wordfence published details of a security weakness that could put those sites at risk if a particular export and restore sequence takes place.

Researcher Jack Taylor reported the issue to Wordfence on 14th August. The plugin developer, ServMask, then released version 7.110 on 20th August. That update is the important part for site owners because it fixes the problem in every version up to and including 7.109.

The vulnerability is recorded as CVE-2026-19949 and has a High severity score of 8.8 out of 10. Those labels help security teams track the issue, but you do not need to understand them to respond. The official WordPress.org plugin page confirms the change in version 7.110 and credits Taylor for reporting it responsibly.

What SQL injection means in plain English

To understand why the update matters, it helps to know what the flaw does. WordPress keeps posts, settings, users and other important information in a database. SQL is simply the language used to read and change that database. With a SQL injection flaw, information that should remain ordinary text can instead be treated as a command.

In this case, that does not happen straight away. The attacker first sends harmful information through a trackback, an older WordPress feature that notifies a post about an incoming link. The information can remain stored on the site until an administrator exports it and later imports the archive with the vulnerable plugin. During that restore, the plugin can mistake the stored text for a database command and run it.

Security researchers call this a second-order SQL injection because the information is stored first and becomes dangerous during a later action. The useful point for site owners is the order in which it happens: the harmful information is planted first, then a later export and restore can set it off.

Why the restore step matters

That extra restore step changes how this warning should be understood. The vulnerability is unauthenticated, which means an attacker does not need a WordPress account to place the harmful information. Even so, simply having the plugin installed does not give somebody immediate control of the site.

The attack only moves to its next stage when an administrator exports the site and imports the resulting archive. Because those are normal actions for a migration plugin, the condition cannot be ignored, but it does help explain which sites may need a closer review.

If the full sequence succeeds, the attacker may obtain a private key used by the plugin and use it to make the server run code of their choosing. In practical terms, that could give them control of the WordPress site.

Who needs to update

Although the attack relies on that sequence of events, the update advice is straightforward. Any site with All-in-One WP Migration and Backup 7.109 or earlier should move to a fixed release, even if the plugin has not been used recently or there is no migration planned.

Open Plugins > Installed Plugins in WordPress and find All-in-One WP Migration. The installed version appears with the plugin details. If it shows 7.109 or an earlier number, update it to 7.110 or the latest version available.

A firewall may provide another layer of protection, but updating remains the more dependable response because it removes the known weakness from the plugin itself.

What site owners should do now

If version 7.110 or later is already active and the plugin was not used for a recent export and restore, there is unlikely to be anything more to do for this specific issue. Otherwise, work through these steps in order:

Check the plugin version. Look under Plugins > Installed Plugins for All-in-One WP Migration and Backup.
Update to version 7.110 or later. Confirm the new version number after the update finishes.
Update before exporting or restoring. If you cannot update immediately, do not use an older version for another migration or restore.
Review any recent migration or restore. If an administrator exported and imported the site while version 7.109 or earlier was active, a security review is sensible. This does not mean the site was attacked, only that the sequence needed for the vulnerability took place.
Remove unused copies. If the site no longer needs the plugin, remove it instead of leaving an old version installed and forgotten.

What to check after a recent restore

A recent restore with an affected version is a reason to check the site, not proof that it was compromised. The review becomes more worthwhile if public posts accepted trackbacks before the archive was created. Updating closes the vulnerable route, while the review checks whether anything happened before that update.

That review should bring the main signs of unexpected access together:

administrator accounts you do not recognise
plugins and must-use plugins that nobody on your team installed
unexpected file changes around the time of the restore
security and server logs showing unusual activity
hosting, WordPress and database credentials if there are signs of access

If something unfamiliar appears, avoid deleting it until somebody has checked what it is. Removing the wrong file can break the site or make an investigation harder. A full WordPress malware review can check the files and database together.

How BugShield handles plugin security updates

Keeping plugins current is easier when it is part of the site's regular care. On BugShield maintenance plans, a developer can review the release, apply it and check the site afterwards through our managed plugin updates. This works alongside site monitoring and off-site cloud backups.

If you are not on a maintenance plan and would like help updating or checking a recent restore, you can request a one-off WordPress fix. If there are already signs that somebody gained access, choose WordPress malware removal so the investigation covers more than the plugin version.

For most site owners, this comes back to one practical step: make sure All-in-One WP Migration is on version 7.110 or later before the next export or restore.

Quick answers about the All-in-One WP Migration vulnerability

Which versions of All-in-One WP Migration are affected?

If your site is using All-in-One WP Migration and Backup 7.109 or earlier, it is within the affected range. Updating to version 7.110 or any newer release offered through WordPress will apply the security fix.

Does an attacker need a WordPress account?

An attacker does not need a WordPress account to place the harmful data. However, the disclosed attack only reaches its final stage after a site administrator exports and then imports the site using a vulnerable version of the plugin.

Is my site safe if I have not restored an archive?

Without an export and restore, the harmful database command described by Wordfence is not triggered and this particular attack chain cannot be completed. Updating is still important because it prevents a future migration or restore from activating stored harmful data.

What should I do if I use All-in-One WP Migration?

Start by updating the plugin to version 7.110 or later and checking that the new version is active before creating or restoring another migration archive. If you recently completed a restore with version 7.109 or earlier, a security review is also sensible.

Should I remove the plugin after updating it?

If your site still uses All-in-One WP Migration, you can keep it once the fixed version is active. If the plugin is no longer needed, removing it leaves one less piece of software to maintain and update.

Originally published on BugShield.

Wishlist Member account takeover: unauthenticated mergewith bug in 3.34.1

Fri, 14 Aug 2026 00:00:00 GMT

Wishlist Member account takeover is possible without logging in on WishList Member X through 3.34.1. Wordfence reports that a mergewith parameter can be pointed at a WordPress user the attacker does not own. If that user is an administrator, they own the site. Update first. Then look at who is on the Users screen.

Running WishList Member? Update the plugin first. If you cannot install 3.34.2 or a newer patched release, or the site already has mystery admins, we can do a full WordPress malware removal from £99.99. Get your site checked

What this Wishlist Member account takeover actually is

WishList Member is a commercial membership plugin. Course sites, coaching programmes, and paid communities use it to gate content and take payments. If it is installed, it is usually doing the money part of the site, not sitting unused in a forgotten folder.

Wordfence published an advisory titled Wishlist Member X 3.34.1: unauthenticated account takeover via the mergewith parameter . Their naming matches the rest of the WishList Member X intel list : versions up to and including 3.34.1 are in scope. Unauthenticated means the attacker does not need a membership, an admin session, or a stolen password. Reaching the site is enough.

In plain English: the plugin can connect a new registration or payment to an existing WordPress account, avoiding the creation of a duplicate user. That connection is what mergewith is designed to handle. The bug is that the plugin trusted that value without proving the requester owned the target account. Point it at the wrong user and you are sitting in their session. Point it at an administrator and the site is gone.

We will not include the technical request details here. To protect your site, update the plugin and review your WordPress users for any accounts or changes you do not recognise.

Who is at risk

If WishList Member (WishList Member X) is active and the version is 3.34.1 or older, treat the site as in scope. Check Plugins > Installed Plugins, or the version string inside the WishList Member screens. Premium plugins often update from the vendor, not from wordpress.org, so “I click Update All on Tuesdays” is not a guarantee this one moved.

This is worse than “a subscriber can be annoying.” The May 2026 WishList Member bugs ( CVE-2026-6419 , CVE-2026-6895, and neighbours) needed a Subscriber-level login first. This one does not. Open registration is not a prerequisite. A membership paywall does not save you. The public front of the site is the front door.

Two extra gotchas that matter on real membership sites:

Levels can map to WordPress roles. WishList Member can assign a WordPress role when someone joins a level. If any level grants Administrator (or even Editor), a taken-over member account is not “only” a content leak. It is wp-admin.
Duplicate-account handling is a feature, not a hidden switch. The vendor documents preventing duplicate shopping cart registrations and letting existing members add a level without a second login . That is legitimate product behaviour. The vulnerability is the unauthenticated abuse of the parameter that glues those flows together, not the idea of merging itself.

How the mergewith bug fits together

You do not need an exploit write-up. The shape is enough, and it is the same shape we keep seeing in membership plugins.

A public flow accepts a user identifier. Registration, a payment return, or a related front-end request includes a mergewith value that names an existing WordPress user.
The plugin does not prove you own that user. No login. No capability check that would stop a stranger. The value is trusted.
Accounts get glued together, or the attacker is treated as that user. Membership levels, profile data, and the WordPress role travel with the account.
Aftermath. From an administrator session the rest is ordinary: new admin users, plugin ZIPs, must-use droppers, wp-config.php in someone’s pocket. Same cleanup story as the BdThemes supply chain mess last week, minus the poisoned JSON.

If that last stretch sounds adjacent to WordPress XSS2Shell, it is only from a site-owner point of view: security issue published, patch available or imminent, do not wait for a quiet Sunday. XSS2Shell started on wp-login.php. The WordPress 7.0.4 Postscript bug started in the Media Library. This one starts in the membership plugin you installed on purpose.

This plugin has had a rough year

WishList Member is not a one-CVE product. In May, Wordfence disclosed a cluster of High issues through 3.30.1 where a Subscriber could pull or rotate the plugin’s REST API secret, create a membership level mapped to Administrator, and register a new admin. Patches landed in 3.31.x. The wlm3_export_settings advisory is the readable one if you want the older chain in one place.

3.33.0 (June) had a Security section in the vendor changelog : tighter payment notifications, team and API access, login and profile hardening. 3.34.0 (6th July) hardened secrets used by some payment integrations. None of that is a reason to assume 3.34.1 is fine. A later unauthenticated account takeover means those earlier fixes did not cover this path.

The advisory identifies CVE-2026-12949 and confirms 3.34.2 as the first patched release. Install the latest patched version available through your WishList Member account. If Dashboard > Updates does not offer it, check the licence connection and obtain the package from the vendor. The WishList Member changelog records subsequent releases.

What to do about this Wishlist Member account takeover today

Update WishList Member to the latest patched release from the vendor; 3.34.2 is the first version containing this fix. Confirm the version under Plugins > Installed Plugins, or inside WishList Member itself. If the plugin is inactive but still installed, update or delete it. Inactive is not the same as gone, and leftover copies get forgotten.
Audit WordPress users. Users > All Users. Sort by registered date. Look at Administrators first, then anyone with a role you did not assign. WP-CLI is the honest view if you have SSH: wp user list --role=administrator. The dashboard can lie after a takeover. See managing WordPress user roles if you need a refresher on what each role can actually do.
Look at membership levels and role maps. In WishList Member, check which levels grant a WordPress role. A “Gold” level that quietly assigns Administrator is a loaded gun even after the plugin is patched. Change that mapping. Then re-check the Users screen.
Reset remaining admin passwords and turn on two-factor authentication. Reset the admin password, then enable WordPress 2FA. If you also keep site credentials in BugShield, the same habit applies to our own 2FA and Active Sessions.
If you were late: review unexpected plugins (including mu-plugins), Application Passwords, and new users from the last few weeks. For a proper pass, see WordPress malware removal and Fixing a Hacked Site.
Take a clean backup after you patch, so you are not rolling back onto a known-bad plugin build. Managed backups exist so that step is not a ZIP on someone’s laptop.

How to tell if someone already used it

There is no magic log line labelled “mergewith attack.” Look for the residue instead.

Administrator accounts you did not create, especially recent ones with throwaway emails
Existing admins whose email or password suddenly “stopped working” for the real owner
Members who gained a WordPress role they never had
Plugin folders you did not install, and anything under wp-content/mu-plugins
Payment or registration traffic that does not match real customers

Unknown does not mean safe. If WishList Member was on 3.34.1 or older and exposed to the internet, do the user audit even if the dashboard looks calm. File integrity tools will not catch an account takeover. The files can be clean. The Users table is where this one lives first.

If anything on that list shows up, stop poking at random files. Half-cleaning a backdoor is how it comes back next week. The work is the same as our hacked WordPress site case study : files, database, and the entry point. Deleting one user and hoping is not that.

Wishlist Member account takeover and BugShield

Premium membership plugins are easy to leave a version behind. The update is not in the wordpress.org button. It sits in a vendor account someone last logged into in 2024. That is how a site stays on 3.34.1 while the advisory is already public.

On Shield plans we treat plugin updates as part of managed updates, next to monitoring and backups. That includes commercial plugins when we have the licence in the Password Vault. Shield Pro adds malware scanning when you need a second pair of eyes on files after a scare. Broader reading: website security and WordPress security in the knowledge base.

If you only need this one plugin updated, or the site already looks compromised, request a one-off fix or go straight to malware removal. August has been busy enough without leaving a membership plugin as the unlocked door.

Install the latest patched WishList Member release, with 3.34.2 as the minimum for this flaw. Then review who can still log in as administrator. That is the whole job for most sites today.

Quick answers about WishList Member security

Which WishList Member versions are affected?

WishList Member X 3.34.1 and earlier are affected by CVE-2026-12949. Version 3.34.2 is the first patched release. Install the latest patched version from the vendor and confirm the installed version inside WordPress or the plugin's own settings.

Does an attacker need a member account to use this bug?

No. The vulnerability is unauthenticated, so an attacker does not need a membership, an existing login or a stolen password to target the site.

What if WishList Member is installed but inactive?

Do not leave an old copy forgotten on the server. Update it if you plan to use it again, or remove it if the site no longer needs it.

How can I tell whether someone took over an account?

Look for unfamiliar administrators, unexpected role changes, new plugin folders, must-use plugins and registration or payment activity that does not match real customers. Check the database or WP-CLI as well as the WordPress Users screen if you can.

Is updating the plugin enough after a suspected compromise?

Updating closes the vulnerable path, but it does not remove accounts or files that may already have been added. If anything looks unfamiliar, the site needs a proper review of its users, files, database and access credentials.

Originally published on BugShield.

WordPress 7.0.4: Author-level Postscript upload RCE (CVE-2026-65640)

Wed, 12 Aug 2026 00:00:00 GMT

WordPress 7.0.4 fixed a High severity core bug (CVE-2026-65640) that allowed a user with upload permission to turn a crafted Postscript upload into code execution when Imagick and Ghostscript were present. That was the original patch. Install current WordPress security updates, then review who can upload media.

Keep security updates current Update WordPress first. If the site already looks odd after an Author-level account went sideways, we can do a full WordPress malware removal from £99.99. Get your site checked

What WordPress 7.0.4 fixes

WordPress published GHSA-8vr3-7mxf-gx8w on 12th August 2026. The CVE is CVE-2026-65640. CVSS 8.8 (High). CWE-434: unrestricted upload of a dangerous type.

In plain English: on some hosts, WordPress will process a Postscript file that an Author uploads through the Media Library. Imagick hands that file to Ghostscript. Ghostscript has a weakness in how it handles certain embedded files. That is where remote code execution comes from. WordPress is the front door. Ghostscript is the room the payload reaches.

The fix shipped in WordPress 7.0.4, and as usual the WordPress security team backported it all the way to the 4.7 branch. You do not need to jump to 7.x to be patched. You do need the matching security release for whatever major you are on.

Credit for the disclosure goes to the team at pwn.ai.

Who is at risk from this WordPress 7.0.4 CVE

Two conditions have to line up. Miss either one and this particular path does not fire. That is not a reason to skip the update.

Imagick and Ghostscript on the server. Plenty of managed WordPress hosts ship both so image and PDF handling “just works.” Shared hosts and VPS images do the same. If you are not sure, ask the host whether ImageMagick (Imagick PHP extension) and Ghostscript are installed.
A user with the upload_files capability. On a default WordPress role map, that means Author and above: Author, Editor, Administrator. Contributor does not get Media Library uploads by default. Custom roles and membership plugins often add upload_files to “trusted” customers. Treat those the same as Authors for this advisory.

This is not an unauthenticated drive-by. Someone needs a legitimate (or stolen) Author-level account, or any account that can upload media. That still leaves a large blast radius: guest writers, agencies with shared Author logins, old contractor accounts nobody revoked, and any plugin that quietly grants upload rights.

If that sounds adjacent to WordPress XSS2Shell, it is the same family of problem from a site-owner point of view: core bug, security release out, update now. The mechanics differ. XSS2Shell started on the login page. This one starts in the Media Library.

How the Postscript upload RCE fits together

You do not need an exploit walkthrough to defend the site. The shape is enough.

Upload. A user with upload_files adds a malicious Postscript file through the normal media flow WordPress already allows.
Server-side processing. With Imagick available, WordPress (or the image stack around it) asks Ghostscript to handle Postscript content.
Ghostscript weakness. Certain embedded files inside that Postscript are handled badly. That is the RCE step. It runs as the same system user PHP runs as, often www-data.
Aftermath. From there an attacker can plant PHP, read wp-config.php, create admin users, or drop must-use plugins. Same cleanup story as any other webshell.

WordPress called out “certain installations.” That is the Imagick + Ghostscript prerequisite, not a vague “maybe you are fine.” If both are present and you still have unpatched core, assume you are in scope.

Patched versions for WordPress 7.0.4 and the backports

WordPress 7.0.4 was the first fix on the 7.0 branch for this specific vulnerability. The versions below record that original patch, not the releases to stop at today:

7.0.x: 7.0.4
6.9.x: 6.9.7
6.8.x: 6.8.8
6.7.x: 6.7.7
6.6.x: 6.6.7
…and the same pattern back through 4.7.35

Full affected and patched lists are in the GitHub advisory. If Dashboard > Updates offers a security release, take it. Do not wait for a “convenient” maintenance window if Authors can already upload.

What to do about WordPress 7.0.4 today

As checked on 9th October 2026, the WordPress 7.1.3 security release includes additional fixes. Use the latest available release rather than installing 7.0.4 as a final destination. Only the latest WordPress release is actively supported; older security backports do not promise continuing support.

Update WordPress to the newest release available for your installation, then confirm it under Dashboard > Updates. The original 7.0.4 fix does not include later security patches.
Audit who can upload. Users > All Users. Look for Authors, Editors, and any custom role with Media Library access you forgot about. Remove accounts that no longer need a login.
Review recent media. Especially Postscript / EPS-style uploads from the last few weeks if you have Author accounts you do not fully trust. Delete anything you did not expect.
If you were late: review Administrator users, unexpected plugins (including mu-plugins), and Application Passwords. Change passwords for remaining admins. For a proper pass, see WordPress malware removal and Fixing a Hacked Site.
Take a clean backup after you patch, so you are not rolling back onto a known-bad core build.

Hosting notes: Imagick, Ghostscript, and hard choices

Some teams will ask whether they should remove Ghostscript or disable Imagick. That can reduce exposure to this class of bug, and it can also break PDF thumbnails, EPS handling, and other media features your editors rely on. Patching WordPress is the first move. Server-side surgery is a second conversation with whoever runs the stack.

If you manage your own VPS, our WordPress server setup checklist is the place to keep “what image tools are installed” written down, not guessed under pressure.

WordPress 7.0.4 and BugShield

Core security releases are the boring kind of urgent. On Shield plans we apply WordPress updates as part of managed updates, next to monitoring and backups. Shield Pro adds malware scanning when you need a second pair of eyes on files after a scare.

If you only need this one patch handled, or the site already looks compromised, request a one-off fix or go straight to malware removal. And if you are still catching up on last week’s core issue, the XSS2Shell post and free XSS2Shell checker are still worth a pass. August has been busy.

Install current WordPress security updates, then review who can upload files and investigate any evidence of misuse. An update closes the flaw; it cannot establish whether the site was compromised before the fix.

Quick answers about WordPress 7.0.4

Which WordPress sites are exposed to CVE-2026-65640?

The vulnerable path needs Imagick and Ghostscript on the server, plus a WordPress user who can upload files. On a default site that includes Authors, Editors and Administrators, although custom roles may also have upload access.

Do I need to move to WordPress 7.0.4 if my site uses WordPress 6.x?

The original fix was also backported to older branches, so 7.0.4 was not the only patched version. Those historical patches are not current update targets. Install the latest available WordPress release, testing compatibility first.

Can a Contributor exploit the Postscript upload issue?

Contributors cannot upload media on a default WordPress installation. Check any custom roles or membership plugins, because they may grant the upload_files capability to users who would not normally have it.

Should I remove Imagick or Ghostscript from the server?

Patch WordPress first. Removing either tool may affect PDF thumbnails, EPS handling and other media features, so discuss any server change with the person who manages your hosting.

What should I review after installing the security update?

Check who can upload files, review recent media, and look for unfamiliar administrators, plugins or Application Passwords. Once you are comfortable the site is clean, take a fresh backup of the patched version.

Originally published on BugShield.

WordPress plugin supply chain attack: BdThemes plugins created rogue admins

Wed, 12 Aug 2026 00:00:00 GMT

A WordPress plugin supply chain attack hit BdThemes in August 2026. The plugin files on WordPress.org stayed clean. A promotional JSON feed did not. When an administrator signed in, the compromised feed could create additional administrator accounts without their knowledge. If you run Element Pack, Prime Slider, or another BdThemes plugin, check the site even if nothing looks wrong.

Using a BdThemes plugin? Cleaning the vendor feed does not clean a site that already got a hidden admin or webshell. If you would like a developer to investigate, BugShield offers WordPress malware removal from £99.99. Get your site checked

What a WordPress plugin supply chain attack actually is

Most people picture a supply chain attack as “someone uploaded a bad plugin update.” That does happen. A ZIP on WordPress.org gets swapped, sites auto-update, and the malware arrives with a version bump.

The BdThemes case is the other flavour, and it is worse in one specific way. Nothing in the plugin repository had to change. The plugins already trusted a remote promotional feed. Attackers poisoned that feed. Every time a logged-in admin opened wp-admin, the dashboard fetched the poisoned JSON and ran attacker JavaScript in the admin’s own browser session.

You did not click a phishing link. You did not install a random ZIP from an email. Logging into wp-admin was enough. That is why this WordPress plugin supply chain attack spread quietly.

What happened with BdThemes

BdThemes makes Elementor add-ons a lot of sites already have installed: Element Pack, Prime Slider, Pixel Gallery, Ultimate Post Kit, Ultimate Store Kit, plus a couple of smaller tools. Element Pack alone sits north of 100,000 active installs on WordPress.org.

Those plugins share a banner component (researchers call it Biggopti) that pulls “summer sale” style notices from a vendor API. The API was not a clever application server. It was static JSON in object storage, sitting behind Cloudflare. Someone got write access to that bucket and replaced the legitimate notices with a payload.

Wordfence was notified on 7th August 2026 after seeing the traffic in the wild. The WordPress Plugins team then closed the affected listings pending review. By 8th August the poisoned endpoints were serving clean JSON again. BleepingComputer has a useful news round-up if you want the timeline in one place.

Cleaning the feed is not the same as cleaning your site. Anything planted between late June and 8th August is still there until someone looks.

Which plugins were in the blast radius

If any of these are installed, treat the site as in-scope. Free or premium does not matter. The banner code is what mattered:

Element Pack Addons for Elementor (bdthemes-element-pack-lite)
Prime Slider Addons for Elementor (bdthemes-prime-slider-lite)
Pixel Gallery Addons for Elementor (pixel-gallery)
Ultimate Post Kit Addons for Elementor (ultimate-post-kit)
Ultimate Store Kit (ultimate-store-kit)
Live Copy Paste for Elementor (live-copy-paste)
Smart Admin Assistant (smart-admin-assistant)

Wordfence scored the underlying XSS as medium (CVSS 5.4) and listed it as unpatched when they published. That sounds mild until you remember where it ran: inside an already-authenticated administrator session, on every wp-admin page load.

How the attack created rogue WordPress admins

You do not need to understand every technical detail to protect your site. The important part is knowing how the attack reached WordPress and what it changed.

A coding gap in the banner. A field from the remote JSON was dropped into an HTML id attribute without escaping. That bug landed in March 2026. Later releases sanitised the banner body and still left the id open.
Poisoned JSON instead of a plugin update. With write access to the vendor bucket, attackers did not need to touch WordPress.org. The next admin page load fetched their payload.
JavaScript in your admin session. The script used the logged-in administrator’s own nonce to create a new Administrator user. One variant used predictable usernames starting with bd_ and an @wordpress.org email. Another hid the new account from the Users screen.
A fake plugin, then a backdoor. A ZIP with a boring name (researchers saw things like wp-smart-thumbnails) landed through the normal plugin uploader. Inside it: a webshell. That then dropped must-use plugins for persistence, including a magic-login style backdoor.

If that last stretch sounds familiar, it should. WordPress XSS2Shell is a different bug, in WordPress core, but the idea is the same: XSS in an admin context is how you turn “a script on a page” into “they own the site.”

Why file scans missed this WordPress plugin supply chain attack

Integrity checkers compare plugin files with WordPress.org. These files matched. No update was required. No file on disk had to change for the first stage to fire.

That is the part that should make site owners sit up. A lot of “we are fine” habits assume malware arrives as a dirty PHP file. Here the first stage lived in a JSON response the plugin asked for on purpose. File hashes stay green. The Users list can stay green too, because one of the persistence modules hooked database queries and hid the rogue accounts.

If you only glance at Dashboard > Users, you can miss the whole thing. Check the database, or use WP-CLI, or look at the wp_users table from the host. Do not trust the screen that the malware was written to lie to.

How to check your site after the BdThemes incident

Wordfence’s earliest possible campaign date is 23rd June 2026, based on timestamps in the poisoned notices. The feed was clean again on 8th August. If a BdThemes plugin was active in that window, and an administrator used wp-admin, do this checklist. None of it needs a scanner licence.

1. Look for users you did not create

Hunt for Administrator accounts you do not recognise, especially:

Usernames starting with bd_ followed by six letters or numbers
Emails on @wordpress.org or @developer.wordpress.org that you did not add
Admins that appear in the database but not in wp-admin

WP-CLI is the honest view: wp user list --role=administrator. If you do not have SSH, phpMyAdmin or your host’s database tool works. Sort wp_users by user_registered and look at anything from late June onwards.

2. Look at plugins, including ones you never activated

Folders you did not install, with friendly names like wp-smart-thumbnails
A file named emer-run.php anywhere under wp-content
Must-use plugins under wp-content/mu-plugins, especially names like class-wp-token-validate.php, class-wp-query-*.php, or wp-cache-optimizer.php

Must-use plugins load automatically. They do not show up in the normal Plugins screen the way a regular plugin does. If you never use that folder, it should be empty or only contain what you put there.

3. Check the options table

Researchers flagged two database options used as compromise flags: fz_emer_login_tokens and fz_emer_done_v1. If either exists, treat the site as compromised even if the dashboard looks calm.

4. Do not stop at “the plugin is closed now”

WordPress.org closing the listing stops new installs. It does not uninstall the plugin, and it does not remove a backdoor that already landed. Same for the cleaned API. That only stops new infections from this particular feed.

What to do if you find a rogue admin or webshell

If anything on that list shows up, stop poking at random files. Half-cleaning a backdoor is how it comes back next week.

Take a backup of the current mess before you delete anything, so a cleaner can still see what was there. Then keep it off the public site.
Remove the rogue users from the database, not only from the Users screen. Reset passwords for every remaining Administrator. Rotate hosting, FTP, database, and application passwords too. The Password Vault exists so you are not doing that over email.
Delete the fake plugin and any must-use droppers. Search the whole wp-content tree for emer-run.php, not just the plugins folder.
Clear those database options if they are present, after you have a copy.
Review who is still signed in. WordPress sessions, application passwords, and any “magic login” style URL the backdoor used. Our own 2FA and Active Sessions post is about the BugShield account, but the habit is the same: a strange session is a warning, not the whole cleanup.

If that already feels like a lot, it is. This is the job in Fixing a Hacked Site, and it is the same work we did in the hacked WordPress site case study. A proper malware removal pass covers files, the database, and the entry point. Deleting one user and hoping is not that.

This keeps happening

BdThemes is not a one-off mood. The same few months brought CDN and update-flow compromises against other well-known WordPress products, including OptinMonster . Wordfence tied the command-and-control used here to the same actor behind that campaign and the Advanced Responsive Video Embedder incident.

The pattern is getting boring, which is the problem. Popular plugins talk to vendor APIs for licence checks, banners, changelog nags, and “news.” Those requests look legitimate. They use HTTPS. They come from a domain the plugin author owns. File integrity tools are not watching that JSON.

So a WordPress plugin supply chain attack no longer has to mean “the ZIP on WordPress.org went bad.” It can mean “the plugin phoned home, and home was having a worse day than you were.”

What we take from it at BugShield

No platform can guarantee that a vendor’s external systems will never be compromised. A popular plugin and a normal-looking dashboard should not stop us from investigating when new security information appears.

On Shield plans, managed plugin updates are not “click Update All and leave.” They sit next to monitoring, backups, and a human who can check users and mu-plugins when a campaign like this lands. Shield Pro adds malware scanning on top. If you only need the cleanup, request a one-off fix or go straight to malware removal.

If you ran a BdThemes plugin this summer, do the user and mu-plugins check today. The feed is clean. That does not mean the site is.

Quick answers about the BdThemes attack

Which BdThemes plugins were linked to this supply chain attack?

The reported list includes Element Pack, Prime Slider, Pixel Gallery, Ultimate Post Kit, Ultimate Store Kit, Live Copy Paste and Smart Admin Assistant. Free and premium editions should both be checked where the shared banner code was present.

Were the plugin files on WordPress.org infected?

The first stage came from a poisoned promotional JSON feed rather than a changed plugin ZIP. That is why a normal file integrity check could show clean plugin files while an administrator's browser still received the malicious script.

Does a clean vendor feed mean my site is safe now?

No. Cleaning the feed stops that route from delivering new payloads, but it does not remove a rogue administrator, fake plugin or backdoor that was already added to a site.

What signs of compromise should I look for?

Check for administrators you did not create, especially usernames beginning with bd_, unfamiliar plugin folders, unexpected files under wp-content/mu-plugins, and the database options named in the article. Use the database or WP-CLI if the Users screen looks incomplete.

What should I do if I find a rogue administrator or webshell?

Keep a secure copy for investigation, then arrange a full cleanup of the users, files, database and original entry point. Reset administrator passwords and rotate hosting, database and other site credentials as part of that work.

Originally published on BugShield.

WordPress XSS2Shell: what it is, who is at risk, and how to check

Sat, 08 Aug 2026 00:00:00 GMT

WordPress XSS2Shell (CVE-2026-64638) is the kind of WordPress bug you want closed the same day it lands: XSS on the login page that can stretch into remote code execution if an admin gets pulled into the chain. Here is what it is, who is at risk, how to check your site, and what to do next. Our customers get WordPress security updates applied quickly. This post shares the same steps for everyone else.

Free WordPress XSS2Shell checker Check the public login-page response for XSS2Shell behaviour, with version detection as a fallback. Open the XSS2Shell checker

What WordPress XSS2Shell is

WordPress XSS2Shell is built into WordPress itself, not a random plugin problem. That is the uncomfortable part. Default WordPress installs were in scope. You did not need a shady extension sitting next to WooCommerce for this one to apply.

It starts on the ordinary login screen at wp-login.php. Someone posts a username that does not exist. WordPress helpfully puts that username into the error message. With the right payload, enough dangerous markup survives the first clean-up and later gets treated as allowed HTML. Your browser then renders attacker-controlled elements on a page that still looks like your site’s login page.

That alone is XSS in the WordPress origin, which is already bad. The research that named XSS2Shell went further. If a logged-in administrator walks into the trap, an attacker can create an Application Password as that admin, talk to the REST API, upload a plugin ZIP, and run PHP as the web server user.

When people write “full remote code execution on the underlying server,” this is what they mean. Usually that shell is www-data (or whatever user PHP runs as on your host). That is enough to read wp-config.php, dump the database, and plant a backdoor that is easy to miss.

Who is at risk from WordPress XSS2Shell

Anyone still on an unpatched WordPress build when this shipped. The XSS piece does not need a WordPress account. Getting all the way to RCE does need an admin session in the mix, usually through a phishing link while someone is already signed into wp-admin.

An attacker still needs an administrator to interact with the malicious page, but that does not make the issue harmless. Admins click links, shared logins are common, and office laptops often stay signed in. These everyday habits make the risk realistic, so make sure your site is running a patched WordPress version.

How the WordPress XSS2Shell attack works

You do not need the full research write-up to defend yourself. This is the shape of it:

Failed login XSS. An attacker submits a crafted username to your login page. WordPress reflects it into the error UI.
Attacker code on your login page. The injected markup works with WordPress’s own scripts, so malicious JavaScript runs under your domain.
Admin API access. If an administrator hits the trap while logged in, an Application Password can be created and handed to the attacker.
Plugin upload, then PHP. With that access, a ZIP lands under wp-content/plugins. Those PHP files are reachable even if nobody clicks Activate.

The takeaway is simple: skip WordPress updates, and you leave that first door on the latch.

What to do about WordPress XSS2Shell today

Update WordPress to the newest release available for your installation. Version 7.0.3 was the first fix on that branch for XSS2Shell, not a current update target. Take a backup and arrange prompt testing and installation of the update.
Confirm what is actually running. Check Dashboard > Updates or the admin footer. Caches and managed WordPress panels sometimes tell a happier story than the files on disk. Or use our free WordPress XSS2Shell checker.
If you were late to the update, do a quick tidy: revoke Application Passwords you do not recognise, glance at Administrator users, and peek under wp-content/plugins for folders you never installed. Change admin passwords if anything feels off. If you want a proper cleanup rather than a DIY scan, our WordPress malware removal service covers that.
Take a clean backup after you patch, so a later cleanup does not restore from a copy made while things were still messy.

Patched WordPress versions for XSS2Shell

WordPress fixed XSS2Shell in 7.0.3 and pushed the fix back through maintained branches to 4.7. Sitting on 6.8 or 6.9 is not enough. You need the patch level for that branch.

These are historical minimums for XSS2Shell. Later releases fix additional vulnerabilities, including the WordPress 7.1.3 security release. Install the latest available release. Original patch examples:

7.0.x: 7.0.3
6.9.x: 6.9.6
6.8.x: 6.8.7
6.7.x: 6.7.6
Older maintained branches continue down to 4.7.34

The full table is on the WordPress XSS2Shell checker. If your host manages WordPress updates, it is still worth confirming that the latest security release has been installed.

Free WordPress XSS2Shell checker

The free checker sends a non-destructive failed-login probe and looks for the response associated with this flaw. It uses a publicly detected WordPress version as a fallback. Only check websites you own or have permission to assess.

The check does not sign in, create users, upload plugins or execute the later remote-code attack. A result indicating no detected vulnerability applies only to this specific check. It cannot prove that the website is free of other vulnerabilities or that a past compromise never occurred.

What “Unknown” should mean to you

An Unknown result means the check did not produce a usable answer. A firewall, hidden login address or connection failure can prevent completion. Confirm the installed version under Dashboard > Updates, or ask your host to verify it. A missing result is not evidence that the site is protected.

After you patch: a short compromise checklist

If the site sat unpatched for a while after WordPress XSS2Shell went public, a five-minute review is worth it:

Application Passwords: revoke anything you do not recognise on each admin.
Users: remove mystery Administrator accounts; check your own admin email still looks right.
Plugins: delete folders you did not put there, including inactive ones.
Must-use plugins under wp-content/mu-plugins, if you use that folder.
Odd file dates around the disclosure window, if your host or backups show them.

If something looks wrong, stop poking and get a human on the site. Half-cleaning a web shell usually means you get to clean it again later.

WordPress XSS2Shell and BugShield

Moments like WordPress XSS2Shell are why “we will update next month” keeps ending badly. BugShield is there for the days something actually breaks, and for the quieter work that keeps a site watched: monitoring, backups, and security habits in one place, with an encrypted Password Vault so you are not emailing logins around during an incident.

Need someone to dig through a site that may have been exposed? Request a one-off fix or look at a Shield plan. Only need the XSS2Shell check right now?

Check your site for WordPress XSS2Shell

Quick answers about WordPress XSS2Shell

Is WordPress XSS2Shell a plugin vulnerability?

No. XSS2Shell is a WordPress core vulnerability, so a site could be exposed even if all of its plugins were fully updated.

Can XSS2Shell be exploited without logging in?

The login-page XSS can be triggered without an account. Turning that into remote code execution also needs a logged-in administrator to encounter the malicious content.

Which WordPress versions contain the XSS2Shell fix?

The fix arrived in WordPress 7.0.3 and matching security releases for older branches, including backports through 4.7.34. These are historical patch levels. Install the latest available WordPress release to include subsequent security fixes.

What does Unknown mean in the free XSS2Shell checker?

Unknown means the check did not produce a usable answer, for example because access was blocked or the connection failed. It is not evidence of protection. Confirm the installed version in your WordPress dashboard or ask your host to check it.

Do I need to check anything after updating WordPress?

If the site remained unpatched after the issue became public, review Application Passwords, administrator accounts, plugins and must-use plugins. Updating closes the vulnerability, but it cannot undo changes that may already have happened.

Originally published on BugShield.

Account security first: 2FA and Active Sessions on BugShield

Fri, 07 Aug 2026 00:00:00 GMT

WordPress security includes protecting the account you use to manage your site. Your BugShield account provides access to your domains, fix requests, and encrypted Password Vault, which is why two-factor authentication and active-session controls matter.

Security starts with the BugShield account

BugShield exists so you can hand a broken site to a developer without emailing passwords into thin air. Credentials live in an encrypted vault tied to the site. Fixes are tracked. Access is logged.

None of that holds up if your BugShield login is easy to borrow. A strong password is still the foundation. What we have shipped now is a way to make that login harder to steal, without forcing every account into a heavier routine on day one.

Optional two-factor authentication

Two-factor authentication is available under Settings > Security, and it stays off until you decide otherwise. When you turn it on, you pair BugShield with an authenticator app you already trust (Google Authenticator, Authy, 1Password, or any standard TOTP app), confirm with a six-digit code, and keep a set of one-time backup codes somewhere safe for the day your phone is not nearby.

From then on, signing in means your password plus a code from the app. Lose the phone and you still have those backup codes. We deliberately skip SMS. Text messages are easier to intercept, and authenticator apps are simply the clearer standard for protecting an account that holds this much.

If you change your mind later, you can turn 2FA off again with your password and a valid code. Some people will enable it the same afternoon. Others will wait until their sites and vault are set up. Both are fine. The protection is there whenever you want it.

Active Sessions

Active Sessions is for the other half of the problem: not just how you sign in, but where you are still signed in.

Active Sessions shows the browsers and devices signed in to your account, along with their approximate location and recent activity. Your current device is clearly labelled, and you can securely sign out an older or unfamiliar session whenever needed.

Left yourself logged in on a shared laptop? You can sign out that session without needing to reset your password. Spot a login you do not recognise? Revoke it straight away, and change your password too. That second step matters. A strange session is a warning, not a full clean-up on its own.

Locations are approximate and are intended to help you recognise familiar sign-ins rather than show an exact position.

How this fits the rest of BugShield security

These updates sit with the rest of how we look after WordPress:

An encrypted Password Vault for site credentials, with access logging
Controlled developer access during a fix, instead of passwords floating around inboxes
Monitoring, backups, and maintenance plans that catch problems early
Clear activity history so you can see what happened on a site

2FA and session control tighten the front door. The vault, monitoring, and fix workflow protect what sits behind it. The idea is simple: everything that touches your website should be handled securely, starting with the BugShield account that owns it.

A small habit worth building

Next time you are in the dashboard, open Security settings. If authenticator 2FA feels right for how you work, turn it on and store the backup codes somewhere you will actually find them. While you are there, glance at Active Sessions and sign out anything that does not look like you.

If you run an agency or look after several client sites, this is especially worth doing. The more sites and credentials sit behind one login, the more that login is worth protecting.

Website security is not only plugins and scans. It is also who can open the door. We will keep hardening that door as BugShield grows. To review these options, sign in to BugShield and open Security settings.

Quick answers about BugShield account security

Is two-factor authentication required on BugShield?

No. Authenticator-based two-factor authentication is optional, and you can enable it from Settings > Security whenever you are ready.

Which type of authenticator app can I use?

You can use any authenticator app that supports standard time-based one-time passwords, often shortened to TOTP. BugShield does not rely on text-message codes.

What happens if I lose the phone used for 2FA?

Use one of the one-time backup codes created when you enabled 2FA. Keep those codes somewhere secure and separate from the device that holds your authenticator app.

What information appears under Active Sessions?

Active Sessions shows the browsers and devices currently signed into your account, when each was last active and an approximate location. Your current device is clearly labelled.

What should I do if I do not recognise a session?

Sign out that session, then change your BugShield password. The location is only an estimate, but an unfamiliar device or activity time is still worth checking.

Originally published on BugShield.