BugShield Blog

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.

WooCommerce 11.2.1: fixing blocked classic checkout and rejected postcodes after 11.2.0

Tue, 13 Oct 2026 00:00:00 GMT

WooCommerce 11.2.1 arrived on 9th October 2026, two days after 11.2.0, and it targets two checkout faults that the earlier release introduced. Stores that hide address fields on the classic checkout could find customers stuck behind a Please enter an address to continue message, with tax or shipping missing. Separately, the checkout block began rejecting valid postcodes from Argentina, El Salvador, Saint Vincent and the Grenadines and the British Virgin Islands. Below you will find how to tell whether your store is affected, how to update with care and how to test checkout properly afterwards.

Miniature metal shopping cart on a white desk in front of a laptop, illustrating online shopping Shixart1985. CC BY 2.0. Resized and converted to WebP.

What changed between WooCommerce 11.2.0 and 11.2.1

WooCommerce 11.2.0 was released on 7th October 2026. The changelog lists it as backwards compatible and marks it as including a database update, which means WooCommerce adjusted how some store data is stored when the update ran.

Two days later the 11.2.1 release notes described a dot release with two fixes, one for the classic checkout and one for postcode validation on the checkout block. The same notes state plainly that 11.2.1 is not a security update and does not include a database update.

Those two labels matter for planning. Because 11.2.1 is not flagged as a security release, the reason to install it is to restore checkout behaviour rather than to close a known vulnerability. Because it carries no database update of its own, moving from 11.2.0 to 11.2.1 is a smaller step than the jump from 11.1 to 11.2.0 was. WooCommerce also notes on its releases page that only the latest version is considered fully secure, and 11.2.1 is currently listed there as the stable release.

Classic checkout stores with removed address fields

The first fix applies to stores using the classic checkout, the older shortcode-based checkout page rather than the newer checkout block. Some shops trim the form so customers fill in fewer boxes, for example by dropping address lines on a store that sells only digital goods. Developers do this with two WordPress filters, which are small pieces of code that let a theme or plugin change WooCommerce's default fields: woocommerce_billing_fields and woocommerce_default_address_fields.

On 11.2.0, stores removing fields through either filter could hit three problems. Checkout could be blocked with the message Please enter an address to continue., tax could fail to be charged, or shipping options could disappear. According to WooCommerce, 11.2.1 restores the 11.1 behaviour for how the classic checkout sends address data when the order summary refreshes, which is the moment totals, tax and shipping are recalculated.

If you are not sure whether your store removes fields, ask whoever built or maintains it, or check whether a checkout field customisation plugin is active. A shorter-than-standard billing form on the classic checkout is a strong hint, but only the code or plugin settings confirm which filter is in use.

Checkout block postcodes for four countries

The second fix concerns the checkout block. In 11.2.0, postcode validation became stricter for a handful of countries and began rejecting formats that customers legitimately use.

Argentina is the clearest example. WooCommerce 11.2.1 accepts Argentine postcodes without the province letter again, such as 1213. The release also restores the formats for El Salvador, Saint Vincent and the Grenadines and the British Virgin Islands that 11.2.0 rejected.

A UK store that ships only within Britain sees no difference from this fix. If you sell to any of those four countries and run the checkout block, a customer reporting that a correct postcode is refused since 7th October fits the description closely.

Updating to WooCommerce 11.2.1 safely

Updating forward is the route WooCommerce has provided for both faults. Rolling back to 11.1 is a riskier choice here, because 11.2.0 ran a database update and older code is not guaranteed to read data changed by a newer version. If you are weighing a rollback anyway, our guide to rolling back a plugin after an update explains how to check database compatibility before doing so.

A staging site, which is a private copy of your store, lets you prove the update before customers see it. Where your host offers one, work through these steps there first.

Take a complete backup of files and database, and confirm you know how to restore it.
Refresh your staging copy from the live store so it reflects current settings, plugins and checkout customisations.
Note the current behaviour on staging: try the symptoms described above and record what happens before you change anything.
Update WooCommerce on staging from Plugins > Installed Plugins and confirm the version shows 11.2.1.
Clear any page, server or CDN caches so you are testing the new code rather than stored copies.
Run the checkout tests in the next section, then repeat the update and tests on the live store.

Testing checkout after the WooCommerce 11.2.1 update

Tests are worth more when they mirror the exact situations the release notes describe. Place real or sandbox test orders that cover each affected path relevant to your shop.

Keep in mind what a clean test actually shows. A completed order after updating is an observation: checkout works now, for that cart, address and payment method. On its own, that result does not prove 11.2.1 was the cause, since a cache clear or a change elsewhere could also have helped. The stronger evidence is a before and after comparison on the same staging copy, where the symptom appears on 11.2.0 and disappears on 11.2.1 with nothing else changed.

Classic checkout with your trimmed address fields: confirm the order completes without the Please enter an address to continue. message.
Tax: check that the order total and the order record both show the tax you expect for the test address.
Shipping: confirm every method you offer appears for a typical address and that the cost lands on the order.
Affected countries on the checkout block: enter an Argentine postcode without the province letter, such as 1213, and a valid postcode for any other affected country you ship to.
Order confirmation: verify the order reaches WooCommerce > Orders with the correct status and that customer and admin emails arrive.

When checkout problems continue after updating

WooCommerce 11.2.1 addresses two specific faults and nothing broader. If tax is still missing or shipping options still vanish after the update and a cache clear, the cause sits somewhere else, such as shipping zone order, a payment plugin or a theme override of checkout templates.

Our step-by-step guide to fixing WooCommerce checkout not working covers missing payment fields, loading errors, caching and plugin conflicts. For rates that refuse to appear, the separate walkthrough on shipping not calculating checks addresses, zone order and enabled methods.

If orders are being lost and you would rather hand the problem over, BugShield's UK developers offer a fixed-price checkout repair. Share access through the encrypted vault rather than by email, and keep the results of your staging tests, since they show the developer exactly which paths fail.

Sources

WooCommerce 11.2.1 FAQs

Is WooCommerce 11.2.1 a security update?

No. The release notes mark 11.2.1 as not being a security update. It fixes classic checkout behaviour for stores that remove address fields and postcode validation on the checkout block for four countries. WooCommerce still notes that only the latest version is considered fully secure.

Does WooCommerce 11.2.1 run a database update?

No. WooCommerce lists 11.2.1 as having no database update. The earlier 11.2.0 release, published on 7th October 2026, did include one, which is why rolling back to 11.1 needs more care than updating forward.

My store uses the checkout block and ships only in the UK. Do I need to worry?

The classic checkout fix does not apply to the checkout block, and the postcode fix covers Argentina, El Salvador, Saint Vincent and the Grenadines and the British Virgin Islands. Updating to the current stable release is still sensible, followed by a quick test order.

How do I know if my store removes classic checkout address fields?

Removal is done through the woocommerce_billing_fields or woocommerce_default_address_fields filters, added by custom code or a checkout field plugin. Ask your developer, or check for an active checkout field customisation plugin. A shorter billing form than standard is a hint, not confirmation.

Checkout works after updating. Does that prove 11.2.1 fixed it?

Not on its own. A successful order shows checkout works for that test. To link the fix to 11.2.1, reproduce the symptom on a staging copy running 11.2.0, update only WooCommerce, clear caches and confirm the symptom is gone.

Originally published on BugShield.

WooCommerce product search with Advanced Woo Search

Mon, 12 Oct 2026 00:00:00 GMT

WooCommerce product search should help shoppers find the exact item they need, whether they type a product name, a stock code or a particular colour. Advanced Woo Search gives you controls for these searches, but the setup depends on your catalogue and which edition you use.

Choose the search behaviour your shop needs

Advanced Woo Search by KramaKit adds AJAX product search to WooCommerce, so shoppers can see matching products as they type. Before installing it, write down three searches your customers need to make. For a parts shop, that could be a component name, its exact SKU and a material. For clothing, try a product name, a colour and a size.

That small list gives you a way to judge the finished setup. A result appearing in the dropdown is only half the job: opening it should take the shopper to the product they expected.

The official WordPress plugin listing separates the free and Pro features. These are the differences that matter for this guide:

Search requirement	Edition	What to check
Product names and SKUs	Free or Pro	Enable the fields you want searched and test an exact product code.
Product attribute values	Pro	Select the relevant global or custom attributes for indexing and search.
Variations as separate results	Pro	Decide whether to show parents, individual variations, or both.

Variable products also work with the free edition. The distinction is whether a search returns the parent product or displays each matching variation separately.

Set up your WooCommerce product search form

Use a staging copy of your shop for the first setup, with a recent backup available. This gives you somewhere to check the header, mobile menu and product links before changing the search your customers use.

In Plugins > Add New, search for Advanced Woo Search, then install and activate it.
Open Adv. Woo Search > General and run Reindex table. Wait for the initial index to finish.
Under Adv. Woo Search > Search Form, enable AJAX Search and save your settings.
Add the form using the plugin’s block, widget or [aws_search_form] shortcode. For a Pro form instance, use its supplied shortcode.
Open the page as a logged-out visitor and search for a published product by name.

KramaKit’s WooCommerce AJAX search guide explains these placement options. Its Seamless Integration setting can replace compatible theme search forms; check your actual header and mobile search rather than assuming every form has changed.

Make SKU searches useful for returning customers

A customer reordering a part may know its stock code but not its product name. Enable SKU in the plugin’s Search in settings, then try a complete code copied from a published product. KramaKit’s search sources documentation explains the available fields and their weighting controls.

For example, suppose a blue mug has the SKU MUG-BLU-350. Search for that full code and confirm the blue mug appears. Then try the product name. If unrelated descriptions dominate the results, review the enabled sources and give the title or SKU more weight before testing again.

Keep a separate test for a variation SKU. As the variable products documentation explains, a matching variation SKU can return the parent product. That is different from a separate result for the exact colour and size. Check the page a shopper lands on so your team knows what to expect.

Search colours, sizes and other attributes with Pro

Attribute searches need Advanced Woo Search Pro. They also depend on your product data: writing “cotton” in a description does not make it a material attribute. Check where you store the value before changing the search settings.

