PHP Security Update: Fix CVE-2026-109618 and CVE-2026-109619 Safely

PHP security update checklist, reviewed October 21, 2026. If you run a PHP website, check the runtime serving that website today—not just the PHP command in your terminal. This guide walks through a controlled update for aaPanel, Ubuntu/Debian and AlmaLinux/Rocky Linux installations.
1. Choose the right patched PHP version
| Your PHP branch | Patched upstream release | What to do |
|---|---|---|
| 8.2 | 8.2.35 | Install this release or a newer supported patch release. |
| 8.3 | 8.3.36 | Update within the same branch when compatible. |
| 8.4 | 8.4.27 | Update the runtime and matching extensions. |
| 8.5 | 8.5.12 | Update every instance serving requests. |
| 8.1 or older | No regular upstream fixes | Obtain explicit vendor confirmation of a backported fix or migrate to a supported branch. |
These are upstream version targets from PHP.net. Distribution packages may carry security fixes without adopting these exact version numbers. Match the complete package version to your vendor’s advisory for both CVEs. “No updates available” is not proof that a server is fixed.
The PHP project describes the flaws as out-of-memory corruption and stale global state. Technical details are available in its CVE-2026-109618 advisory and CVE-2026-109619 advisory. This tutorial focuses on remediation, not exploit testing.
2. Find the PHP runtime your website actually uses
One VPS can have several PHP installations. A panel website might use PHP 8.3 while the shell uses 8.2. Inventory each domain, FPM pool, scheduled job, queue worker and container.
These commands inspect the command-line installation and common systemd services:
php -v
php --ini
php -m
systemctl list-units --type=service --all 'php*'
For WordPress, an administrator can check Tools → Site Health → Info → Server for the web runtime’s PHP version. Also inspect the site’s selected PHP handler in its hosting panel. A missing php shell command does not mean that the website has no PHP runtime.
For a custom application, use an authenticated administration or monitoring view to inspect its runtime. Do not leave a public phpinfo() file online: it exposes configuration details. Checking the CLI alone is insufficient.
3. Back up and check compatibility first
- Back up website files, uploaded media, the database and relevant PHP/web-server configuration. Keep a copy outside the VPS and confirm that it can be restored.
- Record the current PHP branch, enabled extensions, handler and FPM socket. Keep VNC or your provider console available.
- Check application, plugin and theme requirements. When possible, test the patch in staging before a short production maintenance window.
- If your application uses ionCube-encoded files, confirm compatibility with both the software vendor and the ionCube Loader documentation. A compatible Loader alone does not guarantee that every encoded application supports a different PHP branch.
A patch update within the same branch is different from moving from PHP 8.2 to 8.5. Do not turn an urgent security update into an untested major compatibility migration. If an older installation has no supported patched route, restrict access while preparing the migration with your vendor.
4. Update PHP in hosting panel
- Open the affected website’s PHP settings and note its selected version. Repeat this for other sites on the server.
- Open App Store, locate the installed PHP branch and refresh its available software information.
- Use the PHP package’s update action when offered. Confirm that the provided build contains the fixes—not merely that the panel itself is up to date.
- Review the installation log. Restore or re-enable required extensions only through the panel’s supported workflow, checking ionCube compatibility where relevant.
- Restart the affected PHP service through the panel and confirm the site’s selected handler has not changed unexpectedly.
- Verify the version from the running website and test its key functions.
5. Update distribution-managed PHP on Ubuntu or Debian
Use this route only when APT manages the actual web runtime. Refresh repository metadata and list the installed PHP packages:
sudo apt update
dpkg-query -W 'php*' 'libapache2-mod-php*'
Example only: a server using distribution-managed PHP 8.3 FPM with CLI, common files, MySQL, XML, cURL and mbstring packages. Replace the branch and package list with your installed runtime and extensions; include other installed PHP extensions that need matching updates.
apt-cache policy php8.3-fpm php8.3-common
sudo apt-get -s install --only-upgrade php8.3-fpm php8.3-cli php8.3-common php8.3-mysql php8.3-xml php8.3-curl php8.3-mbstring
Read the simulated transaction and compare the candidate package build with your distribution’s security notice. Once the proposed changes and fixed build are confirmed, run the same package list without -s:
sudo apt-get install --only-upgrade php8.3-fpm php8.3-cli php8.3-common php8.3-mysql php8.3-xml php8.3-curl php8.3-mbstring
sudo php-fpm8.3 -t && sudo systemctl restart php8.3-fpm
sudo systemctl status php8.3-fpm --no-pager
Run the restart only if the configuration test succeeds. The example service name does not apply to every installation. For Apache mod_php, update the corresponding libapache2-mod-php package and restart Apache after a successful apache2ctl configtest. Restarting Nginx alone does not replace PHP-FPM workers. See Ubuntu package management and the APT command reference.
6. Update PHP on AlmaLinux or Rocky Linux
For standard RPM-managed PHP, inspect the installed packages and repository security notices:
rpm -qa 'php*'
sudo dnf --refresh updateinfo list --security
sudo dnf upgrade --assumeno 'php*'
Confirm the vendor’s fixed package release for both CVEs and review the proposed transaction. Then apply the PHP updates:
sudo dnf upgrade 'php*'
sudo php-fpm -t && sudo systemctl restart php-fpm
sudo systemctl status php-fpm --no-pager
The restart assumes a valid configuration and a service called php-fpm. Remi parallel packages, custom repositories and panels can use different binaries and service names. Follow that provider’s advisory and update procedure. Do not reset module streams or switch repositories just to make a version number match. Red Hat’s DNF documentation explains package and security-update workflows.
7. Restart all affected workers and verify the website
For Docker deployments, rebuild or pull a verified patched image and recreate the running containers. Restarting an old image does not patch it. On Windows, use the PHP distribution supported by your stack and recycle the relevant FastCGI processes or application pool. For multi-node websites, repeat verification on every node.
- Confirm the website’s active runtime and full package build meet the upstream or vendor fix requirements.
- Test the homepage, administrator login, forms, uploads and database-backed pages. For shops or billing apps, use a safe test checkout rather than a real charge.
- Check scheduled tasks, background workers, extensions and ionCube-dependent features.
- Review PHP-FPM and web-server error logs. Look for new startup failures, missing extensions, 502 errors or permission issues.
For the PHP 8.3 FPM example:
sudo journalctl -u php8.3-fpm --since '15 minutes ago' --no-pager
If the website fails, use the console and logs to repair the configuration, extension or socket mismatch. Our Nginx 502 troubleshooting guide can help. Do not leave a vulnerable PHP build publicly exposed as a permanent rollback. If recovery requires restoring it, keep the affected application isolated until a patched runtime is ready.
Quick answers before you close the maintenance window
Does updating WordPress fix the PHP vulnerability?
No. WordPress and PHP are separate components. Keep WordPress updated, but patch the PHP runtime that executes it as well.
Is a firewall or PHP configuration change enough?
No. Treat access restrictions as temporary risk reduction while you install the security update, not as evidence that the underlying runtime is repaired.
Can I say the server is clean after patching?
Patching prevents the fixed flaws from remaining unaddressed; it does not establish whether a server was already compromised. If you find unexpected files, accounts or suspicious activity, preserve logs and investigate separately.
Completion checklist: backup checked; vendor fix confirmed; all relevant runtimes updated; affected services and workers restarted; web runtime verified; application tests passed. For ongoing maintenance, follow our Ubuntu server security baseline.
Reviewed October 21, 2026. Package names and commands are examples, not a universal installer; repository availability and vendor advisories can change. This article does not assert that every TudCloud-hosted application has been patched. Cover: conceptual PHP security-update illustration.
