Keeping Software Up to Date: Learning About New Versions, Getting Them, and Putting Them Live

Vulnerability articles almost always end with “update to the latest version.” Ours do too. But if you don’t know what to update, where to get it, or how to put it into production, you get stuck.

This article splits the software that runs a website into layers and covers how to learn about new versions, how to get them, and how to put them live. It is the fourth of four articles on website security basics. The second half has a lot of commands for engineers.

Who updates what

There isn’t just one thing to update. Under the site is the OS; on top of it run PHP or Node.js and the database; above those sit the CMS core such as WordPress, plugins and themes, libraries installed with Composer or npm, and Docker images. Office routers, VPNs and firewalls need updating too. The list you made in the first article, checking your own website’s security, works as-is here.

Each layer has a different owner. On shared hosting the hosting company updates the OS, but on a VPS or in the cloud it’s you. Switching PHP or Node.js versions is usually the customer’s job even on shared hosting; the CMS core and plugins belong to the site owner, libraries and containers to whoever built the site, and network equipment to in-house staff or a maintenance company.

The gaps appear where the “who” is blank. It’s common for the hosting company to keep the OS patched while PHP stays on an old version until the customer switches it.

Learning about new versions

Official announcements are the reliable way to hear about updates. For WordPress, check Dashboard, then Updates, and the official releases page; for PHP, the official news and supported versions page. For software published on GitHub, choose Releases and Security alerts under the repository’s Watch button to get notified. In Japan, JVN, run by JPCERT/CC and IPA, collects advisories in Japanese and offers RSS. endoflife.date is handy for support periods, though it’s a volunteer project.

News coverage is convenient but can be late or differ from the original. Even in the articles we wrote over the past two weeks, coverage and primary sources disagreed more than once (our WordPress article, our OpenSSH article). Read the original before deciding what to do.

Getting updates

From here on it’s for engineers. For the OS, use apt on Ubuntu or Debian, dnf on RHEL-family systems such as AlmaLinux or Rocky Linux, and apk on Alpine, checking what’s available before installing.

# Ubuntu / Debian
sudo apt update
apt list --upgradable
sudo apt upgrade

# AlmaLinux / Rocky Linux, etc.
sudo dnf check-update
sudo dnf upgrade

# Alpine
apk update
apk upgrade

For PHP and Node.js libraries, these commands list outdated packages and known vulnerabilities. After updating, commit the lock file (composer.lock or package-lock.json) along with the change, and install from the lock file in production.

composer outdated
composer audit
npm outdated
npm audit

WordPress can be updated from Updates in the admin screen, or with WP-CLI if you have command-line access on the server. With the core flaw found at the end of October, the update to the fixed version itself runs once through the old update code, so we wrote up the WordPress core flaw and what to do before updating separately.

wp core version
wp core update
wp plugin update --all

On shared hosting, PHP versions are usually switched in the control panel. Raising the version can break old plugins and themes, so try it first in a test environment, described next.

Putting updates live

Before touching production, back up both the files and the database; WordPress’s official upgrade guide recommends a backup before updating too (WordPress). Then update a test environment (staging) first and check that pages display and the main functions, such as forms and payments, still work. If all is well, update production, restart, and check again in production. If something goes wrong, restore from the backup.

The restart is the step people miss. Updating a package doesn’t change a program that’s already running; it keeps running the old version until restarted. During the OpenSSH flaw, there were warnings to restart sshd after updating (our OpenSSH article). For PHP, PHP-FPM or the web server needs a restart.

Automate what you can

The more you update by hand, the more likely something stalls. In WordPress, minor core updates, the maintenance and security releases, are automatic by default. Major updates are automatic by default on sites newly installed from 5.6 onward, while older sites keep their previous behavior unless configured (WordPress). Plugins and themes don’t update automatically by default; since 5.5 you can turn it on one by one in the Automatic updates column of the plugins list. If the hosting company or a plugin has disabled the feature, the column doesn’t appear at all (WordPress).

Ubuntu comes with unattended-upgrades preinstalled. By default it installs only security updates, once a day, and doesn’t reboot automatically (Ubuntu). That means updates that need a reboot, like kernel updates, are installed but don’t take effect until you reboot. You can test that it’s working with this command.

sudo unattended-upgrade -v --dry-run

For code managed on GitHub, Dependabot automatically opens a pull request that bumps a dependency to a fixed version when a vulnerability is found in it (GitHub Docs). All a person has to do is review and merge.

Automatic updates do occasionally break a site, though. If you automate, you need to be able to notice right away when something breaks and to roll back. That’s what uptime monitoring and backups are for (see the second article, how to notice your site has been hacked).

End of support can’t be fixed by updating

Finally, the most important point. Versions past end of support get no new fixes, so no amount of checking for updates will turn up a fixed version. As of November 8, 2026, PHP 8.1 and earlier are already unsupported, and 8.2 ends on December 31, 2026 (PHP). If your site runs on 8.2, plan the move to 8.3 or later before the end of the year.

Moving up from an old PHP version means first checking that the CMS, plugins and any custom code run on the new version. That is less an update than a small renovation. For sites that haven’t updated PHP yet, we covered the state of PHP2Shell and what to check now, and why it pays to list what you run shows in the breakdown of the 2026 surge in CVE counts. If you need help planning updates or moving to a newer PHP version, contact us.