PHP CVE-2026-109618 & CVE-2026-109619: What Website Owners Should Do Now

Update, 21 October 2026: The security patches are now available. PHP has confirmed that CVE-2026-109618 and CVE-2026-109619 are two critical vulnerabilities that can allow unauthenticated remote code execution. Update immediately to PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or install a vendor package that explicitly backports both fixes. Restart all PHP workers after updating.

PHP powers WordPress, WooCommerce and many custom websites. These vulnerabilities affect PHP itself, so updating WordPress, a theme or a plugin does not apply the fix. The PHP project says every installation serving web requests may be at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The highest confirmed risk is on mod_php.

This is no longer a notice about a future patch. Fixed releases have been published and updating is the only complete solution. PHP’s temporary mitigations reduce exposure to specific attack paths, but they do not make an unpatched server safe.

What website owners should do now

1. Ask your hosting provider or maintenance team to update PHP now. Request the installed package version and written confirmation that both CVE-2026-109618 and CVE-2026-109619 are fixed.
2. Confirm that a recent backup exists. It should include website files, the database and any server configuration needed for recovery.
3. Restart PHP after the package update. Long-running PHP-FPM, Apache, LiteSpeed or container workers must be replaced so that vulnerable code is no longer in memory.
4. Test the website after deployment. Check login, forms, checkout, payments, search, scheduled tasks and business-critical integrations.
5. Do not rely only on the PHP version shown by the command line. The website can use a different PHP-FPM pool, container or control-panel runtime. Verify the version that actually serves web requests.

You can send your provider this message:

PHP has released fixes for CVE-2026-109618 and CVE-2026-109619. Please confirm which PHP runtime serves our website, install PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or a vendor package that explicitly backports both fixes, restart all PHP workers and confirm when post-update testing is complete.

Which PHP versions contain the fix?

PHP branch	Vulnerable release	Fixed release
PHP 8.2	8.2.34 and earlier	8.2.35 or later
PHP 8.3	8.3.35 and earlier	8.3.36 or later
PHP 8.4	8.4.26 and earlier	8.4.27 or later
PHP 8.5	8.5.11 and earlier	8.5.12 or later
PHP 8.1 and older	End of life upstream	Upgrade to a supported branch or use a vendor package explicitly documenting both backports

Some Linux vendors keep the original base version number and add a distribution revision when they backport a security fix. In that case, do not judge the result from the short PHP version alone. Check the vendor security notice and the full installed package version.

How to update PHP

Take a backup and use your normal staging or maintenance process. The examples below show the common update paths, but package names and service names can differ between servers.

Ubuntu with the Ondřej Surý PPA

First confirm that the Ondřej repository is configured, then refresh package metadata and install the available updates:

grep -Rhs "ondrej/php" /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null
sudo apt update
apt list --upgradable 2>/dev/null | grep -E '^php'
sudo apt upgrade

Restart the runtime that serves the website. Replace 8.4 with the installed branch:

sudo systemctl restart php8.4-fpm
sudo systemctl restart nginx
# If PHP runs as an Apache module, restart Apache instead:
sudo systemctl restart apache2

php -v
apt-cache policy php8.4-common php8.4-fpm

If the fixed packages do not appear, do not switch to an unrelated repository. Confirm that the operating-system release is supported by the PPA and wait for the repository metadata to finish propagating, or use your vendor’s documented update path.

Debian with DEB.SURY.ORG

DEB.SURY.ORG is the Debian package repository maintained by Ondřej Surý. The update process is the same standard APT workflow:

grep -Rhs "packages.sury.org/php" /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null
sudo apt update
apt list --upgradable 2>/dev/null | grep -E '^php'
sudo apt upgrade
sudo systemctl restart php8.4-fpm
sudo systemctl restart nginx

php -v
apt-cache policy php8.4-common php8.4-fpm

Again, replace 8.4 with the branch used by the website. If Apache loads PHP directly, restart Apache instead of PHP-FPM and Nginx.

Ubuntu or Debian distribution packages

If PHP comes from the operating system’s standard repository, use the same APT update process. A distribution may backport the fix without changing the upstream version shown at the beginning of the package number:

sudo apt update
apt list --upgradable 2>/dev/null | grep -E '^php'
sudo apt upgrade
dpkg-query -W 'php*' | grep -E 'php(8\.[2-5])?-(common|cli|fpm)|libapache2-mod-php'

Compare the full package revision with the Ubuntu or Debian security notice, then restart the active PHP-FPM or Apache service.