For global attributes, open Adv. Woo Search > Performance and find Data to index. Enable Attributes and select the fields you need using the adjacent settings control. Rebuild the index, then enable those attributes under Search Results > Search in.

Attributes added directly to individual products need the Custom product attributes selection too. KramaKit’s attribute search troubleshooting guide shows both settings and explains how result filters can hide a match.

Test one value at a time first. Search for a colour that belongs to a known product, then a size. Only after those work should you try combined phrases such as “blue large”. Record the expected results so you can spot a change when you adjust the search configuration.

Decide how to display product variations

A clothing shop with many colours and sizes needs a deliberate choice here. One result for the parent keeps the list shorter. Individual variation results can take the customer closer to a specific combination, but fill the dropdown with more entries.

Pro supports parent products, variations, or both. KramaKit’s product variations guide also describes links that open the parent page with the matching variation attributes selected.

Try this with a product containing several similar variations. Check the result title, image and price, then follow the link. Confirm the selected options match the result and that the item can be added to the basket. Repeat with an unavailable variation to check that the search respects the visibility and stock behaviour you intended.

Test the whole search journey before publishing

Keep your original sample searches and add a deliberately unmatched term. Run the same checks on desktop and a real phone, both logged in and logged out.

Exact matches: a product name, a simple product SKU and a variation SKU each return the expected destination.
Pro features: selected attribute values work and variations appear in the format you chose.
Empty results: a nonsense term leaves the shopper with a clear message and a usable search field.
Navigation: the dropdown remains usable in the mobile header and results can be reached with a keyboard.
Product changes: after saving an edit, repeat the relevant search and check the result reflects it.

Save the search settings and your expected results alongside your shop’s update notes. After a theme, WooCommerce or search plugin update, repeat this small set of checks before signing off the release.

If a search does not behave as expected

Start with the product’s publication and visibility settings, the selected search fields and the index. For an attribute problem, check indexing and searching separately. If the form works on a simple test page but fails in the header, record that difference before changing anything else.

For Advanced Woo Search setup questions, use KramaKit’s support first. Send the plugin version, the exact search term, the expected product and a screenshot of the result. For a suspected conflict, reproduce it on staging rather than disabling extensions on a live shop.

If the issue spans your theme or other extensions, BugShield’s WooCommerce troubleshooting and bug fixes service can help investigate the wider problem. Once it is resolved, rerun the same searches to confirm the fix.

WooCommerce product search FAQs

Is Advanced Woo Search free?

There is a free edition on WordPress.org with AJAX product search and SKU matching. Searching product attributes and showing variations as individual results require Pro. Check the current feature comparison before choosing an edition.

Can customers search by a variation SKU in the free edition?

Yes. With SKU search enabled, a variation SKU can match its parent variable product. Showing that variation as its own result is a separate Pro feature. Test the destination with a real variation SKU from your catalogue.

Why does a colour or size search return no products?

First check that you have Pro and that the value is stored in a product attribute. Enable the relevant attributes in both indexing and search settings, then rebuild the index. Custom product attributes have their own selection, and result filters can exclude matching products.

Do I need to rebuild the search index after every product edit?

The plugin synchronises product changes automatically. Build the index after initial setup and rebuild it after changing which data is indexed. If a saved change does not appear in search, check the index and settings before investigating a theme or plugin conflict.

Who should I contact if Advanced Woo Search is not working?

Start with KramaKit’s documentation and plugin support for Advanced Woo Search settings or behaviour. Include your plugin version, a sample search and the expected result. If the problem involves your theme or several WooCommerce extensions, BugShield can help investigate the wider conflict.

Back to the blog

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.

WordPress missed scheduled posts: how WP-Cron timing works and how to test publishing

Sat, 10 Oct 2026 00:00:00 GMT

WordPress missed scheduled posts are a frustrating surprise: you set a publish time, press Schedule, and the post fails to appear when expected. On a site using default WP-Cron, part of the explanation is built in. WordPress checks for due tasks when a page loads rather than watching the clock, so a quiet spell can delay publishing. This guide explains that behaviour, walks you through a careful test, and shows what to record for your host when the test does not pass.

Older WordPress 5.2.4 admin dashboard on a sample blog, shown for context only, with At a Glance, Activity, Quick Draft and WordPress Events and News panels. Gmoran6. CC BY-SA 4.0. Resized and converted to WebP.

Why WordPress scheduled posts can publish late

Pressing Schedule in the editor adds a task to a list. According to the official WordPress Plugin Handbook, WP-Cron handles scheduled tasks, including publishing scheduled posts, and in its default form it checks that list on each page load rather than running continuously.

The handbook illustrates the consequence with a task set for 2:00PM on a site that receives no page loads until 5:00PM, and warns that scheduling errors could occur in that situation. Missed tasks are queued and run at the next page load, so a delay of that kind fits the mechanism: nothing prompts the task until a page load arrives.

On a default set-up, a post that appears late after a quiet period matches that documented behaviour. A post that stays unpublished after your test needs closer investigation, because a failed test alone does not establish the cause.

Which sites feel the delay most

Sites with few visitors leave longer gaps between page loads. In the handbook’s example, no page loads occur between a task’s scheduled time of 2:00PM and a later visit at 5:00PM. A launch or newsletter that depends on timely publishing needs a trigger that does not rely on the next visitor arriving.

A different risk applies where DISABLE_WP_CRON is set to true in wp-config.php. In the configuration the handbook describes, that setting is added after a system task has been scheduled to request wp-cron.php, and it turns off the default page-load trigger. As a consequence of switching that trigger off, a site with the constant set but no working system task has nothing left to prompt its scheduled tasks.

Caching and other hosting layers differ between providers. The handbook describes the trigger as a page load, and whether a cached page served by your hosting reaches WordPress at all is a detail only the host can confirm for your account.

A careful test for scheduled publishing

A temporary post lets you observe publishing on the site you want to check, but on a live site the test post becomes public once it publishes. On a typical site it shows on the blog, can appear in the site's feeds and can be picked up by crawlers, and publication can set off anything connected to new posts, such as newsletter, social sharing or other auto-publish plugins. A neutral title, paused connections and prompt deletion keep that exposure small.

A staging copy only avoids public exposure if its outgoing connections and visibility are contained first, since a copy can keep live credentials and scheduled work. Even when contained, a staging copy checks only its own scheduler and configuration, so its result does not establish whether live publishing works.

The test below includes page loads after the scheduled time because a page load is the documented prompt for the default scheduler. Reloading Posts > All Posts in the dashboard is itself a page load, so the front-page visit and the list reload are both prompts, and the test cannot tell you which one ran the task. The one-minute waits are practical suggestions for this check rather than documented figures.

Confirm that no newsletter, social sharing or other auto-publish connection will send out the test post, and pause any that would.
Create a post with a neutral title such as Scheduling check, set its publish time a few minutes ahead and press Schedule. Write down the exact scheduled time.
Once that time has passed, load a page on the front of the site and note the time. Wait about a minute, then open or reload Posts > All Posts and record the status the post shows.
If the post still shows as scheduled, reload the Posts list once more after another minute before treating the result as a failure.
Open wp-config.php and search for DISABLE_WP_CRON. Note whether the line is present and what value it has.
Delete the test post straight away, then open the Bin view (shown as Trash on some sites) in the Posts list and choose Delete Permanently so the post does not linger. Switch back on anything you paused and keep your notes for the next step.

What your test result tells you

An on-time post is an observed outcome, not proof of its cause. Your own visits during the test, including the Posts list reload, each counted as a page load that could prompt the default scheduler. A pass therefore shows that publishing worked while you were actively loading pages, and leaves open how the site behaves during quiet hours, whether any server task ran, and how the rest of its scheduled jobs are getting on.

Your host is the right contact for the server side, and one message covering everything saves a round of back and forth. Send the scheduled time, the times you loaded a page and checked, the status the post showed, and the DISABLE_WP_CRON value you found. Then ask how scheduled tasks are triggered on your account, whether cached pages reach WordPress, and, where DISABLE_WP_CRON is set to true, whether a server task requests wp-cron.php at a regular interval along with that job's execution or request result around your test time.

Even a server record of that request only shows the request was made. Whether every task WP-Cron then ran completed successfully is a separate question, which is why concrete times and results matter: they give the host something to trace and keep the conversation away from guesses.

Checking DISABLE_WP_CRON in wp-config.php

WordPress keeps core settings in wp-config.php, in the main folder of the installation. You can open it through your host's File Manager or an SFTP client. Download a copy before you edit anything, so the original can go back if the site stops loading.

In the handbook’s configuration, DISABLE_WP_CRON set to true switches off the page-load trigger. A missing line does not settle how the scheduler is configured, since your host can manage scheduling outside that one file. Leave any change to the host or a developer if you are unfamiliar with the file.

Page-load trigger or host scheduler

The default page-load trigger needs no set-up. Its timing depends on page loads reaching the site, which suits content where a delay after a quiet spell causes no harm. Launches, sale pages and announcements tied to a fixed time are a poorer fit.

For critical tasks that must run on time, the Plugin Handbook describes hooking WP-Cron into the system task scheduler as an easy solution. The server requests wp-cron.php at set intervals, and the handbook gives crontab and wget examples for Linux and macOS, plus a PowerShell approach for Windows. Hosting providers differ in which method their accounts support and whether a control panel screen exists for scheduled jobs.

The wget example requests wp-cron.php over the web, so the request needs to reach WordPress for the approach to work. Your hosting set-up decides whether that example fits or a different method is needed.

When you switch, set up the host scheduler and confirm the job's request results with the host before DISABLE_WP_CRON is set to true in wp-config.php, because switching off the page-load trigger first leaves scheduled tasks without a prompt in the meantime. If you run your own server, our server set-up guide includes a cron checklist row.

Getting help with scheduled publishing

Server questions start with the host: whether a scheduled job exists, what its results show and how it reaches WordPress. If the host confirms that requests arrive and your test still fails, give a developer the times and results you recorded so they can investigate further.

