In this guide · 7 sections
Short answer
Check whether a patched version exists. If it does, back up and update now. If it doesn't, or the plugin is closed on WordPress.org, deactivate and delete it or replace it. For high or critical flaws that are being exploited, also check for new admin users, changed files and unknown plugins.
First, read the alert properly
Vulnerability alerts come from databases such as Wordfence Intelligence, Patchstack and WPScan, and from CSA's SingCERT, which publishes alerts and weekly security bulletins that often include WordPress plugin entries. Each alert should tell you four things. Find them before you act:
| What to find | Where it is | Why it matters |
|---|---|---|
| Affected versions | "Versions up to and including 3.2.1" | Compare with the version on your Plugins screen |
| Patched version | "Fixed in 3.2.2" | If it exists, updating is the fix |
| Severity (CVSS score) | A number from 0 to 10 | Tells you how fast to move |
| Who can exploit it | Unauthenticated, subscriber, contributor or admin | Unauthenticated flaws can be hit by anyone on the internet |
The severity bands come from the CVSS v3.1 specification: Low is 0.1 to 3.9, Medium 4.0 to 6.9, High 7.0 to 8.9 and Critical 9.0 to 10.0. A Medium flaw that needs an admin login is far less urgent than a High flaw anyone can trigger without logging in. Words such as "actively exploited" or "in the wild" mean attackers are already using it, so move to the steps below straight away.
What to do in the next hour
Work through these in order. They take under an hour on a typical small business site.
Take a backup you can restore
Use your host's snapshot or your backup plugin, and confirm it finished. Updates rarely break sites, but you want a way back if this one does.
Update the plugin to the patched version
Go to Plugins, update the affected plugin, then check the pages that use it: forms, checkout, booking, sliders. Clear any cache.
No patch yet? Deactivate it
If the alert has no fixed version, deactivate the plugin until one is released, and accept the lost feature for a few days. If the feature is critical, ask your developer about a temporary firewall rule.
Delete plugins you no longer use
Deactivated plugins still have files on the server. If you don't need the plugin, delete it, not just deactivate it.
Check the rest of the site is up to date
Update WordPress core, the theme and every other plugin while you are there. Attackers often chain an old flaw with a new one.
If it was High or Critical and exploited, check for compromise
Follow the checks in the next section before you call it done.
If an update breaks the site, our guide to fixing a WordPress update that broke your site explains how to roll back safely without reinstalling the vulnerable version for long.
Closed or abandoned plugins: when updating isn't an option
WordPress.org shows a red notice on plugins that have been closed. Its Plugin Handbook lists the reasons: author request, guideline violation, licensing or trademark issue, merged into core, or Security Issue. The reason is added to the notice 60 days after closure, and details are not shared outside the security team and authors.
A closed plugin gets no updates through WordPress.org. Even if it was closed for another reason, it will not receive future security fixes. Plugins that have not been tested with the last three major WordPress releases also show an out-of-date notice, which is a warning sign that the author has moved on.
Replace the plugin if
- It is closed on WordPress.org
- It hasn't been updated in over a year
- The vulnerability has no patch after a week
- A maintained alternative does the same job
Keep it for now if
- A patched version is out and you have applied it
- The author responds quickly in the support forum
- The flaw needs an admin login and admins use MFA
How to check whether your site was already hacked
If the flaw was High or Critical and you were running an affected version while it was being exploited, assume someone may have tried. These checks catch the common results:
Signs of compromise to check
If anything looks wrong, stop and follow our website hacked guide rather than deleting files one by one. Change all admin passwords and switch on MFA once the site is clean; our WordPress login security guide covers the settings.
Set up alerts and auto-updates so you hear first
You don't need to read vulnerability feeds yourself. Pick one of these and let it email you:
- A security plugin that checks your installed plugins against a vulnerability database, such as Wordfence or Jetpack Protect (which WPScan says uses its data and is free).
- Your host's security alerts, if your plan includes them.
- SingCERT's alerts for high-profile flaws, which CSA publishes on its website.
Since WordPress 5.5, the auto-updates setting lets you enable automatic updates plugin by plugin on the Plugins screen. Turn it on for well-maintained plugins with small, frequent releases. For plugins that run checkout or bookings, many owners prefer a weekly manual update with a quick test, so they notice if something breaks.
Do it yourself or get help?
A patched update on a simple brochure site is a safe DIY job: back up, update, test. Get help if the plugin runs payments or bookings, there is no patch, the plugin is closed, or any of the compromise checks look odd.
Our Website Security Hardening (S$290) removes risky plugins, applies updates, locks down logins and adds a firewall. For ongoing cover, the Care plan (S$129 a month) handles updates, monitoring and backups so alerts like this are dealt with for you.
Frequently asked questions
Deactivating stops WordPress from running the plugin, but its files remain on the server, and some flaws can be reached by requesting those files directly. If you don't need the plugin, delete it. If you need it back later, reinstall a patched version from WordPress.org.
It is no longer available for download and receives no updates through WordPress.org. Reasons include author request, guideline or licensing violations, being merged into core, or a security issue. The reason appears on the notice 60 days after closure. Treat any closed plugin as unsupported and plan to replace it.
Medium means a CVSS score of 4.0 to 6.9. Check who can exploit it: if it needs an administrator or editor login, and those accounts use strong passwords and MFA, updating within the week is reasonable. If unauthenticated users can trigger it, or it is being exploited, update the same day.
For most small sites, yes for well-maintained plugins, because unpatched plugins are a common cause of hacked WordPress sites. For plugins that handle checkout, bookings or memberships, a weekly manual update with a quick test catches the rare update that breaks something. Keep backups either way.
Compare the version shown on your Plugins screen with the affected range in the advisory, such as up to and including 3.2.1. If your version is the patched one or newer, you are not affected by that advisory. If you are unsure, update to the latest version anyway.