Updating WordPress Plugins: What Happens If You Do Not

Almost every WordPress admin has a small number sitting next to Plugins. It bothers nobody. You click it away because something else is more urgent, and by the next login the number is bigger. The remarkable part is that nothing happens. The site loads, the contact form sends, the shop takes money. That is exactly the problem. The cost of doing nothing is invisible until it is not, and then it arrives all at once.

This article explains what actually happens between the update badge and the incident, from the point of view of the people who write those updates. We build WordPress plugins ourselves, we publish the kind of releases this is about, and we see what happens afterwards.

Why an update badge is not a request for tidiness

1. A security update is what makes the flaw public

This is the part almost nobody knows, and it turns the intuition around. While a security flaw sits undiscovered inside a plugin, nobody knows about it. The moment the developer closes it and publishes the new version, something new exists: a public comparison between before and after. WordPress plugins are licensed under the GPL, their source is open, and every version stays available in the directory. Putting two releases side by side and seeing which line changed is routine work.

So publishing a security update also publishes directions to the flaw in the old version. That is not an argument against updates. It is the strongest argument for updating quickly. The most dangerous period in the life of a security flaw does not begin when the flaw is written, it begins when it is fixed. Update three weeks later and you ran a documented weakness for three weeks.

2. Nobody attacks you, something scans you

The most common objection is that a site is far too small for anyone to bother with. That assumes a person at the other end who chooses. There is no person. What runs are automated scans working through address lists and looking for fingerprints: paths that only one particular plugin creates, version numbers in publicly readable files, responses that give away a specific release.

For that process it makes no difference whether your site has ten visitors or ten thousand. What is interesting is not your reach. It is the server, the mailbox for sending spam and the space for redirects. A small site is therefore not a worse target, only a less conspicuous one. That, incidentally, is why break-ins often go unnoticed for months.

3. A plugin is more than the code its developer wrote

Almost every larger plugin ships third-party libraries with it: for generating PDFs, processing images, connecting payments, drawing charts. They sit in the plugin folder and are delivered along with everything else. When a flaw becomes known in one of those libraries, whether the updated version ever reaches you depends entirely on the plugin vendor. You cannot see these dependencies in your admin, and you cannot update them yourself.

From a developer point of view that is a good share of our update work, and it is completely invisible from the outside. A release whose changelog says only that dependencies were updated looks like nothing at all and can still be the most important one of the quarter.

4. The most dangerous plugin is the abandoned one

A plugin that has had no update in two years is not harmless because nothing has happened. It is dangerous because nothing more will happen. If a flaw is found there, no update is coming, and as a rule you will not hear about it.

We saw how common this is during our own research. For a market overview we went through German-language comparison articles and looked up the recommended plugins at the source. In one current article with twenty recommendations, five of them were closed in the WordPress directory. The article still recommends them, and anyone who installed them sees exactly what they saw before in their plugin list: a name, a version number, no warning. A closed plugin does not disappear from your site. It only stops delivering updates.

How this looks from our side

We stand on the other side of this process, so here is the unglamorous part.

You need an address people can write to. Whoever finds a flaw has to be able to report it without going through a contact form that lands in sales. We run a dedicated security address for that. It is not a big thing to set up, and it is the difference between a report that arrives and a report that eventually goes public because nobody answered.

We would rather publish small and often than large and rarely. An example from this week: our version 2.3.0 came out on 17 August and 2.3.1 on 18 August, because the consent banner was being shown again to visitors who had already decided. No security flaw, just an annoyance. Something like that still goes out immediately instead of waiting for the next big package. The reason is practical: a release that changes one thing can be checked. A release that changes eight things leaves nobody able to trace the one change that broke the layout.

And the part vendors do not enjoy writing: updates sometimes go wrong. That is not theory, it is our daily work as much as yours. Anyone claiming their releases are risk free has either few users or a short memory. The right response to that is not updating less often. It is keeping the individual update small and recoverable. If a white screen appears on your site after an update, that is annoying and fixed in ten minutes. A break-in is not.

The phrase never touch a running system comes from a world where the system stood in a room and the door was locked. Your WordPress install stands on the internet. Its surroundings change daily even when you touch nothing: PHP versions, browsers, the WordPress core, and the tools of the people looking for old releases. A system that does not move does not become more stable in that environment. It only becomes older.

What the Cyber Resilience Act changes on 11 September

The Cyber Resilience Act is an EU regulation for products with digital elements, and software is one of them. From 11 September 2026 the reporting obligations apply: actively exploited vulnerabilities and severe security incidents have to be reported. The rest of the duties follow in stages.

For manufacturers it comes down to three things that used to be voluntary: handling vulnerabilities in an orderly way, providing security updates for a named period, and having a reachable contact point for both. Anyone who has ever tried to reach the developer of a plugin last updated in 2021 will recognise the problem being addressed here.

Two caveats belong in this honestly. First, the question of who counts as a manufacturer in the case of free open-source software is precisely the point that is still disputed. We describe it here, we do not decide it for you. This article is an assessment and not legal advice, and for your own situation there is no way around a professional review. Second, the CRA does not update your website. It changes what you may expect from a vendor, not who installs the update. That stays your job, and if you look after websites for clients, it becomes a contractual one.

In practice, for choosing a plugin: one that names neither a security address nor a support period is not automatically bad. But it tells you something about how much structure sits behind it, and from now on you get that information without having to ask.

Updating without taking your own site down

A backup you have restored at least once. A backup that has never been restored is a hope rather than a safeguard. Try it once and you will know how long it takes and whether it works at all. Which tools are worth using is covered in the article on WordPress backup plugins.

Automatic updates for security releases, manual for everything else. WordPress can update plugins on its own. For small corrective releases that is the right setting, because the time between publication and installation is what counts most there. For large version jumps that bring new features, a manual look pays off.

Thirty seconds in the changelog. If it says security fix, the matter is urgent and not negotiable. If it describes a new feature you do not need, it can wait until the weekend.

A test environment as soon as the site earns money. For a blog a backup is enough. For a shop or a membership area you want to have seen the update somewhere else before your customers see it.

A stocktake twice a year. Every plugin you no longer need is attack surface with no return. Deactivating is not enough, because the files stay on the server. Delete them.

How to spot a plugin that will leave you stranded

Common questions