Keeping servers patched to avoid vulnerabilities

A city's public works site goes down on a Thursday afternoon. The cause is not the CMS. It is a flaw in the server's web server software that was fixed six weeks earlier, and an automated scanner found the unpatched server within days of the fix being published. Most website compromises start this way: not with a clever new attack, but with a known weakness that already had a fix. This article covers what needs patching under your site, how to do it without downtime, and how to keep it from slipping.

Why speed matters more than it used to

When a vendor publishes a security fix, the fix itself tells attackers where the weakness is. Automated tools turn that into scans of the whole internet, often within hours. The window between "a fix exists" and "unpatched servers are being attacked" has shrunk from weeks to days. For government agencies, the US Cybersecurity and Infrastructure Security Agency (CISA) keeps a catalog of vulnerabilities known to be exploited in the wild, and federal agencies must fix those by set deadlines. It is a useful priority list for any organization.

What actually needs patching

A website runs on a stack of layers, and each has its own update stream:

The layers people forget are the ones underneath the CMS. A fully updated WordPress install on an operating system that stopped receiving fixes is still an unpatched server.

End-of-life dates to check now

A version that has reached end of life gets no more security fixes at all, so patching stops being possible. Dates worth checking against your servers:

• PHP 8.1: security support ended December 31, 2025. PHP 8.2 ends December 31, 2026.
• Amazon Linux 2: end of support June 30, 2026. CentOS 7 ended in June 2024.
• Ubuntu 20.04: standard support ended in May 2025.
• Drupal 7: community support ended in January 2025.

To see what a Linux server runs, these two commands are a quick start:

cat /etc/os-release
php -v

Patching without downtime

1. Test first. Apply the patch set to a non-production environment and run your normal checks: pages render, login works, search and forms work.
2. Use a planned window. Routine patches go in an agreed low-traffic window, typically overnight.
3. Patch one server at a time. Behind a load balancer, take one server out, patch it, check it, and return it before moving on. Visitors never see the change.
4. Keep a rollback. Know how you would undo the change before you make it: a snapshot, a previous machine image, or the previous package versions.
5. Do not wait for critical fixes. Advisories that are being actively exploited go through an emergency path, not the monthly window.
6. Record what changed. A short log of patch dates and versions makes the next audit, and the next incident, much faster.

Notes by platform

WordPress: core security releases install automatically by default on most sites, but plugins and themes do not, and the PHP version underneath is a separate decision. Drupal: the security team publishes advisories on a regular weekly window, on Wednesdays, which makes planning easier; see Drupal security updates and patch cadence. Government Drupal sites should plan major version moves early, since each Drupal major release has a fixed support end. Cascade: Hannon Hill patches the Cascade application itself. The servers that receive published files, and the CDN in front of them, are your hosting layer and need the same patching as any web server.

How eWay handles patching

On environments eWay manages, every patch set is validated in non-production first, then applied in an agreed low-traffic window, one node at a time behind the load balancer. Critical security advisories follow an emergency change path rather than waiting for the monthly window, and every production change has a tested rollback. Operating system, PHP, database, and CMS versions are moved in step, validated in test before production. During change freezes around high-stakes periods, such as elections or the start of term, only critical security patches proceed.

What to include in a support ticket

• The severity you would assign, P1 to P4 (see severity levels and response times)
• The advisory or CVE number, if you are asking about a specific vulnerability
• The affected sites or servers
• Any dates that matter, such as a freeze period or a compliance deadline

eWay customers can open a ticket in the support portal or email support@ewaycorp.com at any time. Related reading: updating WordPress and Drupal safely, WordPress plugins and Drupal modules: choosing, updating, removing, and Dev, Test, and Live environments.