Software updates and plugin security

• Website Security
• Updated: 4 October 2026
• About 10 min read

The four steps of an update routine

1. 1

   Take an inventory: know what you need to update

   You cannot update a component you do not know about. List everything that runs on your site: the content management system and its version, plugins, themes, the PHP version, the JavaScript and CSS libraries added to the page (jQuery, Bootstrap, editors, gallery scripts), other software on the server and scripts loaded from third-party services.

   : Enlarge

2. 2

   Remove what is not used

   The files of a deactivated plugin stay on the server and can be called directly by their address. Delete the plugins and themes you do not use, old version folders and trial installations. The fewer components you have, the smaller both the attack surface and the update workload.

   : Enlarge

3. 3

   Set up a safe update workflow

   Fear of updating usually comes from the worry "what if the site breaks?". The answer is not to put the update off but to make it something you can do with confidence: a backup first, a trial on a test copy if possible, then going live and a brief check.

   : Enlarge

4. 4

   Trust the source, but not blindly

   Every plugin and library you add to your site is someone else's code running on your behalf. Install only maintained components, and only from official sources.

   : Enlarge

Signs: how do you know you have fallen behind?

• Pending update notifications have piled up in the admin panel.
• The PHP version selected in the hosting panel is one that no longer receives security support according to the "Supported Versions" page on php.net.
• Library versions released years ago are visible in the page source.
• A plugin's last update is very old, or the plugin has been removed from the official directory.
• There are forgotten installation folders on the server with names like old, backup, test or v2.
• Nobody knows which components the site uses or when they were last updated.

Content management system, plugins and themes

• Install security updates automatically: Most systems can apply minor releases and security updates automatically. Keep this setting switched on.
• Plan major version upgrades: Try major version upgrades on a test copy first and identify incompatible plugins.
• Do not modify theme files directly: Make your changes in a child theme or in the customisation area; otherwise an update will wipe out your changes and you will start avoiding updates.
• Follow the announcements: Subscribe to the security announcements of the system you use.

For recommendations specific to WordPress, see the WordPress security guide.

JavaScript and CSS libraries

jQuery, Bootstrap, rich text editors, gallery and slider scripts are often added when the site is first built and never updated again. Old versions may contain known vulnerabilities (XSS in particular).

• List every <script> and <link> tag added to your pages; remove the ones that are not used.
• Upgrade libraries to their current supported versions; for major version upgrades, read the migration guide and test the site.
• Serving the library from your own server removes the dependency on a file that a third party can change.
• If you load it from a CDN, use Subresource Integrity (SRI): the browser will not run the script if the file's hash does not match the expected value.

<!-- Pinned-version address + integrity hash: if the file changes, the browser will not run it -->
<script src="https://cdn.example.com/library/1.2.3/library.min.js"
        integrity="sha384-PASTE_THE_HASH_FROM_THE_OFFICIAL_PAGE_HERE"
        crossorigin="anonymous"></script>

Take the integrity value from the library's official page or from the copy button the CDN provides; use an address with a pinned version (the hash will not match on addresses that change, such as "latest").

PHP and server software

Every PHP version receives active support for a set period, then security support only; after that, support ends and any vulnerabilities found are no longer fixed. Check the current status on the supported versions page on php.net.

• Upgrade PHP to a supported version from the hosting panel. Try it on a test copy first; old code may throw errors on a new version.
• If your software does not run on a newer PHP version, that is a sign that the software itself needs maintenance. Staying on an old version indefinitely is not a solution.
• If you manage your own server, install the security updates for the operating system, web server and database regularly. On shared hosting the provider does this; even so, you are the one who updates the choices left to you in the panel (such as the PHP version).

Dependency tracking

In projects that use Composer or npm, dependencies are written to a lock file together with their versions. The package managers' audit commands report whether there are known vulnerabilities in the installed versions.

# PHP dependencies: are there known vulnerabilities in the installed versions?
composer audit

# Which packages have a newer version?
composer outdated

