Website owner guide · PHP

How to check your PHP version and update safely

An owner-side guide to checking PHP in WordPress, hosting panels or SSH, taking a full backup, and applying the October 2026 fixes for your environment.

Why this update matters

On October 21, 2026, PHP released fixes for CVE-2026-109618 and CVE-2026-109619. These runtime vulnerabilities can allow remote code execution without authentication on PHP installations serving web requests. Update the branch your site uses to a fixed release, or a vendor package revision that includes both fixes.

PHP branchFixed PHP.net release
PHP 8.58.5.12
PHP 8.48.4.27
PHP 8.38.3.36
PHP 8.28.2.35

PHP 8.1 and earlier no longer receive PHP.net releases: confirm a backported fix with your distribution/LTS vendor or move to a supported branch. PHP 8.2 reaches end of life on December 31, 2026; plan that migration too.

Official sources: PHP.net · 2026

1. Before making changes: take a full backup

  1. Save files, database and configuration

    Take a full backup of the site and its server or service. Include uploaded files, PHP settings and web server configuration. Keep a copy off the server and check that you can restore it.

  2. Prepare a test and maintenance window

    Record the current version, extensions, domains and pools used by each site. Test the update on a staging copy when possible and decide how to restore service if compatibility problems occur. If recovery requires a vulnerable runtime, keep the site offline until it is patched.

2. Check the PHP runtime your site actually uses

  1. WordPress

    In the dashboard, open Tools → Site Health → Info → Server and record the PHP version. This describes the website runtime; if the host uses distribution packages, also ask for the full package revision.

  2. cPanel or Plesk

    In cPanel, open Software → MultiPHP Manager and inspect every domain. In Plesk, open Websites & Domains → your domain → PHP Settings. Record the active version and handler; different domains may use different PHP runtimes.

  3. SSH: CLI and PHP-FPM

    On your own server, check both versions. CLI PHP may differ from the web runtime. If there is no unversioned php-fpm command, use the branch-specific binary, such as php8.3-fpm -v. For Apache with mod_php, also confirm the active module and package.

    php -v
php-fpm -v

  4. Ubuntu/Debian: inspect the full package revision

    This example uses PHP 8.3 with FPM; adapt package names to your installation. apt policy shows installed and candidate versions and their repository; dpkg -l lists PHP, extensions and the Apache module.

    php8.3-fpm -v
apt policy php8.3-fpm php8.3-cli php8.3-common
dpkg -l 'php*' 'libapache2-mod-php*'

Distributions can backport security fixes while retaining an older PHP version number. Ubuntu PHP 8.3.6 can therefore be patched: compare the full package revision and repository with the distribution notice, rather than relying on php -v. These are published fixed revisions; a later revision should be confirmed by the same vendor.

System and packageFixed package revision
Ubuntu 22.04 · php8.18.1.2-1ubuntu2.28
Ubuntu 24.04 · php8.38.3.6-0ubuntu0.24.04.13
Ubuntu 26.04 · php8.58.5.4-0ubuntu1.5
Ubuntu 26.10 · php8.58.5.9-0ubuntu2.1
Debian bookworm · php8.2 · DLA-4848-18.2.35-1~deb12u1
Debian trixie · php8.4 · DSA-6574-18.4.27-1~deb13u1

Ubuntu: USN-8948-1; older releases may require Ubuntu Pro. Debian: DSA-6574-1 for trixie and DLA-4848-1 for bookworm. The Debian tracker lists sid as unfixed at this guide’s cutoff. Do not apply package revisions from another distribution or OS release.

Official sources: Ubuntu · USN-8948-1 · Debian · DSA-6574-1 / DLA-4848-1

3. Follow the update path for your environment

Always start with the full backup in step 1. Follow only the option that matches your site, then check the website again after restarting or deploying.

Shared hosting: cPanel / Plesk

  1. Back up and ask the host for the patch

    Keep a full backup before switching PHP. If you only have customer access, ask the host to install the fixed package; selecting “8.3” or “8.4” alone does not prove that the patch is installed.

  2. cPanel: update EasyApache, then select the domain

    The administrator must update EasyApache 4 packages in WHM. Fixed versions are ea-php85 8.5.12, ea-php84 8.4.27, ea-php83 8.3.36 and ea-php82 8.2.35. Then select the domain in MultiPHP Manager and apply a compatible, patched branch.

  3. Plesk: update the runtime and PHP settings

    The administrator must install PHP updates through the Plesk installer, then select the runtime in the domain’s PHP Settings. The notice lists 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 for Linux; confirm availability with the provider for Windows or PHP 7.4–8.1.

  4. Confirm restarts and test each domain

    Ask the host to restart the PHP-FPM or Apache workers serving the site. Recheck the actual runtime and test ordinary login, forms and uploads.

Official sources: cPanel · EasyApache 4 · Plesk · PHP

Ubuntu / Debian and Ondřej’s PPA: apt

  1. Back up and identify the branch and repository

    With a full backup ready, compare apt policy with USN-8948-1 or the Debian notice. If Ubuntu already uses ppa:ondrej/php, verify the fixed 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 packages published for jammy and noble on October 21. Do not add an Ubuntu PPA to Debian or mix repositories to follow this example.

  2. Upgrade the installed branch’s packages

    Example for PHP 8.3 with FPM. Replace 8.3 with your branch and include the installed extension packages your application uses. With mod_php, also upgrade your branch’s libapache2-mod-php package. If no fixed candidate is available, resolve repository availability with the provider first.

    sudo apt update
