What to do the day a WordPress plugin vulnerability is published

A new WordPress plugin vulnerability is published almost every day. Most need nothing more than the next routine update. A few need action today: the ones that are actively exploited, that need no login, or that sit in a plugin you run on dozens of client sites. This guide is a routine for that day: how to decide quickly whether a flaw matters to you, how to find every affected site, and what to do after updating.

Step 1: decide in five minutes whether it is urgent

Read the advisory itself (Patchstack, Wordfence or WPScan), not only the headline. Four questions decide how fast you move:

• Is it being exploited? An advisory that says attacks are seen in the wild moves to the top of your day.
• Does it need a login? A flaw that an anonymous visitor can use is far more dangerous than one that needs an administrator account.
• What can an attacker do? File upload, code execution or creating admin accounts is worse than a reflected XSS that needs a click.
• How many of your sites run it? One site is a task; forty sites is a project with a deadline.

If the answer to the first two questions is yes, treat it as urgent: affected sites today, not at the next maintenance round.

Step 2: find every affected site

You need two facts per site: is the plugin installed (active or not), and which version is it on. Inactive plugins count. The vulnerable code is still on the server and can often still be reached directly.

With WP-CLI this takes seconds per site:

wp plugin list --name=ninja-forms --fields=name,status,version

Without WP-CLI, check Plugins in wp-admin, or the version in the plugin’s readme.txt. Write the result down in one list: site, installed yes or no, version, fixed version. That list is your checklist for the rest of the day and your proof for the client afterwards.

Step 3: update the affected sites, most exposed first

Start with the sites that matter most if they are hit: webshops, sites with many forms or user accounts, and sites with a lot of traffic. Before each update, make sure a recent backup exists that you can actually restore.

Security updates are usually small, but not always. Some vendors ship the fix in a larger release with other changes. If the fixed version is a big jump, or the plugin handles forms or checkout, test it on a copy of the site first when you can, and check the key pages afterwards.

If you cannot update today, for example because the fix is not released yet or the update breaks something, reduce the risk instead: deactivate the plugin if the site can live without it for a day, or block the vulnerable endpoint in your firewall if the advisory names it. Tell the client what you did and why.

Step 4: test what the plugin does

An update that succeeds is not the same as a site that works. After updating, test the thing the plugin is for. For a form plugin, send a real test submission and check that the email arrives. For a shop plugin, run a test order up to payment. A form that silently stops sending can cost a client a week of leads before anyone notices.

Step 5: check whether the site was already hit

Updating closes the hole. It does not remove anything an attacker left behind before you updated. If the flaw was exploited before you patched, check each affected site for:

• administrator accounts you do not recognise;
• PHP files in the uploads folder, which should only hold media;
• recently changed files in plugins and themes that you did not update;
• unknown scheduled tasks, or redirects you did not set up.

If you find signs of a compromise, restore from a backup made before the attack window, update straight away, and change all passwords and the security keys in wp-config.php. Patching alone is not enough.

Step 6: tell the client, briefly

Clients rarely read security news, but they do notice when their agency was on top of it. A short note is enough: what the issue was, that their site was or was not affected, what you did and when. It turns an invisible task into visible value, and it belongs in your next maintenance report too.

Make the next one faster

• Keep a list of which plugins run on which sites, so step 2 takes minutes.
• Follow one or two advisory sources, not ten.
• Make sure every site has a backup you have actually restored once.
• Agree with clients in advance that urgent security updates happen outside the normal schedule.

How Verploy handles plugin vulnerabilities

Verploy shows known vulnerabilities in the plugins and themes of every connected site, so you see at once which sites are affected. Every update is checked, and the risky ones are tested on a copy first, including the forms and the checkout. Nightly backups come with a restore test, and if a site breaks after going live, Verploy rolls it back. More on WordPress vulnerability monitoring.