In short: With unattended-upgrades on Debian and Ubuntu and dnf-automatic on the RHEL family, Linux servers apply security updates on their own. For an update to take effect, affected services such as PHP-FPM must restart afterwards; check this with needrestart or the process start times. Third-party sources such as sury.org must be expressly released; containers and major version changes are not covered by the automation.
From patch to server: automation saves time
When php.net published the patches against PHP2Shell on 21 October 2026 at 4 p.m. German time, a race began for administrators. According to reports, distributions shipped their backports in some cases on the same day. Servers with automatic security updates could install the new packages at the next scheduled run without anyone having to intervene.
That is the good news. The less good news: installed does not mean effective. A PHP-FPM service that has been running for weeks keeps working with the old code in memory until it is restarted. And packages from third-party sources, containers or hosting panels with their own PHP management often remain untouched by the automation.
This article shows how to set up automatic security updates and supplement them so that they really protect in an emergency.
unattended-upgrades on Debian and Ubuntu
On Ubuntu, the package unattended-upgrades is installed by default and applies security updates. On Debian you install it as needed. It is controlled via two files under /etc/apt/apt.conf.d/.
sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades
The file 20auto-upgrades defines whether and how often package lists are updated and updates are applied. The value is the number of days; "1" means daily:
// /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
50unattended-upgrades states which sources updates may come from, whether a restart follows and who receives a message. By default, only the distribution's official security sources are released. According to the Ubuntu documentation, it is not enough to add another repository: it must also be in this list, otherwise the automation ignores it. This applies, for example, to the third-party repository sury.org, which according to reports provided PHP builds for all branches from 5.6 to 8.5. Background is in the article The sury.org repository.
A dry run that changes nothing shows whether everything is right:
sudo unattended-upgrade -v --dry-run
# Logs of the real runs
ls -l /var/log/unattended-upgrades/
dnf-automatic on RHEL, AlmaLinux and Rocky Linux
On the RHEL family, dnf-automatic takes over the same task. The configuration is in /etc/dnf/automatic.conf. According to the documentation, upgrade_type = security checks only updates with a security advisory, and apply_updates is off by default.
# /etc/dnf/automatic.conf (excerpt)
[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
reboot = never
sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers 'dnf-automatic*'
Besides dnf-automatic.timer, which follows the configuration file, there are timers that only notify, only download or always install. To begin with, the timer with a configuration file is the easiest to follow.
The underestimated part: restarting services
The package manager replaces files on disk. Running processes keep the old code in memory. For PHP this means: as long as PHP-FPM or Apache with mod_php has not been restarted, the vulnerability stays open.
| Tool | System | What it does |
|---|---|---|
| needrestart | Debian, Ubuntu | detects services with outdated files; on Ubuntu from 24.04 restarts them automatically by default |
dnf needs-restarting -s |
RHEL family | lists services that should be restarted |
Automatic-Reboot |
unattended-upgrades | restarts the server if an update requires it; off by default |
reboot |
dnf-automatic | never, when-changed or when-needed |
According to the Ubuntu documentation, services excluded by needrestart keep running with old files until a manual restart. So after every PHP update, check the start time of the processes, as described under Restarting PHP-FPM and all workers.
With backports the displayed PHP version number often stays the same. You prove the patch through the package changelog with the CVE numbers, for example with apt-get changelog or rpm -q --changelog. How this works in detail is shown in Debian and Ubuntu: is my PHP package patched?.
What the automation does not cover
Automatic updates are one building block, not complete patch management. Some areas need their own processes:
- Containers: PHP in Docker images is not updated by host updates. Rebuild images, recreate containers.
- Hosting panels: Plesk, cPanel and similar panels manage PHP partly through their own packages and mechanisms.
- Major versions: The move from PHP 8.2, which reaches end of support on 31 December 2026, to a newer version does not happen automatically.
- Applications: CMS, plugins and Composer dependencies have their own update paths.
- Oversight: Someone must read the automation's logs and error messages. A silently failing run is worse than none, because it feigns security.
How these parts grow into one process is described in Patch management as a process instead of firefighting.
Conclusion: automation yes, blind trust no
Automatic security updates belong on every Linux server that is reachable from the internet. PHP2Shell has shown how tight time can get: according to media reports, a first attack attempt was already observed on 17 October, four days before the patches. Anyone who still waits for a manual maintenance window afterwards loses valuable time.
But the automation only takes the installing off your hands. Restarting services, proving the patch level, containers, panels and the timely move to supported versions remain tasks someone must be responsible for. Define this responsibility in writing, and spot-check whether the automation's logs are actually read. Only the combination of automation and oversight makes updates reliable.
How does PHP SOS help?
- Set up: We configure unattended-upgrades or dnf-automatic to suit your servers, including released third-party sources.
- Secure restarts: We set up needrestart or equivalent checks and verify process start times after PHP updates.
- Close gaps: We include containers, panels and major version changes in a fixed maintenance routine.
- Oversee: Under the security maintenance contract, we check the automation's logs and report anomalies.
Frequently asked questions
Aren't automatic updates too risky on production servers?
Limited to the distribution's security updates, the risk is usually smaller than that of an open vulnerability. These updates are meant to fix errors, not bring new features. For critical systems, backups, monitoring and a test system are part of the picture.
Does unattended-upgrades restart PHP-FPM after an update?
Not necessarily by itself. On Ubuntu from version 24.04, the tool needrestart restarts affected services automatically by default, but excluded services keep running with old files. After every PHP update, check the start time of all PHP processes.
Are packages from sury.org or other third-party sources updated automatically?
Only if you expressly release the source. According to the Ubuntu documentation, it is not enough to add a repository; it must also be in the list of allowed origins of unattended-upgrades.
Does the automation also raise PHP 8.2 to 8.3?
No. Automatic security updates stay within the installed package versions. A change of the PHP major version, for example before the end of support for PHP 8.2 on 31 December 2026, remains a planned project with tests.
What about Docker containers?
Updates on the host do not update the PHP version in containers. Container images must be rebuilt or pulled again and the containers recreated.