BugShield offers one-off fixes at a confirmed price if you would rather hand that investigation over, and Shield maintenance plans include bug fix requests for ongoing care. Either way, a repeat test post is a simple way to recheck publishing after hosting changes.

Sources

WordPress missed scheduled posts FAQs

Why did my scheduled post publish hours after its set time?

One documented explanation is the way default WP-Cron waits for page loads. The WordPress Plugin Handbook gives an example of a 2:00PM task with no page load until 5:00PM and warns that scheduling errors could occur. That explanation does not establish why every delayed post failed to appear, so record your test results and share them with your host if the behaviour remains unexplained.

Does a post publishing on time prove my server cron job works?

No. A page load that reaches WordPress triggers the default scheduler, and your own visits during the test, including reloading the Posts list, count as page loads, so an on-time post does not identify which request ran the task. The host can supply the job's execution or request result at your test time.

When is it safe to set DISABLE_WP_CRON to true?

The Plugin Handbook says to add DISABLE_WP_CRON after the system task that requests wp-cron.php has been scheduled. As our own extra precaution, confirm the job's results with your host before you set it, because the setting removes the page-load trigger.

Will a scheduled test post be visible to the public?

Yes, on a live site. On a typical site it shows on the blog once published, can appear in the site's feeds and can be picked up by crawlers, and connected newsletter or social sharing plugins can send it out. Use a neutral title, pause those connections, then delete the post and remove it from the Bin with Delete Permanently.

What should I send my host if a test post does not publish?

Send the scheduled time, the times you loaded a page and checked the post, the status shown under Posts > All Posts, and whether DISABLE_WP_CRON appears in wp-config.php with its value. Ask how scheduled tasks are triggered on your account, whether cached pages reach WordPress, and for any scheduled job results around that time.

Originally published on BugShield.

Website redesign checklist: planning a better business site

Fri, 09 Oct 2026 00:00:00 GMT

A website redesign checklist helps you decide what needs to change before you pay for a new design. Start with the jobs customers need to complete, keep a record of what already works, and agree how the replacement will be tested. Those decisions belong in the brief, alongside colours and layouts.

1. Define the problem the redesign must solve

A site looking dated is a starting point, but it does not tell a developer what to improve. Describe a customer task that is difficult today: finding the right service, checking delivery information, requesting a quote or paying for an order. Include an example page and explain where the journey breaks down.

Then write a short acceptance statement. For a service business, that could be a visitor finding the relevant service and sending an enquiry from their phone. For a shop, include choosing a product variation, seeing the full delivery cost and receiving an order confirmation. A working journey is something you can test together before launch.

2. Record what your current website gets right

Before changing pages, save a list of their addresses and note which ones bring enquiries, sales or search visits. Your analytics and Google Search Console provide different parts of that picture. Take screenshots of important layouts and export the content you need to retain.

A page with an old design can still answer a valuable customer question. Keep its useful information in the brief rather than allowing it to disappear because it does not fit a new template. Include downloads, product details and answers your team regularly sends to customers, not just the pages visible in the main menu.

3. Decide between a refresh and a rebuild

Match the size of the project to the problem. A confusing menu or a broken form calls for investigation before replacing the entire website. If you retain WordPress, establish whether the existing theme and plugins can support the new design without rebuilding every function.

A custom build becomes a different proposal: the developer creates the features your business needs and must explain how you will edit and maintain them. Ask for a demonstration of routine tasks, such as changing a price or adding a service page. A platform decision affects your daily work long after the design has been approved.

For an isolated WordPress fault, review the scope of a one-off repair before committing to a redesign. If the requirements really have outgrown the current site, carry the audit forward into a proper development brief.

4. Put pages, content and features into the brief

A page count does not describe the whole job. A booking page with availability rules and payment collection needs a different specification from a page containing a telephone number. List what each feature must do, which existing service it connects to, and what should happen when something fails.

Page inventory: identify the pages to keep, revise, combine or retire, with a reason for each decision.
Content responsibility: assign the writing, photography, product information and approvals to named people.
Connected services: record forms, email delivery, payments, bookings and any customer records that need to move.
Acceptance checks: describe the customer journeys and editing tasks that must work before you sign off.

Separate essential launch requirements from later improvements. That gives the developer a defined scope to price and gives you a way to assess a proposed extra charge without reopening the entire project.

5. How BuiltToWinWeb approaches a website redesign

BuiltToWinWeb builds custom business websites, online shops and web applications. Its approach brings the design and the working features into the same project, from the pages customers browse to the forms, bookings and payments they use.

Its custom website design service includes layouts that adapt to phones and larger screens, enquiry forms, online booking and payment integrations. For a service business, those are the practical details that turn a new design into a useful route from a first visit to an enquiry or appointment.

For online retailers, BuiltToWinWeb lists product search, shopping carts, payment processing, and sales and inventory management. Businesses with more specialised requirements can also commission web applications with customer accounts, dashboards, reporting tools and connections to other software.

The offering extends beyond the build itself. Its services include technical SEO, local search support, speed improvements, hosting setup and WordPress-to-custom-PHP migration. That gives you several areas to cover in the brief, particularly when a redesign also involves moving content or changing how the site is managed.

BuiltToWinWeb publishes flat-fee project packages and states that clients receive ownership of the source code. Use the proposal to pin down the pages, features, revisions and handover included in your project, with hosting and future support costs set out separately.

Bring a real customer journey to the conversation, such as booking an appointment with a deposit or ordering a product with several delivery options. Ask the team to walk through both the customer experience and the work your staff will do behind the scenes. You will then have a concrete way to judge the proposed design and test the finished site. For a UK project, confirm availability, communication hours and the currency of the quote directly.

6. Agree ownership and the full running cost

Keep the domain, hosting and key business accounts under your organisation's control, with individual access for the people working on the project. Agree what will be handed over: source files, content, database exports where relevant, design assets and instructions for publishing changes.

Ask for the project fee and ongoing costs separately. Hosting, domain renewal, paid services and future development still need a budget, even when a website has no monthly platform subscription. Establish what happens if you change developer and whether any licensed assets or tools have transfer restrictions.

7. Plan page addresses before the redesign goes live

Changing the appearance of a page does not require changing its address. Keep existing URLs where they still fit the content. For a page that moves, record the old address and its relevant replacement so the developer can set up a permanent redirect.

A redirect sends someone using the old link to the new page. Avoid sending unrelated retired pages to the homepage. Update internal links to their final destinations, and check that the new site's preferred URLs, called canonicals, point to the public site rather than the private preview.

Google's site-move guidance recommends preparing a URL map and monitoring the change. It also warns that rankings can fluctuate while changed pages are recrawled. Build those checks into the launch plan; a new design or a redirect is not a guarantee of retaining every search position.

8. Test the finished site as a customer

Use a private preview, sometimes called a staging site, to review the build before it replaces the public website. Test with the real copy and representative images. A page filled with short placeholder text tells you little about how a long product name or a detailed service description will fit.

Complete an enquiry on a phone and confirm it arrives in the correct inbox.
Try menus and forms using a keyboard, checking visible focus, labels and error messages.
Check layouts at narrow and wide screen sizes, including long headings and tables.
Run a test purchase or booking through the provider's test mode and verify the confirmation and cancellation paths.
Review mobile and desktop performance on representative pages, including the scripts needed for the finished site.

Record failures with the page address, device and steps needed to reproduce them. Give each issue an owner, then repeat the failed journey after it has been corrected. A screenshot of a good score cannot establish that a checkout works or an enquiry reaches your team.

9. Prepare the launch and handover together

Before switching over, take a restorable backup of the current site and agree how to return to it if the launch fails. For a shop or membership site, plan how orders and account changes made during the move will be preserved. A backup taken before those transactions is not a complete record of them.

Assign one person to approve launch and another to carry out the agreed checks. Confirm public pages are accessible to search engines, private previews remain protected, the sitemap uses live addresses and forms still deliver from the production site. If hosting or domain settings change, include business email in the checks.

Finish with a practical handover: edit a page, publish a change and locate the backup and support instructions together. Keep the agreed scope and the final issue list with your account records so the next person responsible for the site can understand what was delivered.

10. Keep a website redesign checklist for the weeks after launch

Launch is the start of observation. Watch for broken links, undelivered enquiries and unexpected changes in sales or search visits. Compare equivalent periods and account for advertising, seasonality and changes to tracking before attributing a result to the redesign.

Agree who handles defects, how long launch support lasts and which later requests count as new work. For a retained WordPress site, include updates, backups and developer support in the ongoing maintenance plan. A custom site also needs a named owner for its hosting, software and recovery arrangements.

Keep the checklist with the project brief and record the outcome of each check. That leaves you with evidence of a working website and a clear route for resolving faults after handover.

Website redesign checklist FAQs

What should a website redesign checklist include?

Include the business goal, an inventory of existing pages, required features, content responsibilities, account ownership, a URL plan, testing, launch arrangements and ongoing support. Give each item an owner and an acceptance check so it is clear when the work is complete.

Do I need to rebuild my website to change its design?

No. A design refresh can keep the existing platform and page addresses. Choose a rebuild when the current system cannot support the agreed requirements at an acceptable cost. Ask the developer to explain why smaller changes are insufficient.

Can a website redesign affect Google rankings?

Yes. Changes to URLs, content, navigation and indexing settings can affect search visibility. Keep useful URLs where practical, map changed pages to relevant replacements, and check Search Console after launch. Redirects do not guarantee unchanged rankings.

What should I ask a web design company before accepting a quote?

Ask which pages and functions are included, who writes and moves the content, how revisions are handled, what you will own, and which costs continue after launch. Request written testing, handover and support terms before agreeing the project.

How does BuiltToWinWeb fit into this checklist?

BuiltToWinWeb publishes custom website design services, including PHP development, with flat-fee pricing. Use the checklist to discuss your requirements and confirm the proposal, editing arrangements and ongoing costs.

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.

WooCommerce Purple theme is back in beta

Wed, 16 Sep 2026 00:00:00 GMT

