Outdated plugins: how attackers find your site, and the fix

People imagine being hacked as being chosen. It is not personal. When a hole in a popular plugin is published, scripts start visiting every site they can find within days, sending the one request that tests for that plugin at that version. If the answer comes back, the exploit follows automatically. Your site gets hit because it exists and it was not updated, nothing more.

How it works, briefly

A researcher finds a hole in a plugin used on a million sites. The author fixes it and releases an update. The details get published so people know to update. From that moment, everyone who has not updated is running known-broken software, and the attackers know exactly what to send. The window between publication and mass exploitation is now measured in days, sometimes hours.

The sites that get hit are the ones where updates happen “when someone gets round to it”.

How to know if you are exposed

• The plugins page in your admin shows what has an update available. That list is your exposure list.
• Site Health in WordPress flags plugins with no author activity, and old PHP versions.
• A vulnerability feed. Services like Patchstack and Wordfence publish which plugin versions have known holes. Some security plugins check your installed versions against these lists and email you.
• Our scanner reads the WordPress version, and where a site exposes them, theme and plugin signals, and flags what is out of date. That is what an attacker’s first request learns too, so it is worth knowing what it shows.

Plugins that have not been updated by their author in two years are exposed in a different way: nobody will fix the next hole. Those need replacing, not updating.

The monthly routine, one hour

1. Backup. A fresh one, before touching anything, stored off the server.
2. Update on staging first if you have one. If you do not, that is the first thing to set up, because it turns updates from a risk into a routine.
3. Update core, then plugins, then the theme. Read the changelog for anything marked security: those go first, and they go today rather than at month end.
4. Open the site and click through the pages that matter: home, a service page, the contact form, checkout if there is one, and the admin.
5. Replace the abandoned. Anything not updated by its author in two years, or with a published hole and no fix, gets swapped for a maintained alternative.
6. Delete what is unused. Deactivated plugins and unused themes are files an attacker can still reach.
7. Note what changed, so if something breaks next week you know where to look.

Automatic updates

Turn them on for minor WordPress core releases, which are security releases, and for plugins from authors with a track record of not breaking things. For everything else, the monthly routine. Automatic updates for a large plugin on a site with no staging copy will eventually break the site at three in the morning, so this is a judgement, not a rule.

When a hole is published in something you use

Update that day. If no fix exists yet, deactivate the plugin until one does, or put a firewall rule in front of the request it exploits. Your firewall provider will often have the rule within hours of publication; that is a large part of what the managed rules are for.

The honest summary

Almost no site we have cleaned was hit by a new or clever attack. They were hit by a request that tested for a hole fixed months earlier. An hour a month closes that door. It is the least glamorous part of looking after a website and the one that prevents the most damage, which is why it is the core of what a care plan does.