# JavaScript dependencies
npm audit
npm outdated

• Keep the lock files (composer.lock, package-lock.json) under version control; that way it is known which version is installed.
• Run the audit regularly; automate it if you can.
• In projects that do not use a package manager, keep a simple inventory file: component, version, source, date of last update.
• The vendor and node_modules folders should not be accessible over the web; keep them outside the web root if possible.

Supply chain risk

Supply chain risk is when a component you trust becomes harmful itself: a plugin changes hands and its new owner adds unwanted code, the developer's account is taken over, or a backdoor has been planted in a copy of a paid plugin that is distributed "for free".

• Official sources only: Get plugins and themes from the official directory or directly from their developer.
• Do not use unlicensed (nulled) copies: These copies are the files most likely to contain malicious code, and they cannot receive updates.
• Choose maintained components: Look at the date of the last update, the supported versions and the replies given to issue reports.
• Fewer components: Instead of installing a large plugin for a small job, ask whether it is needed at all.
• Limit external scripts: Every third-party script you add to a page (chat, analytics, advertising) runs on your site with full privileges. Keep the ones you need and restrict the sources with a CSP.
• Observe after updating: If you see unexpected outbound links, new administrator accounts or unfamiliar scripts after an update, roll the update back and investigate.

A safe update workflow

1. Take a backup: Files and database. See Website backup and monitoring.
2. Read the release notes: Is it a security fix, and is there any change in behaviour?
3. Try it on a test copy: On a copy of the site if possible; if not, at a low-traffic time.
4. Update and check: Try the critical flows such as the home page, forms, login, payment and the admin panel; look at the error log.
5. Record it: What was updated, when, and to which version? If a problem comes up, knowing what changed speeds up the rollback.

Installing security updates within days and the rest on a regular schedule (e.g. once a month) is a reasonable routine. When a critical vulnerability is announced, do not wait for the schedule.

What can you do with software that cannot be updated?

Sometimes an update is not possible straight away: the developer of the software is no longer around, the new version is incompatible with your customisations, or the migration needs a budget. This is not a permanent solution, but there are things you can do to reduce the risk until the migration is complete:

• Narrow the access: Protect the admin panel with an IP restriction or an extra password layer; switch off unused features and endpoints.
• Put a filter in front: A WAF can block requests aimed at known vulnerabilities before they reach the server. This does not replace the patch; it buys time.
• Isolate it: Do not keep the old software in the same hosting account as your other sites; if it is compromised, the damage should stay limited to it.
• Reduce privileges: Keep the database user's privileges and the writable folders to a minimum; disable execution in upload folders.
• Back up and monitor more often: Check file changes daily.
• Put the migration on the calendar: A decision to "leave it as it is for now" can last for years. Set a date and a person responsible for moving to the new version or to different software.

Common mistakes

• Switching off or ignoring update notifications.
• Updating the core and forgetting the plugins and themes.
• Leaving the old version in another folder on the server "just in case".
• Updating without a backup, at the busiest time of day.
• Adding libraries once and never recording their versions.

Checklist

• There is a component inventory: CMS, plugins, themes, libraries, PHP version.
• Security updates are installed automatically or within a few days at the latest.
• Unused plugins, themes and old installation folders have been deleted.
• The PHP version receives security support.
• JavaScript libraries are up to date; those loaded from a CDN have SRI.
• The dependency audit is run regularly.
• Plugins come only from the official source; there are no unlicensed copies.
• A backup is taken before each update, a check is made afterwards and a record is kept.

Frequently asked questions

Related guides

• WordPress securityUpdates, few and trusted plugins, administrator accounts, wp-config protection, XML-RPC and login limits.
• Server and hosting securitySFTP/FTPS, file permissions, directory listing, error display, sensitive files and database access.
• Website backup and monitoringFile and database backups, restore drills, file integrity, logs and uptime monitoring.
• Website security guide: where should you start?Threat types, layered defence, priorities and a roadmap to all the security guides.