apt policy php8.3-fpm php8.3-cli php8.3-common
sudo apt install --only-upgrade php8.3-fpm php8.3-cli php8.3-common

  3. Restart PHP-FPM if your site uses it

    Use the service for the branch actually serving the website; cover every relevant pool, service and server. This example is for PHP 8.3.

    sudo systemctl restart php8.3-fpm

  4. Restart Apache if your site uses it

    With mod_php, this restart loads the patched runtime. If Apache uses FPM, restart the matching FPM service too. Then check apt policy, the website and the logs.

    sudo systemctl restart apache2

Official sources: Ubuntu · USN-8948-1 · Debian · DSA-6574-1 / DLA-4848-1 · Ondřej Surý · Launchpad

Docker: official PHP images

  1. Back up persistent data too

    Before rebuilding, back up the database, uploads, volumes and configuration. A container image does not back up that data.

  2. Pin a fixed image tag

    Use php:8.5.12, php:8.4.27, php:8.3.36 or php:8.2.35 with the appropriate variant, such as -fpm or -apache. Preserve the OS variant and extensions your application needs. Example Dockerfile line:

    FROM php:8.4.27-fpm

  3. Rebuild and redeploy

    For Docker Compose services built from a Dockerfile, pull the updated base and rebuild without cache. For another orchestrator, publish and deploy the new image through its normal workflow. If Compose only uses image:, change the tag and pull the fixed image before recreating the service.

    docker compose build --pull --no-cache
docker compose up -d

  4. Verify every replica

    Check PHP inside the new containers and the runtime serving the website. Confirm that old replicas no longer receive traffic and test the application.

Official sources: Docker · Official Images / PHP · PHP.net · 2026

Laravel Forge

  1. Back up the server and application

    Save a full backup before applying changes. Laravel’s October 21 notice, updated at 17:12 UTC, distinguishes the update method by branch.

  2. PHP 8.5: Update PHP

    Open your server in the Forge dashboard and click Update PHP. Confirm completion on a patched revision and that the services restart.

  3. PHP 8.2–8.4: SSH and apt

    Per that notice, connect over SSH and use this guide’s apt procedure with your branch’s packages and service. Restart PHP-FPM and Apache where applicable; review other long-running application processes too.

  4. If you cannot update

    Laravel recommends powering down the server until the update can be applied. Preserve your backup first. For Vapor, the notice says to redeploy to pick up the updated runtime.

Official sources: Laravel · 2026-10-21

WordPress: the fix belongs at the host

  1. Back up all of WordPress

    Save files, uploads, database and configuration, and check restoration before changing the runtime.

  2. Update the PHP that runs WordPress

    Follow the hosting, apt or Docker path used by your installation. Updating WordPress core, a theme or a plugin does not fix these PHP runtime vulnerabilities. If your host manages the server, ask it to confirm both fixes.

  3. Return to Site Health

    Check Tools → Site Health → Info → Server again and request the full package revision for backports. Test dashboard access, forms, purchases and uploads used by your site.

Official sources: PHP.net · 2026

4. Verify the update before finishing

  1. Verify the web runtime and packages

    Confirm a fixed release or vendor backport, restarted workers, and every domain, server or replica. Updating CLI PHP does not prove that the website’s PHP has been patched.

  2. Test normal site functions

    Check pages, login, forms, uploads and payments as relevant. Review errors and keep the backup and a record of the versions applied.

Cloudflare: temporary protection while you update

  1. Confirm proxying: orange cloud

    Cloudflare reports automatic rule deployment starting October 21, 2026 at 03:02 UTC on all plans, including Free through Cloudflare Managed Free Ruleset. Confirm that DNS names serving the website are proxied, shown by an orange cloud.

  2. Pro, Business and Enterprise: confirm Block

    Confirm that Cloudflare Managed Ruleset is deployed and its protection rules are in Block mode. Review Security → Security Analytics → Events to check their activity.

A WAF is not a patch. It only covers traffic passing through Cloudflare and does not repair the server runtime; finish the PHP update even with active rules.

Official sources: Cloudflare · WAF

PHP.net interim mitigations: incomplete

Use these only with your administrator while preparing the patch, taking a full backup before configuration changes. They do not make a vulnerable installation safe.

  1. Set memory_limit=-1 administratively

    PHP.net advises removing PHP’s memory limit through php_admin_value so application settings cannot restore a finite limit. This is an FPM pool example; Apache uses php_admin_value memory_limit -1. Removing the limit may increase memory use, so the administrator should monitor server capacity.

    php_admin_value[memory_limit] = -1

  2. Limit POST size and disable upload progress

    In php.ini or server configuration, use post_max_size=8M without uploads, or 32M when uploads are needed, keeping upload_max_filesize lower. Set session.upload_progress.enabled=0 before request processing; ini_set() and .user.ini are insufficient. Adapt these example values to the site:

    post_max_size = 8M
upload_max_filesize = 2M
session.upload_progress.enabled = 0

  3. PHP 8.5: disable fatal error backtraces

    On PHP 8.5 only, also apply this setting in server configuration.

    fatal_error_backtraces = 0

  4. Restart every worker

    Restart all affected PHP-FPM or Apache services and confirm each site’s effective configuration. These measures cover only part of the problem; continue until the patch is installed.

No complete mitigation replaces the update. If the server cannot be patched, coordinate temporary shutdown with its owner.

Official sources: PHP.net · 2026

Need help? Hire us

We can help identify the runtime, prepare a backup, apply the update and check that your site still works.

Hire us to update PHPEmail Humberto

We only work on sites the owner authorizes in writing, with a full backup before making any changes.