DEV Community

JonPatchWarden
JonPatchWarden

Posted on

The Linux server patching checklist (2026 edition)

#security #linux #devops #sysadmin

Last week did the reminding for us. On October 21, PHP shipped emergency fixes for two unauthenticated remote code execution vulnerabilities ("php2shell", CVE-2026-109618 and CVE-2026-109619). Per CISA, they affect PHP installations serving web requests: Apache with mod_php (which PHP considers highest risk), PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. The same day, Node.js shipped security releases for the 26.x, 24.x and 22.x lines, including a Brotli decoder flaw (CVE-2026-111497) that can corrupt process memory and lead to RCE. On October 26, CISA added the PHP vulnerabilities to its Known Exploited Vulnerabilities catalog, meaning confirmed active exploitation.

Sources

1. Inventory what you actually run

  • List every server you own, including staging and test machines; check which of them are reachable from the internet.
  • On each server, list installed packages: dpkg -l (Debian/Ubuntu) or rpm -qa (RHEL/Fedora). These commands list what is installed; they do not tell you what is vulnerable. For that, compare against CVE data or your distro's security tracker.
  • Note where each runtime came from. PHP or Node.js installed from the distro repositories, or from a third-party apt/dnf repo such as NodeSource or the widely used PHP PPAs, updates through the package manager - once the repo maintainer publishes the fixed build. A runtime compiled from source, installed with a version manager like nvm, or baked into a container image follows a different update path and needs its own fix.

2. Check versions against the fixes

  • php2shell is fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 from the upstream PHP project. Upstream no longer provides security fixes for PHP 8.1 and older, though distro or extended-support channels may ship their own backports. For unsupported versions, CISA's advice is to take the affected systems offline until they can be patched or updated. Base that call on your vendor's advisory and your own exposure, not on the upstream version number alone - an older-looking version with a vendor backport can already be fixed.
  • The Node.js fixes land in 26.12.1, 24.22.1 and 22.23.4 (all released October 21 as security releases).
  • Distros often backport a fix without adopting the upstream version number. Check your distro's security tracker for the CVE ID instead of comparing version strings alone.

3. Patch, carefully

  • Prioritize internet-facing systems, as CISA recommends.
  • Prefer updating the affected packages over a full-system upgrade during an incident, and treat it like any other change: have a backup or snapshot, know your rollback path, and test the service afterwards.
  • If patching has to wait: for the php2shell case specifically, CISA notes a web application firewall may provide some protection until systems are updated. Treat that as a bridge, not a fix.

4. Verify the fix actually landed

  • Confirm the installed build is the vendor-fixed one (package version plus your distro's advisory, not just the upstream number).
  • Follow your vendor's instructions to make the fixed code live - typically reloading or restarting the affected services, and for containers rebuilding and redeploying the image. Note that not every reload swaps in the new code; the vendor advisory says what is required.
  • Rescan as a supporting check. A clean rescan supports that the vulnerable package is gone; it does not prove the host was never compromised.
  • Patching closes the hole going forward. If a server was exposed while vulnerable, check it for signs of compromise - CISA suggests watching for PHP worker processes launching shells or downloading tools.

5. Make it routine

  • Scan on a schedule rather than when someone remembers.
  • Route alerts somewhere you actually look (email, webhook).
  • Decide ahead of time which severities may patch automatically and which wait for a human.

The honest plug

That loop - scan installed OS packages against CVE data, patch the affected ones, rescan to check the fix - is what we built PatchWarden to do for Linux servers. It connects over SSH, scans every 6 hours, patches with one click after approval or automatically for severities you choose, upgrades only the affected packages, and verifies with a rescan. It works on OS packages managed by your package manager; it does not handle application-level dependencies (Composer, npm packages), containers, or runtimes installed outside the package manager - those need the separate paths described above. One honest caveat: we have not yet verified PatchWarden's coverage of these specific CVEs or of third-party repositories such as NodeSource and the PHP PPAs, so treat this article as the general workflow, not a coverage promise for your exact setup.

14-day free trial for one server, no credit card: https://www.patch-warden.com

[exit code: 0]

Top comments (0)