RHEL, AlmaLinux, Rocky Linux or Fedora with Remi

For a standard Remi module installation, refresh metadata and update PHP packages from the already enabled stream:

sudo dnf clean metadata
sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm
sudo systemctl restart nginx

php -v
dnf list installed 'php*'

If PHP was installed as a Remi Software Collection, the package names look like php84-php-* and the service can be named php84-php-fpm. Update and restart that matching collection. Do not switch module streams during an emergency patch unless the application has been tested on the new branch.

Docker and Docker Compose

Updating PHP on the host does not update PHP inside a container. Change an exact vulnerable base tag such as php:8.4.26-fpm to php:8.4.27-fpm, or pull and rebuild the existing supported branch so that it resolves to the patched image:

docker compose pull
docker compose build --pull --no-cache
docker compose up -d --force-recreate
docker compose exec php php -v

The service may not be named php, so use the service name from your Compose file. If production is pinned by digest, update the digest and redeploy. Recreating the containers is necessary because pulling an image alone does not replace running containers.

cPanel, Plesk and managed hosting

• cPanel/WHM: use EasyApache 4 or the operating-system update interface to install the vendor’s PHP packages, then restart Apache and the relevant PHP-FPM services.
• Plesk: use Tools & Settings, Updates, Add/Remove Components, or the provider’s system update process. Confirm that every PHP handler assigned to a domain has been patched.
• Managed WordPress or managed cloud hosting: open a support ticket and request explicit confirmation for both CVEs. A generic statement that “security updates are automatic” is not the same as confirmation that the active runtime was replaced.

Windows and manually compiled PHP

Use the official Windows build or source release for PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12. Preserve the existing php.ini and extension configuration, replace the runtime using the deployment process for IIS, Apache or the application service, restart every PHP worker and verify the version from the web-serving environment. For PHP 8.1 and older, prefer migration to a supported branch. The PHP project has published minimal source backports for 7.4, 8.0 and 8.1, but those branches remain end of life.

How to verify the update

1. Check the PHP version in WordPress under Tools, Site Health, Info, Server, or through the hosting control panel.
2. Check the full operating-system package revision or container image digest, not only the CLI output.
3. Confirm that PHP-FPM, Apache, LiteSpeed or the containers were restarted after packages were installed.
4. Run a website smoke test covering forms, authentication, checkout, payments, cron jobs and integrations.
5. Record the update time, installed package version and test result. Remove any temporary public phpinfo() page used during verification.

Does this affect WordPress websites?

Yes, if the PHP runtime serving the WordPress site is vulnerable. The flaw is below WordPress in the software stack and can be reached before application code runs in confirmed configurations. Updating WordPress core, plugins or the theme does not patch PHP.

If the site is on managed hosting, the provider may already have deployed a vendor backport. Ask for the active runtime version, the vendor advisory or package revision and confirmation that workers were restarted.

What the two vulnerabilities do

• CVE-2026-109618: an out-of-memory condition can interrupt request processing while internal data is only partially initialized. Cleanup can then treat invalid data as valid.
• CVE-2026-109619: request-owned internal state can remain after its memory has been freed. A later request handled by the same worker can use that stale state before normal initialization resets it.

Both issues are rated critical at CVSS v4.0 9.2. The confirmed impact includes unauthenticated remote code execution with the privileges of the PHP web worker. Multiple workers or worker recycling may reduce the success rate of an attack, but they do not remove the vulnerability.

If you cannot update immediately

Apply PHP’s official temporary mitigations only as a short bridge to the update. The project recommends disabling session.upload_progress before request parsing and restarting every worker. It also documents specific controls for memory limits, upload sizes and PHP 8.5 fatal-error backtraces. These measures cover only known paths and are not a complete fix.

; Temporary mitigation, not a replacement for patching
session.upload_progress.enabled = Off

Do not rely on ini_set() or a per-directory .user.ini for this control, because the vulnerable request processing can happen before application settings are applied. Put it in the server-level PHP configuration or FPM pool and restart every worker.

What LibraFire can handle

We can identify the PHP runtime serving your website, coordinate the correct vendor update, test WordPress or custom PHP compatibility, verify critical user journeys and document the deployed version.

Last updated: 21 October 2026, after publication of the fixed PHP releases. Sources: PHP security advisory and release announcements, CVE-2026-109618 advisory, CVE-2026-109619 advisory, Ondřej Surý Ubuntu PPA, DEB.SURY.ORG PHP packages, Remi repository documentation and official PHP Docker image documentation.