The WooCommerce Purple theme gives store owners an official block-theme starting point for testing a new shop design. As checked on 9th October 2026, its GitHub release is 1.0.1 and remains marked pre-release. WooCommerce 11.2 is now available, but a working store still needs a tested migration before changing theme.

Purple 1.0.1 is available from the official Woo Themes repository and is marked pre-release. Its package lists WordPress 7.1, WooCommerce 11.1 and PHP 7.4 as minimum requirements. Use supported software releases and test on staging. A manual GitHub installation does not configure automatic theme updates.

What is the WooCommerce Purple theme?

Purple is an open-source block theme built by Woo for WooCommerce stores. Unlike a classic theme, it is designed around the WordPress Site Editor, block templates, patterns, and Global Styles. A store owner can change the overall look of the shop without relying on a separate theme options screen for every decision.

WooCommerce announced the renewed beta on 15th September 2026 in its official call for testing. The first preview includes templates for most block-enabled WooCommerce pages, ten colour palettes, ten font pairings, and custom styles for WooCommerce and WordPress blocks. Its pattern library covers common shop layouts such as product grids, filters, collections, calls to action, and product detail sections.

That makes Purple a starting point rather than a finished identity every shop must share. The colours, type, patterns, and templates can be adjusted in the editor, while developers and agencies can build more specific designs on top of the same block-based foundation.

Check the release status and update route

The official release list marks Purple 1.0.1 as a pre-release, published on 30th September 2026. Its theme header lists WordPress 7.1, WooCommerce 11.1 and PHP 7.4 as minimum requirements. Minimum compatibility is not a security recommendation: PHP 7.4 is unsupported, so choose a supported PHP release and test your complete store.

For a GitHub package, plan how you will check for and install subsequent theme releases. The original preview did not configure automatic updates. Before using any other distribution channel, confirm its publisher, version and update mechanism rather than assuming every download behaves the same way.

Available now	Check before switching
Open-source Purple 1.0.1 pre-release on GitHub	Whether the chosen release is marked stable or pre-release
Store templates, patterns, palettes, and font pairings	Your products, extensions and custom layouts on staging
Manual installation for staging and local testing	The source of future updates and who will install them

For a new experimental shop or a local build, that may be exactly what you want. For a trading store, the beta label changes the decision. Checkout, customer accounts, extensions, custom templates, and mobile layouts all need to be proved before a theme change reaches customers.

Why has Purple returned now?

Purple is not a completely new idea. Woo discussed the block theme in 2025, then paused the project while it reconsidered where the work should live. Since then, improvements have gone into WooCommerce blocks and WordPress itself rather than being kept inside one large theme framework.

That change explains why the new Purple is deliberately lean. Older theme setups sometimes needed extra extensions for product heroes, custom homepages, galleries, mini-carts, headers, or footers. Many of those building blocks now belong in WooCommerce and the WordPress editor, where any compatible block theme can use them.

The important update is therefore larger than a new shop design. Purple gives Woo a reference theme for the block editing experience, while the underlying controls remain useful to other block themes as well.

How WooCommerce 11.1 supports the Purple theme

Purple arrives just after WooCommerce 11.1, the current stable branch at the time of publication. The official WooCommerce 11.1 release notes cover broader store changes, including variation image galleries and faster Store API and REST requests. Purple also benefits from less headline-grabbing block work in that release.

Product Price can respond to different viewport styles for type, colour, padding, and margins.
Product Reviews follows the WordPress wrapper used for responsive styling.
Product Details supports more spacing, background, and border controls.
Product Gallery supports custom aspect ratios and better coordination between the main image and thumbnails.

WooCommerce also published measurements showing Store API and REST requests becoming 30 to 42 per cent faster when block and pattern registration can be skipped. Those figures come from Woo's testing, so they should not be treated as a guaranteed speed increase for every store. They do show the kind of core work that makes a lean block theme more practical.

WooCommerce 11.2 is now available

WooCommerce released version 11.2 on 7th October 2026. Its storefront work includes additional block styling controls, alongside changes to product imports and checkout fields. The release also includes security fixes and a database update, so review your extensions and test the upgrade before applying it to a live shop.

These are practical improvements. A filter that stays inline on a large screen but moves into an overlay on a phone can make a catalogue easier to browse without a custom mobile implementation. Consistent borders, typography, and quantity controls also help the shop feel like one design rather than a collection of unrelated plugin screens.

WooCommerce 11.2 being available does not change Purple's pre-release label. Treat the plugin update and a theme switch as separate changes so a failure can be traced to the correct component.

Does Purple replace WooCommerce Storefront?

Purple is Woo's first official block theme, while Storefront is its long-standing classic theme. That makes Purple the clearer expression of where new block-based store design is heading. It does not mean an existing Storefront shop should be switched immediately.

A mature Storefront site may depend on a child theme, template overrides, extensions, and CSS written around its current markup. Changing the theme can affect far more than colours. Product pages, navigation, checkout, tracking, accessibility, and custom code may all behave differently.

For a new store, Purple may become a useful official starting point once it reaches a stable release. For an existing store, the right question is not whether one theme is newer. It is whether a tested migration gives customers a better shop without breaking the parts that already earn revenue.

How to test the WooCommerce Purple theme safely

Start with a local site or a staging copy that reflects the live store. WooCommerce asks testers to review the front page, shop, product, cart, checkout, My Account, and search templates. That is a sensible base, but a real store should go further.

Take a current backup. Keep a restorable copy of the files and database before changing the staging theme or updating its supporting software.
Match the required software. Purple 1.0.1 lists minimum requirements of WordPress 7.1, WooCommerce 11.1, and PHP 7.4 or later. Check extension compatibility before updating simply to meet those versions.
Use real product types. Test simple, variable, grouped, virtual, downloadable, sale, and out-of-stock products used by the business.
Complete the buying journey. Check search, filters, basket changes, coupons, tax, shipping, payment, confirmation, transactional emails, refunds, and customer account pages.
Repeat the checks on smaller screens. Review filters, galleries, menus, forms, tables, and the whole checkout on phone and tablet widths.
Include every important extension and customization. Payment gateways, subscriptions, bookings, product add-ons, analytics, consent tools, and child-theme code need their own checks.

If you find a Purple-specific problem, WooCommerce asks for feedback in the official Woo Themes issue tracker. Include the WordPress, WooCommerce, PHP, and Purple versions, the affected template or block, clear reproduction steps, and a screenshot or recording when the issue is visual.

What should a store owner do today?

If you are curious about modern WooCommerce design, Purple is worth exploring on staging. It is an official, open-source preview with a useful set of shop templates and patterns. Testing it now can also help shape the stable theme that eventually reaches the normal directories.

If your live store is working, there is no urgent reason to switch. Wait for a stable release and automatic update path, then assess the migration against your actual catalogue, extensions, custom work, and customer journeys. A theme controls what shoppers see at some of the most valuable moments on the site. A careful test is more important than being first.

Planning a WooCommerce theme change? Test the catalogue, checkout, extensions, and custom code on staging before the new theme reaches customers. BugShield can help investigate compatibility problems and fix the issues a redesign uncovers. See WooCommerce support

Quick answers about the WooCommerce Purple theme

What is the WooCommerce Purple theme?

Purple is an open-source WooCommerce block theme made by Woo. It provides store templates, ecommerce patterns, ten colour palettes, ten font pairings, and styles for WooCommerce and WordPress blocks.

Is the WooCommerce Purple theme ready for a live store?

As checked on 9th October 2026, the official Purple 1.0.1 GitHub release is marked pre-release. Test it on a staging or local copy and verify your store workflows before considering a live switch.

Where can I download the Purple theme?

The official Woo Themes repository on GitHub lists Purple 1.0.1. A manual GitHub installation does not configure automatic theme updates. Check the release status and update arrangements for the package you choose.

Does Purple replace the Storefront theme?

WooCommerce presents Purple as its first official block theme and a modern starting point for new stores. Existing Storefront sites do not need to switch immediately, especially when they rely on child themes, extensions, or custom templates.

What should I test before switching a WooCommerce theme?

Test the shop, product, cart, checkout, My Account, search, filters, product variations, payment methods, shipping, tax, emails, mobile layouts, extensions, analytics, and any custom code on a current staging copy before planning a live change.

Originally published on BugShield.

Matt Mullenweg returns as Automattic CEO after two days

Sat, 12 Sep 2026 00:00:00 GMT

Matt Mullenweg has returned as Automattic CEO, less than 48 hours after the company's board placed him on paid leave. Mullenweg told employees that the board was back in agreement and WordPress Executive Director Mary Hubbard publicly welcomed his return. Automattic's board, however, has not explained how or why the decision changed.

The short version: Mullenweg says he is back in control of Automattic, and his return as CEO has been publicly acknowledged by WordPress's executive director. The boardroom process remains unclear, and no immediate change to WordPress software or existing websites has been announced.

Matt Mullenweg returns after a 48-hour reversal

The first announcement came on 9th September 2026. Mullenweg told Automattic employees that the company's board had voted to place him on paid leave and appoint chief financial officer Mark Davies as interim CEO. Automattic then confirmed both parts of that change to reporters.

By early 11th September, the position had changed again. In a company-wide Slack message seen by TechCrunch and reported separately by 404 Media, Mullenweg said the board was back in agreement and that he was in control of Automattic. He described the previous 48 hours as something the company still needed to sort out.

As The Verge reported, Mary Hubbard, Executive Director of the open-source WordPress project, then said publicly that she was relieved and pleased to see Mullenweg return as Automattic CEO. The official WordPress social account shared her message, and Mullenweg reposted it.

What is confirmed and what is still unclear?

The story moved so quickly that the clearest way to understand it is to separate public confirmation from unanswered questions.

Point	What we know
Mullenweg's position	He told staff he was back in control, and Hubbard publicly welcomed his return as CEO
The board's position	No public explanation of the reversal has been reported
Mark Davies	His brief interim appointment was confirmed, but his next role has not been publicly set out
WordPress	No change to the open-source project or WordPress websites was announced

This distinction matters because Automattic had previously issued a direct statement confirming Mullenweg's leave and Davies's appointment. Reporting on the return includes Mullenweg's internal message and Hubbard's public response, but not a detailed statement from Automattic's board explaining a formal vote or resolution.

