SKYLINE Knowledge Base

Cybersecurity

A Monthly PHP Patching Routine for Small Businesses: Watch, Back Up, Test, Update, Verify

PHP and Debian shipped PHP security updates almost every month in 2026. A simple routine to apply them safely, plus a fast path for critical fixes.

Published
Reading time
7 min read

If your business runs a website, shop or internal tool on PHP, security updates are not an occasional event. In 2026 PHP published security releases in May, June, July (twice), September and October, and Debian followed with updated php8.4 packages for Debian 13 on 8 May, 4 July, 31 July, 25 September and 21 October. A small team cannot react to each one from scratch. What works is a fixed monthly routine that everyone knows, plus a fast path for the rare critical release. This guide lays out both for servers running Debian or Ubuntu.

1. Know what you run

Patching starts with an inventory. For each server, write down the operating system release, every PHP version installed, which sites use which PHP-FPM pool, and the applications on top (WordPress, Laravel, Drupal and so on). These commands collect most of it:

cat /etc/os-release
dpkg -l 'php*' | grep '^ii'
ls /run/php/
systemctl list-units 'php*-fpm.service'

Note the support status too. Debian 13 (trixie) ships PHP 8.4 and receives Debian Security Advisories (DSA). Debian 12 (bookworm) ships PHP 8.2; its regular support ended in July 2026, and its fixes now come from the Debian LTS team as DLA advisories until 30 June 2028. Debian 11 (bullseye) left LTS on 31 August 2026: servers still on it should be upgraded, not patched. Upstream, PHP 8.2 receives security fixes until 31 December 2026 and PHP 8.1 is already end of life.

2. Subscribe to the right sources

  • PHP releases: the low-volume php-announce list (subscribe by emailing php-announce+subscribe@lists.php.net) or the news feed at https://www.php.net/feed.atom.
  • Debian 13: the debian-security-announce list (DSA).
  • Debian 12: the debian-lts-announce list (DLA).
  • Ubuntu: Ubuntu Security Notices. Ubuntu backports fixes into its own PHP builds, so compare against its notices, not php.net version numbers.
  • Applications: your CMS or framework's release announcements, and composer audit for Composer-based projects.

Route these to a shared mailbox or channel that someone reads, not to one person's inbox.

3. The monthly routine

Pick a fixed day, for example the first Tuesday of the month, and a quiet time window. Then:

  1. Review what was announced since last month and note the fixed package versions from each advisory.
  2. Back up files and databases, and check that last month's backup actually restores. A backup you have never restored is a hope, not a plan.
  3. Patch staging first, if you have one, and run the checks from step 5.
  4. Update production:
sudo apt update
apt list --upgradeable 'php*'
sudo apt upgrade

If you only want the PHP packages for one version in this window, upgrade just the installed ones:

sudo apt install --only-upgrade $(dpkg-query -W -f='${Package}\n' 'php8.4*')

With --only-upgrade, apt upgrades packages that are already installed and ignores the rest.

  1. Restart and verify:
sudo systemctl restart php8.4-fpm
systemctl is-active php8.4-fpm
apt policy php8.4-fpm          # Installed should equal the advisory's fixed version
sudo needrestart -r l          # list services still using old libraries

Restart Apache as well if a site uses the Apache module (sudo systemctl restart apache2). needrestart, from the package of the same name, checks which daemons need a restart after library upgrades; -r l only lists them. Then open each site, log in, submit a form, complete a test checkout if you sell online, and look at the PHP and web-server error logs for new errors.

  1. Check the application layer: core, plugin and theme updates for your CMS, and composer audit --locked for Composer projects.
  2. Record the date, package versions before and after, and anything unusual. Three lines in a shared document are enough, and they turn next month's review into a quick comparison.

4. The fast path for critical releases

Some releases cannot wait for the monthly window. On 21 October 2026 Debian published DSA-6574-1 for PHP 8.4 in Debian 13 and the LTS team published DLA-4848-1 for PHP 8.2 in Debian 12, describing flaws that could result in the execution of arbitrary code; our article on those PHP vulnerabilities covers them in detail. Agree in advance what triggers the fast path, for example a vendor rating of critical, remote code execution, or confirmed exploitation, and who is allowed to patch production outside the window. For those, run steps 2, 4 and 5 the same day and catch up on the rest afterwards.

5. Plan the rollback before you need it

  • Prefer fixing forward. Rolling back a security update brings the vulnerability back. Most problems after a PHP patch are configuration or extension issues that can be corrected in place.
  • Know whether a package downgrade is even possible. apt list --all-versions php8.4-fpm shows the versions your configured repositories still offer; often only the newest is available. Installing a specific version with apt install package=version can downgrade packages and must be used with care.
  • Hold only briefly. sudo apt-mark hold php8.4-fpm stops a package from being upgraded. Use it only while a specific problem is being fixed, track it, and remove it with apt-mark unhold.
  • Keep restores ready. The dependable rollback for a broken site is restoring files and database from the backup taken in step 2.

Automating part of it

Debian's unattended-upgrades can install security updates daily. That shortens exposure but does not replace the routine: someone still needs to confirm PHP-FPM restarted on the new version, that the sites work, and that application-level updates are done.

What you should do

  1. Write the inventory of servers, PHP versions, pools and applications, and keep it current.
  2. Subscribe a shared mailbox to php-announce and to the advisory list for your distribution.
  3. Fix a monthly patch day and use the same steps every time: review, back up, staging, update, restart, verify, record.
  4. Define what triggers same-day patching and who may do it.
  5. Move servers off Debian 11 and off PHP 8.1 and older, and plan PHP 8.2 replacements before 31 December 2026.

On a Skyline Cloud VPS in Riyadh, the server's software is yours to patch, and there are no platform snapshots or platform-run backups, so the backup in step 2 must be your own; Skyline's web hosting plans include nightly website and database backups kept for 30 days.

Sources

Topics

SKYLINE Engineering

@skyline

The engineering team at SKYLINE Industrial Solutions. We publish field-tested guides drawn from real KSA and GCC deployments.

See author profile
More in Cybersecurity

Related: Skyline Nexus ERP guides

Nexus knowledge base →
Skyline Nexus ERP

Gulf & Middle East tax and e-invoicing guides

VAT, ZATCA e-invoicing and corporate tax explained for Saudi Arabia, the UAE and the wider GCC.

 Skyline Nexus ERP

Skyline Nexus ERP — cloud accounting & ZATCA e-invoicing

Our cloud ERP: accounting, invoicing, inventory and POS in one place. First month free.
SKYLINE engineering services

Need this implemented for you?

Reading is free — building it right takes a team. SKYLINE engineers ship Cybersecurity for Aramco vendors, banks, hospitals and government agencies across Saudi Arabia. Talk to us before you start.

Cybersecurity & Data Centre SACS-210, NCA ECC, SOC, 24/7 ops Firewall & Network Security Fortinet, Palo Alto, segmentation, ZTNA
Talk to a SKYLINE engineer Call +966 50 993 9334
Aramco Approved Contractor ISO 9001 · ISO 27001 SAMA CSF aligned NCA ECC ready 247+ KSA clients

Comments

0 total · 0 threads
Be the first to leave a comment.