That does not make the return meaningless. It does mean claims about who persuaded whom, what legal powers were used, or why the board changed course would be speculation until the people involved provide evidence.

Why was Matt Mullenweg out as CEO for only two days?

There is no confirmed public answer. When the board placed Mullenweg on leave, Automattic did not give a reason or a planned end date. When he announced his return, Mullenweg said he hoped much of what happened had been a misunderstanding, but he did not explain what the misunderstanding was.

The available reports describe a sharp disagreement at the top of a private company. They do not establish the full sequence of board decisions, changes in voting support, or negotiations that produced the reversal. Mullenweg's public posts about attempted coups add colour, but they are not a substitute for a corporate account of what happened.

Automattic and WordPress are connected, but not the same

The rapid change has again produced headlines that treat Automattic and WordPress as one organisation. They are not. Automattic is the private company behind services and products including WordPress.com, WooCommerce, Tumblr, Jetpack and Beeper. WordPress is free, open-source software developed through a broader project and community.

The official WordPress.org guide explains the practical difference between the open-source software and Automattic's WordPress.com hosting service. Mullenweg holds influential roles on both sides: he founded and leads Automattic, and he is a WordPress co-founder and project leader. A change to one role does not automatically rewrite the other.

This is why our earlier report on Mullenweg's leave of absence did not tell site owners to expect WordPress itself to stop. The company leadership story has reversed. The distinction between the company and the project has not.

What does Mullenweg's return mean for WordPress owners?

For somebody running a WordPress website, there is still no immediate technical action to take. The change did not alter your WordPress installation, hosting account, plugins, theme, database or domain. No WordPress release was cancelled, and no interruption to the plugin or theme directories was announced as part of the dispute.

Customers of Automattic products may reasonably want clearer leadership information, particularly after two changes in two days. The useful signals will be operational ones: official product notices, service status, roadmap changes and direct customer communication. A dramatic internal message is not, by itself, a reason to move a working website in a hurry.

Good site ownership remains the practical answer to uncertainty around any supplier:

keep independent, current backups and test that they can be restored;
retain control of your domain, hosting and administrator accounts;
keep WordPress core, plugins and themes updated;
monitor uptime, security and unexpected site changes; and
base migration decisions on service evidence, not boardroom speculation.

What happens next at Automattic?

Mullenweg is back at the top of the company, but the speed of the reversal leaves larger questions behind. It is not publicly clear whether the board's concerns have been resolved, whether its membership or working relationship will change, or what happens next for Davies.

The most useful next step would be a clear company statement that sets out the current leadership and gives employees, customers and partners a stable point of reference. Until then, the responsible conclusion is narrower: Mullenweg has returned as Automattic CEO, the open-source WordPress project continues, and the reason for one of the shortest executive departures in recent memory remains unexplained.

Keep your WordPress site in your hands Independent backups, monitoring, regular updates and clear account ownership keep your website steady when a supplier or the wider WordPress ecosystem changes around it. See WordPress maintenance

Is Matt Mullenweg back as Automattic CEO?

Yes. Mullenweg told Automattic employees that he was back in control, and WordPress Executive Director Mary Hubbard publicly welcomed his return as CEO. Automattic's board has not published a detailed account of the reversal.

How long was Matt Mullenweg away from Automattic?

Less than 48 hours passed between Mullenweg telling employees he had been placed on paid leave and his message saying he was back in control of the company.

Is Mark Davies still interim CEO of Automattic?

Mullenweg says he has returned as CEO, so Davies is no longer leading the company on that interim basis. Automattic has not publicly explained Davies's current position or what happens next for him.

Why did Automattic's board reverse its decision?

No confirmed public explanation has been given. Mullenweg said the board was back in agreement and suggested there had been a misunderstanding, but the board has not described the decisions or discussions behind his return.

Does Matt Mullenweg's return change my WordPress website?

No immediate technical change has been announced. WordPress is open-source software, while Automattic is a private company that runs WordPress.com and other products. Existing WordPress sites continue to work as before.

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.

Matt Mullenweg leave of absence: what it means for WordPress

Thu, 10 Sep 2026 00:00:00 GMT

Matt Mullenweg was placed on paid leave from Automattic, the company he founded and led as chief executive, on 9th September 2026. Chief financial officer Mark Davies was named interim CEO, but Mullenweg said he was back in control less than 48 hours later. The brief company leadership change did not mean WordPress software or WordPress websites had been put on hold.

Update, 12th September 2026: Mullenweg has returned as Automattic CEO. Read our follow-up on his return. The report below explains the original board decision and why it did not directly change WordPress websites.

What happened to Matt Mullenweg?

On 9th September 2026, Matt Mullenweg told Automattic employees that the company's board had voted to place him on a paid leave of absence. He said he voted against the decision and that Mark Davies had been chosen as interim CEO.

Automattic then confirmed the change in statements reported by both 404 Media and TechCrunch. At that point, the company said Mullenweg was on leave and that its board had confidence in Davies and the wider team.

Davies was Automattic's chief financial officer before taking the interim role. Reporting based on the internal messages says Mullenweg remains a member of Automattic's board, so this is not the same as him leaving the company altogether.

There is no WordPress CEO

You may see this story described as the WordPress CEO being placed on leave. It is an understandable shortcut, but it blurs together three different things.

Name	What it is	What the leave changes
Automattic	The commercial company founded by Mullenweg	Mark Davies was named interim CEO
WordPress.com	Automattic's managed hosting service	It briefly sat inside a company under interim leadership
WordPress	Open-source software maintained by a wider community	No immediate change to the project was announced

The official WordPress.org explanation is clear: WordPress is free, open-source software owned by no individual or company, while WordPress.com is a hosted service run by Automattic. Mullenweg is both Automattic's founder and a co-founder and leader of the WordPress project. Those roles are closely connected, but they are not the same job.

What changes for the WordPress project?

For now, the public answer is that the WordPress project continues. TechCrunch reported a message from WordPress.org executive director Mary Hubbard saying Mullenweg remains the project's leader, that she remains executive director, and that teams, priorities, and work are continuing as planned.

That means the board decision at Automattic did not remove Mullenweg from his WordPress project role. It also did not announce a pause to WordPress releases, the plugin and theme directories, community teams, or work on the software itself.

There is still a practical connection. Automattic sponsors people who contribute to WordPress, and many of its products are built around the software. A lasting shift in Automattic's priorities could therefore have an effect on parts of the wider ecosystem. No such change has been confirmed as part of this announcement, so it would be speculation to say what that effect might be.

What does the Matt Mullenweg leave of absence mean for site owners?

If you run a self-hosted WordPress site, there is no technical action you need to take because of this news. Your site remains on your host, using the same WordPress installation, theme, plugins, database, and domain as it did before the board vote.

There was also no announced reason to move away from WordPress.com or another Automattic service in a rush. Customers should watch official service updates and product announcements, just as they would during any important leadership change.

The sensible steps are the ordinary ones that protect a WordPress site whatever happens at a supplier:

keep WordPress core, plugins, and themes updated;
maintain a current off-site backup and test that it can be restored;
keep control of your domain, hosting, and administrator accounts;
monitor uptime and important site changes; and
avoid making a migration decision based only on a breaking headline.

What is still unknown?

The later reversal answered how long the leave lasted, but not why the board acted or why it changed course. Automattic's board has not publicly explained the sequence of decisions, and the company has not set out what happens next for Davies.

Mullenweg described the board process in strongly worded terms in his message to employees. That is his account of the meeting, not an independently established reason for the decision. Until Automattic or its board gives more detail, the cause of the leave should be treated as unknown.

What we will watch next

The next useful information will come from official action rather than speculation: whether Automattic's board explains the reversal, whether the company's leadership structure changes, and whether there are any changes to Automattic's sponsored WordPress contributions or product roadmaps.

For WordPress owners, the key point remains simple. Automattic changed chief executive and changed back less than 48 hours later. WordPress itself did not stop, your site did not change, and the open-source project said its work was continuing as planned.

Keep your site steady through wider changes Leadership news does not change the basics. Reliable updates, off-site backups, monitoring, and clear access to your own accounts keep a WordPress site in your control. See WordPress maintenance

Quick answers about Matt Mullenweg's leave

Is Matt Mullenweg the CEO of WordPress?

No. WordPress is an open-source software project and does not have a company CEO. Mullenweg is a WordPress co-founder and project leader, and he has returned as CEO of the private company Automattic.

Did Matt Mullenweg leave Automattic?

No. Automattic confirmed that Mullenweg had been placed on paid leave, and reporting said he remained a member of its board. Less than 48 hours later, he told employees that he was back in control as CEO.

Who was the interim CEO of Automattic?

Mark Davies, Automattic's chief financial officer, was named interim CEO when Mullenweg was placed on leave. Mullenweg said he had returned as CEO less than 48 hours later.

Why was Matt Mullenweg placed on leave?

Automattic has not publicly given a reason for the board's decision. Mullenweg disputed the process in a message to employees, but that does not establish why the board acted.

Does the Automattic leadership change affect my WordPress site?

No immediate technical change to self-hosted WordPress sites or the open-source project was announced. WordPress.org's executive director said project teams, priorities, and work were continuing as planned.

Originally published on BugShield.

Run PHP examples in your browser with WordPress Playground

Sat, 05 Sep 2026 00:00:00 GMT

You can add runnable PHP examples to your own website with WordPress Playground. Visitors can press Run and see the result without leaving the page. WordPress is now using the same feature in its Code Reference, starting with two examples introduced in WordPress 7.1.

Want to see it before reading the details? Open the official WP_HTML_Processor::class_list() example, then use its Run button to start the example in your browser.

You can add runnable PHP examples to your own website

WordPress Playground provides an embeddable PHP snippet, which is a small component a website owner can add to a page. It displays the example, a Run button, and the result together. It can be used in tutorials, documentation, blog posts, and demos, so the feature is not limited to WordPress.org.

WordPress itself has started using these snippets in the official Code Reference. WordPress 7.1 supplied the first two runnable examples, and the WordPress announcement says more are coming with WordPress 7.2.

The PHP example on your page runs in its own temporary Playground environment. It does not run inside the WordPress installation hosting your website, and it does not use that site's files, plugins, or database.

What happens when you press Run?

When somebody presses Run, WordPress Playground starts a temporary test environment inside their browser. If the example uses WordPress functions, Playground loads a temporary WordPress installation for that snippet. This is separate from the website displaying the example.

Playground does this with WebAssembly, a format that lets software run safely inside modern browsers. You do not need to understand WebAssembly to use it. In practical terms, your browser gets a small, isolated test area, runs the sample there, and shows you what the PHP returned.

The first run can take a moment because the browser has to load that environment. After it starts, you get a real result rather than a picture of what the result should look like.

Why runnable WordPress PHP examples matter

This sounds like a feature only developers will notice, but better examples can help anybody who owns or looks after a WordPress site. When a piece of documentation is easier to test, it is easier to learn from and easier to use when diagnosing a problem.

Who it helps	What gets easier
People learning PHP	Trying an example without installing a full development setup first
WordPress developers	Checking a small API example and seeing its output straight away
Documentation writers	Publishing examples that readers can verify instead of simply trusting
Support teams	Sharing a small, repeatable example when explaining a WordPress behaviour

That last point is especially useful. A clear example reduces the usual back and forth about what code was run, which version was involved, and what result appeared. It does not solve a whole website problem, but it can make the smallest part of that problem much easier to discuss.

How to try WordPress PHP examples in your browser

You have three straightforward ways to use the feature.

Start with a runnable Code Reference example. Visit the WP_HTML_Processor::class_list() page and press Run on the example.
Open the standalone editor for your own small test. The WordPress PHP Playground lets you enter PHP, choose WordPress and PHP versions, run the code, and share the example with a link.
Add a runnable example to your own website. The official PHP snippets guide shows how to embed the component in a web page. Visitors can then edit and run the example directly on that page.

Keep experiments small and never paste passwords, API keys, customer details, or private production code into a shared example. A browser playground removes installation work. It does not remove the need to handle sensitive information carefully.

Running PHP in your browser is not the same as testing your site

A runnable example tells you how a focused piece of code behaves in the Playground environment. Your website has far more moving parts: its theme, plugins, database, PHP extensions, server settings, cache, and real content can all affect the result.

That means Playground is a useful first step for learning or narrowing down an idea, not proof that a change is safe for a live website. If you are updating a plugin, changing a theme function, or fixing a real error, use a WordPress staging site that closely matches production. Take a backup before the change and check the result in the browser as a visitor and an administrator.

There is another useful distinction: this feature does not change how your live WordPress site runs PHP. The runnable example uses a separate Playground test environment that can be embedded in a web page.

A small WordPress 7.1 feature with a useful future

Only two Code Reference examples are runnable today, so this is the start of the idea. The important bit is the path it opens. More WordPress documentation can become something you can try, not just something you have to interpret before building a test setup of your own.

For developers, that can mean faster learning and clearer bug reports. For site owners, it can mean the person helping with a problem has a quicker way to explain and check one small part of it. The careful work still happens on staging before anybody touches the live site.

Ready to test a real WordPress change? Playground is ideal for small examples. For a plugin update or code change on a real site, use a current backup, a matching staging copy, and a proper check after the work is complete. See managed updates

Quick answers about running PHP in your browser

Can I add runnable PHP examples to my own website?

Yes. WordPress Playground provides an embeddable PHP snippet component for tutorials, documentation, blog posts, and demos. The example runs in a separate Playground environment and does not use your live WordPress site's files or database.

Does the PHP code run on my live WordPress website?

No. The example runs in an isolated Playground environment in your browser, not on your live website or hosting account. It cannot test the exact combination of plugins, theme, settings, and server software used by your real site.

Do I need WordPress 7.1 installed to use runnable examples?

No. Playground creates a separate temporary environment for the example. WordPress 7.1 is relevant because it supplied the first two runnable examples used in the official Code Reference, not because your own site needs that version.

Will every WordPress Code Reference example have a Run button?

Not yet. WordPress 7.1 shipped the first two runnable examples, and the project says more are planned for WordPress 7.2. Most Code Reference examples remain ordinary code samples for now.

Is WordPress Playground a replacement for a staging site?

No. Playground is excellent for learning and small, isolated tests. A staging copy is still the right place to test an update or fix against your real theme, plugins, content, database, and hosting setup before changing the live site.

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.

WP Rocket incompatibility with WordPress 7.1: update WP Rocket first

Thu, 20 Aug 2026 00:00:00 GMT

The WP Rocket incompatibility with WordPress 7.1 that caused a fatal error was fixed in WP Rocket 3.23.2.2. If an older copy is still breaking your site, recover access and install a current vendor release. Check the exact error first, because a different critical error needs its own investigation.

The fix is available Version 3.23.2.2 was the first fix for this error. Install the latest stable WP Rocket release from your account, then test current WordPress updates on staging. If the site is already down, we can help with a WordPress critical error fix. Get the site fixed

The short version

WordPress 7.1 and older WP Rocket releases can be a bad combination. On affected sites, a normal request can reach WP Rocket's Cloudflare compatibility code and stop on this error:

TypeError: substr(): Argument #1 ($string) must be of type string, int given
wp-content/plugins/wp-rocket/inc/ThirdParty/Plugins/CDN/Cloudflare.php:562

That is not a warning tucked away in a log while the site carries on. It is a fatal error. Depending on where it fires, visitors can see the WordPress critical error screen and you can lose access to wp-admin.

WP Rocket released the 3.23.2.2 fix on 20th August 2026. Its changelog now lists later releases, including 3.23.5.1 on 2nd October. The original fix version identifies this incident; use the latest stable package available from the vendor for an update today.

What causes the WP Rocket incompatibility

The crash sits in WP Rocket's Cloudflare integration code, but this is the slightly confusing bit: you do not need the separate Cloudflare plugin installed for it to happen. The original report reproduced the error without it.

In plain English, WP Rocket looks through a list of WordPress callbacks and checks the end of each callback ID with PHP's substr() function. The code expects every ID to be text. Under the conditions reported with WordPress 7.1, one of those IDs can arrive as an integer instead. PHP 8 refuses to treat that integer as a string automatically, so it throws a TypeError and stops the request.

The actual code correction is tiny: cast the value to a string before passing it to substr(). The impact is not tiny. A single missing type cast can turn a routine core update into a dead site.

How the fault was identified and fixed

The original bug report was opened on 6th July 2026 and reproduced the crash with WordPress 7.1 alpha and PHP 8.3. The report included the error and a proposed correction. The fixed release followed on 20th August. Those dates describe the original incident; the update is available now.

Update WP Rocket before testing WordPress

If WP Rocket is older than 3.23.2.2, update it before testing a WordPress upgrade. The original error was reproduced without the separate Cloudflare plugin, so its absence does not rule out this fault. Keep WordPress security updates moving once the plugin issue is resolved.

You may see another site with the same versions update cleanly. That does not prove yours will. The fatal depends on the callbacks registered by the site's particular mix of plugins and theme. Two outwardly similar sites can behave differently.

Our advice is simple:

Record the installed WordPress and WP Rocket versions and check the release notes.
Take a fresh, restorable backup of files and the database.
On a staging copy, install the latest stable WP Rocket release from your account.
Update that staging copy to the latest available WordPress release.
Check the front end, wp-admin, publishing, cache clearing, forms, checkout, and scheduled jobs.
Only update production after those checks pass.

If you do not have a safe place to test, our guide explains how to create a WordPress staging site. Our safe plugin update checklist covers the same backup, test, verify routine for everyday updates.

Is Elementor affected too?

We have not found evidence of a separate Elementor fatal error caused by WordPress 7.1 in this incident. That distinction matters. An Elementor site running an affected WP Rocket version can still go down, but the fatal stack trace points to WP Rocket, not Elementor.

The WP Rocket fix and regression test describe the trigger as a plugin, theme, or custom code registering a Closure or invokable object on either deleted_post or transition_post_status. They do not name Elementor. Elementor does use post lifecycle hooks, but that fact alone is not enough to reproduce the crash. The specific callback shape matters, and we have not found a reproducible report that ties Elementor to it.

So the honest answer is: Elementor is not confirmed as the cause, and we would not deactivate it on a guess. If your Elementor site shows the exact Cloudflare.php and substr() error above, update or disable WP Rocket first. If the stack trace names Elementor or Elementor Pro instead, treat that as a different compatibility problem and investigate it separately.

Already updated and staring at a critical error?

Do not keep refreshing and hoping the cache sorts itself out. If the error contains wp-rocket/inc/ThirdParty/Plugins/CDN/Cloudflare.php and substr(), disable WP Rocket first so WordPress can load again.

Open your hosting file manager, SFTP, or SSH and go to wp-content/plugins.
Rename the wp-rocket directory to wp-rocket-disabled. WordPress will no longer be able to load that copy of the plugin.
Reload the site and wp-admin. Take a backup before making the next change.
Download the latest stable WP Rocket package from your legitimate account. Keep a private copy of the old folder, then replace the disabled installation with the clean vendor package. Ask your host to help if you are unsure which folder to replace; do not leave multiple plugin copies installed.
Reactivate WP Rocket, clear its cache, and check both logged-in and logged-out pages.

If you are not comfortable working in the plugins directory, stop after the backup and ask your host or a developer to handle it. The longer walkthrough for regaining access is in deactivating a WordPress plugin without wp-admin. If the error is different, use the broader WordPress critical error guide instead of assuming WP Rocket is the cause.

Do not edit the WP Rocket file as the first fix

Yes, the public report shows a one-line change. No, that does not make editing a live premium plugin the best first move for most site owners. A typo can trade one fatal error for another, and the next plugin update can overwrite the manual edit without warning.

Recover access by disabling the broken plugin copy, then install the vendor's fixed release. A manual patch can be a short emergency bridge for a developer who understands the code and has a backup. It should not become the permanent version running your site.

What this says about WordPress update day

The lesson is not “never update WordPress.” Staying on an old core version forever creates its own security and compatibility problems. The lesson is that release day is a poor time to discover whether a commercial plugin tested the same combination you run in production.

A backup gives you a way back. Staging shows you the break before customers do. Monitoring tells you if the live site stops answering after the change. Those are separate jobs, and you want all three. BugShield's managed backups, uptime monitoring, and managed WordPress updates are built around that reality.

The original compatibility fault is fixed. Bring WP Rocket up to date, test WordPress updates and verify the public site, dashboard and important forms after deployment. If the same error continues with a current plugin, preserve the error details and ask the vendor to investigate rather than repeatedly delaying WordPress updates.

Quick answers about WP Rocket and WordPress 7.1

Which WP Rocket version should I use with WordPress 7.1?

WP Rocket 3.23.2.2 was the first release fixing this error. Install the latest stable vendor release, then test it with current WordPress updates on a staging copy before changing the live site.

Does this problem only affect sites using the Cloudflare plugin?

No. The fatal error sits in WP Rocket's Cloudflare compatibility code, but it was reproduced without the separate Cloudflare plugin installed.

Should I update WordPress or WP Rocket first?

Update WP Rocket first on staging, then test the latest available WordPress release. Check public pages, wp-admin, forms, checkout and scheduled tasks before applying the tested combination to the live site.

What should I do if the update has already caused a critical error?

If the error names WP Rocket's Cloudflare.php file and substr(), disable WP Rocket through your hosting file manager, SFTP or SSH. Then install a current copy from your WP Rocket account and test the site before reactivating it.

Is Elementor responsible for this compatibility issue?

There is no confirmed separate Elementor fault in this incident. Check the error details first. If they point to WP Rocket's Cloudflare.php file, deal with WP Rocket rather than disabling Elementor on a guess.

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.

Best shared hosting for WordPress: how to compare plans in 2026

Thu, 06 Aug 2026 00:00:00 GMT

“Best shared hosting” lists usually rank brands. This guide ranks criteria instead: PHP limits, isolation, backups, staging, support depth, and the point where shared hosting becomes the reason your site keeps breaking.

Editorial note: this is a criteria-first comparison. We describe typical plan tiers rather than affiliate partnerships, so you can score any host yourself.

Who shared hosting is for

Shared hosting puts many sites on the same server. That keeps the monthly price low and removes most server admin work. It is usually the right starting point if you run one brochure site, a brochure WooCommerce shop with light traffic, or a content site that does not need custom server software.

Shared hosting is a poor fit when you need guaranteed CPU, custom Redis stacks, unusual cron jobs, or the ability to reboot and resize resources yourself.

The shared hosting tiers that actually matter

Ignore marketing names. Score providers against three practical tiers. Many “WordPress hosting” products are still shared under the hood.

Tier	Best for	Typical strengths	Watch-outs
Budget shared	Single brochure sites, staging-free blogs	Low price, one-click installers, free SSL	Noisy neighbours, weak backups, limited PHP workers
Performance shared	Growing blogs, busy brochure sites	Better CDN, caching, staging on some plans	Renewal pricing jumps, resource caps still shared
Managed WordPress shared	Owners who want less stack fiddling	Auto updates, malware tools, WordPress-aware support	Plugin restrictions, migration policies, higher cost

Criteria checklist before you buy

1. PHP and WordPress runtime

A supported PHP version compatible with your theme and plugins; WordPress recommends PHP 8.3 or greater
Ability to change PHP version per site without a ticket
Memory limit and max_execution_time high enough for plugins and imports
Enough PHP workers so admin-ajax and checkout do not queue under load

PHP 8.1 reached end of life on 31st December 2025. Check the PHP support schedule alongside WordPress hosting requirements. A version that still runs your site can be outside security support. Test upgrades before changing the live site.

2. Isolation and security

Account isolation between customers on the same machine
Free SSL with automatic renewal
Malware scanning or at least easy restore after compromise
SFTP / SSH access when something breaks outside the control panel

3. Backups you can actually restore

Daily or more frequent off-site backups
Self-service restore for files and database
Retention that covers quiet weekends and holiday weeks
Exportable archives you can download, not only restore in-place

4. Staging and change safety

Before changing PHP or updating plugins, test a current copy of the site and confirm you can restore its backup. Prefer hosts with staging and a documented way to transfer tested changes without overwriting new orders or enquiries.

5. Support that understands WordPress

24/7 chat or ticket coverage for real downtime
Agents who can read PHP fatals, not only restart Apache
Published response targets for urgent tickets

6. Contract and migration friction

Introductory vs renewal pricing (model year-two cost, not month one)
Site migration help included or billed
Egress or backup download limits
Cancellation and refund windows written clearly

Scorecard you can copy

Score each shortlisted plan from 1–5. Anything under 20 total usually needs a second look.

Criterion	Weight	What “5” looks like
PHP / workers	High	Modern PHP, adjustable limits, enough workers for admin and front end
Backups	High	Daily off-site, self-service restore, downloadable copies
Staging	Medium	Included staging with easy sync
Support quality	High	WordPress-aware help outside business hours
Security tooling	Medium	SSL, malware tools, SSH/SFTP when needed
True cost	High	Renewal price still fair after discounts expire

When shared hosting is no longer enough

Move up if you regularly see any of the following:

503 errors or “resource limit reached” messages during normal traffic
WooCommerce checkout timeouts while CPU on the plan is shared with other accounts
Host blocks tools you need (object cache, custom cron, composer workflows)
Support keeps asking you to disable plugins instead of raising account capacity

At that point, compare a WordPress-ready VPS instead of buying another “unlimited” shared plan.

Moving host without creating a second outage

A host change is a migration, not a DNS toggle. Use a staging rehearsal, lower TTL early, and verify SSL, forms, cron, and email after cutover. If you want a checklist, start with our WordPress migration how-to. If you would rather not own the cutover, BugShield can migrate the site at a confirmed price.

Hosting choice prevents a lot of emergencies. It does not replace monitoring, off-site backups, or a developer when a plugin update whitescreens the store. That is what Shield Pro and one-off fixes are for.

Quick answers about shared WordPress hosting

Is shared hosting suitable for a small WordPress site?

Usually, yes. A brochure site, smaller blog or lightly used shop can run well on shared hosting when the plan has sensible PHP limits, dependable backups and useful support.

Is managed WordPress hosting still shared hosting?

It can be. Many managed WordPress plans still share a server, but add staging, automatic updates, security tools and support that understands WordPress. Check the resources rather than relying on the product name.

Does unlimited shared hosting really have no limits?

No. Hosts normally apply limits to CPU, memory, PHP workers, storage or acceptable use. Ask for the actual resource allowances and what happens when the site reaches them.

What should I look for in a shared hosting backup service?

Look for off-site backups, enough retention to cover a problem you notice late, self-service restores and copies you can download. A backup is only reassuring once you know it can be restored.

How do I know when my site has outgrown shared hosting?

Regular 503 errors, resource-limit warnings, slow WooCommerce checkouts and blocked tools are common signs. If support cannot give the site enough capacity, it may be time to compare a managed or VPS option.

Originally published on BugShield.

Best VPS for WordPress: how to compare plans without brand bias

Wed, 05 Aug 2026 00:00:00 GMT

The best VPS for WordPress depends on the resources your site needs and who will maintain the server. A VPS gives you a separate server environment, but its CPU can still be shared. Compare the resource allocation and management terms before migrating from shared hosting.

Editorial note: this guide compares VPS tiers, management options, and technical requirements rather than ranking providers through affiliate partnerships.

When a VPS is the better WordPress home

Choose a VPS when shared hosting repeatedly hits resource walls, or when you need:

A plan with enough RAM and an explicit shared or dedicated CPU allocation for WooCommerce or membership traffic
Object cache, Redis, Elasticsearch, or custom worker processes
SSH-first workflows, deploy pipelines, or multiple environments
The ability to resize resources without changing hosting brands

If you only need a cheaper SSL and one-click staging, stay on stronger shared hosting first.

VPS tiers that describe real products

Tier	Who it fits	What you manage	Typical cost
Entry cloud VPS	Developers comfortable with panels or CLI	OS updates, stack, security patches	Low monthly fee, higher labour
Managed VPS	Owners who want server management included with their chosen resource allocation	App updates and content; provider handles more of the stack	Higher monthly fee, lower labour
Application platform / PaaS-style VPS	Teams that want Git deploys and scaling knobs	App code and env config more than raw servers	Usage-based pricing can surprise

Managed vs unmanaged: the decision that matters most

Unmanaged

You get a blank Linux box. That means freedom and full responsibility. Plan time for security updates, fail2ban or equivalent, firewalls, monitoring, and restores. If nobody on the team owns that work, do not buy unmanaged to “save money.”

Managed

Someone else patches the OS and often watches the server. Check exactly what “managed” includes: kernel updates, malware response, WordPress troubleshooting, and restore assistance are different services often sold under one word.

Resources: size for PHP, not marketing RAM

Shared-CPU plans divide processor access between customers; dedicated-CPU plans reserve processor capacity according to the provider's terms. DigitalOcean documents both models. Ask which model a quote uses, what happens during sustained load, and whether the plan can be resized. The word VPS alone does not guarantee dedicated CPU.

vCPU: WooCommerce and page builders need more workers than brochure sites
RAM: leave headroom for MySQL/MariaDB, Redis, and the OS
Storage: prefer fast SSD/NVMe and room for uploads plus local backup staging
Bandwidth / egress: image-heavy shops and CDNs can make egress the expensive line
Snapshots: useful, but not a substitute for application-aware WordPress backups

Stack checklist for WordPress on a VPS

Nginx or Apache with HTTP/2 or HTTP/3 enabled
PHP-FPM with enough workers and sensible timeouts
MariaDB/MySQL tuned for your data size
Object cache when plugins expect Redis or Memcached
Automatic TLS with renewal that fails loudly when DNS is wrong
Off-server backups on a schedule you have restored at least once

If you are building the box yourself, follow how to set up a server for WordPress before DNS cutover.

Comparison matrix

Question	Entry VPS	Managed VPS	App platform
Need SSH root?	Yes	Sometimes limited	Often limited
Comfortable patching Linux?	Required	Less so	Rarely
Need predictable WooCommerce CPU?	Good if sized right	Good if sized right	Good if plan reserves resources
Want panel tools (cPanel/Plesk/custom)?	Add-on or DIY	Often included	Usually proprietary UI
Lowest hidden labour cost?	No	Often yes	Depends on team skills

Cost model that avoids “cheap VPS” surprises

Budget the following over twelve months, not the first month:

Compute + storage + snapshots
Egress / CDN
Panel or managed fee
Monitoring and backup storage
Hours for updates, restores, and incident response

A £12 unmanaged VPS plus ten hours of emergency admin is more expensive than a managed plan you can operate calmly.

Migration notes

Moving to a VPS changes more than IP addresses. You must recreate cron, mail (or SMTP), PHP versions, and firewall rules. Rehearse on a staging hostname. After cutover, verify checkout, webhooks, and search console indexing.

Need help with the move? BugShield WordPress migration covers files, database, and URL cutover at a confirmed price.

A VPS does not replace application care. After you land on better infrastructure, keep off-site backups and monitoring in place so PHP fatals and downtime are not your first alert from a customer.

Quick answers about WordPress VPS hosting

When should I move WordPress from shared hosting to a VPS?

Consider a VPS when the site repeatedly reaches its resource limits or needs server tools your current host will not provide. Check whether the proposed plan shares CPU access or reserves dedicated CPU capacity; a VPS does not automatically guarantee dedicated CPU.

Should I choose a managed or unmanaged VPS?

Choose unmanaged only if someone can reliably patch Linux, secure the server, monitor it and recover it. A managed VPS costs more each month, but may cost less overall when your team does not have that time or experience.

How much RAM does a WordPress VPS need?

There is no useful one-size answer. A simple site needs far less than a busy WooCommerce store. Size the server for PHP workers, the database, caching and traffic, then leave headroom for busy periods.

Are VPS snapshots enough for WordPress backups?

No. Snapshots are useful for server recovery, but you should also keep off-server WordPress backups of both files and the database, with a restore process you have tested.

What costs are easy to miss when comparing VPS plans?

Include storage, snapshots, bandwidth, a control panel, management, monitoring, backup storage and the time spent maintaining the server. The cheapest monthly server is not always the cheapest site to run.

Originally published on BugShield.

How to set up a server for WordPress

Tue, 04 Aug 2026 00:00:00 GMT

A new VPS needs to be configured before it is ready to host WordPress. This guide covers the web server, PHP, database, security, SSL, backups, and final checks to complete before pointing your domain at it.

This guide assumes a Linux VPS and basic SSH knowledge. If you want the benefits of a VPS without managing the server yourself, start by comparing managed VPS options.

What you are building

A production WordPress server usually includes:

A web server (Nginx or Apache)
PHP-FPM with a supported PHP version
MariaDB or MySQL
TLS certificates with auto-renewal
Firewall and failed-login protections
Automated off-server backups
Basic monitoring and disk alerts

Step 1: Choose the base and access model

Create the VPS in a region close to your visitors.
Prefer Ubuntu LTS or another long-support distro your team already knows.
Disable password root login. Use SSH keys only.
Create a sudo user for day-to-day work.
Record the provider’s recovery or console access path before you tighten the firewall.

Step 2: Update and harden the OS

Apply system updates immediately, then reboot if the kernel changed.
Enable automatic security updates or a scheduled patch window you actually run.
Configure a firewall: allow SSH, HTTP, and HTTPS only unless you need more ports.
Install fail2ban or equivalent and protect SSH.
Set the timezone and NTP so logs and cron match reality.

Step 3: Install the WordPress stack

You can use a control panel or a lean CLI stack. Either way, verify the following:

Web server serving a temporary hostname or IP test page
PHP-FPM connected to the web server with phpinfo() then removed
Database server listening on localhost only
A dedicated database and user for WordPress with least privilege

Recommended PHP extensions for most modern WordPress sites include mysqli, curl, xml, mbstring, zip, gd or imagick, and intl.

Step 4: Create the site files and permissions

Create a web root such as /var/www/example.com/public.
Download WordPress core into that directory or deploy from your own repo.
Set ownership to the PHP/web user your stack expects.
Use directory permissions around 755 and file permissions around 644.
Keep wp-config.php restrictive and never world-writable.

For permission repairs later, see how to fix WordPress file permissions.

Step 5: Configure HTTPS before launch

Point a staging hostname or wait for DNS if you are launching a brand-new domain.
Issue certificates with Let’s Encrypt or your provider’s ACME tool.
Force HTTPS redirects only after the certificate is valid.
Test renewal with a dry run so certificate expiry does not become an outage.

If padlock warnings appear after go-live, use our SSL error how-to and mixed content guide.

Step 6: Hardening WordPress itself

Set unique table prefix and strong salts in wp-config.php.
Disallow file editing in admin with DISALLOW_FILE_EDIT.
Limit XML-RPC if you do not need it.
Create an admin user that is not named admin.
Put SMTP credentials in a proper mail plugin or transactional provider. Do not rely on bare mail().

Step 7: Backups, cron, and monitoring

System	Minimum setup	Pass/fail test
Backups	Nightly files + database to off-server storage	You restore a file and a DB table successfully
Cron	System cron hitting `wp-cron.php` or real cron with DISABLE_WP_CRON	Scheduled posts and WooCommerce tasks run
Uptime / health	External uptime check + disk/CPU alerts	You receive a test alert
Logs	Web, PHP, and auth logs rotated	You can find a fatal error within minutes

Step 8: Migrate or launch content

Copy files and import the database if migrating.
Search-replace URLs carefully for serialized data.
Update DNS with a lowered TTL planned days ahead.
Flush caches and confirm forms, login, checkout, and webhooks.
Leave the old host online briefly as a rollback path.

Full migration walkthrough: migrate WordPress to a new host. Prefer a developer-owned cutover? Request a BugShield migration.

Common setup mistakes

Opening MySQL to the public internet
Leaving WP_DEBUG_DISPLAY on for visitors
No swap or no disk alerts on small VPS plans
Only provider snapshots, never tested application restores
Pointing production DNS before HTTPS and mail are ready

After the server is live, infrastructure still needs care. BugShield monitoring and cloud backups watch the WordPress layer so the first alert is not a customer email.

Quick answers about setting up a WordPress server

Can a beginner set up a WordPress VPS?

It is possible, but this guide assumes basic SSH knowledge and comfort maintaining Linux. If nobody can own security updates, firewalls, backups and recovery, a managed VPS is the safer fit.

Should I use Nginx or Apache for WordPress?

Either can run WordPress well. Choose the web server your team knows how to configure and maintain, then make sure PHP-FPM, redirects, caching and logs are set up correctly.

Which firewall ports should a WordPress server expose?

Most installations only need SSH, HTTP and HTTPS open to the internet. Keep the database bound to the local server and open any extra port only when a real service requires it.

Is a provider snapshot enough to protect WordPress?

No. Keep scheduled off-server backups of the WordPress files and database as well. Test a restore so you know the data can be recovered before an emergency.

When should I point the domain at the new server?

Wait until WordPress, HTTPS, mail, backups and monitoring have been tested. Lower the DNS TTL ahead of the move, rehearse the cutover and keep the old host available briefly in case you need to roll back.

Originally published on BugShield.

Introducing BugShield: WordPress care that actually fixes things

Thu, 02 Jul 2026 00:00:00 GMT

BugShield is live. Here is why we built a platform for WordPress owners who are tired of chasing freelancers every time something breaks. Today we are launching a WordPress care platform built around one simple idea: when your site breaks, you should be able to hand it to someone who fixes it properly, without a messy email thread or a surprise invoice.

Why we built it

Most WordPress owners do not want to become developers. They run shops, agencies, blogs, and client sites. But WordPress still breaks: plugins clash, updates go wrong, checkout pages stop working, and someone has to sort it out.

BugShield brings that work into one place. Request a fix, pay a clear fee, chat with your assigned developer, and track progress on a kanban board. No hunting for a freelancer on a forum at 11pm.

More than one-off fixes

One-off tasks are where many owners start, but maintenance is where sites stay healthy. Our Shield Light and Shield Pro plans add:

24/7 uptime and performance monitoring
Off-site cloud backups with downloadable archives
Included bug fixes every month (2 on Light, unlimited on Pro)
A full activity log of backups, fixes, and vault access
Subscriber support that does not eat into your fix allowance

Shield Pro goes further with daily backups, on-demand backups, malware prevention, and priority response for sites where downtime costs real money.

Credentials done properly

Every fix needs access. BugShield includes an encrypted Password Vault tied to your site, not your login. Developers request credentials through the platform and every access is logged. You stay in control.

What is next

This is day one. We will keep shipping improvements to monitoring, backups, and the fix workflow based on what owners and developers tell us. If you run WordPress and want a calmer way to look after it, create your account and add your first site.

We are glad you are here.

Quick answers about BugShield

What is BugShield?

BugShield is a WordPress care platform for one-off fixes and ongoing maintenance. It brings developer conversations, site access, monitoring, backups and work history into one account.

Do I need a maintenance plan to ask BugShield for help?

No. You can create an account and submit a one-off fix without starting a subscription. Shield Light and Shield Pro are available when you want ongoing maintenance for a site.

What is the difference between Shield Light and Shield Pro?

Both plans include maintenance, monitoring, off-site backups, subscriber support and included fixes. Shield Pro adds daily and on-demand backups, unlimited fixes, malware prevention and priority handling. See the current plan comparison for the full details.

How does BugShield handle my WordPress credentials?

Credentials are stored in an encrypted Password Vault and attached to the relevant site. Developers request access through BugShield, and each time a credential is viewed is recorded.

Can I manage more than one WordPress site?

Yes. One account can contain several WordPress sites. Each site has its own workspace, credentials, fix requests, monitoring information and backup history.

Originally published on BugShield.