Critical PHP vulnerabilities: what website owners should do now

The latest status: patches are available

Checked on 22 October 2026: PHP released fixes for two critical remote code execution vulnerabilities on 21 October. If you received a hosting notice saying that no patch exists yet, that part is now out of date. The priority is to confirm that the PHP package serving your website includes both fixes.

RCE means an attacker may be able to execute code on the server remotely. Treat this as urgent maintenance, but do not confuse a vulnerability warning with evidence that your own website has been compromised.

• PHP: official security announcement, 21 October 2026

Which PHP versions contain the fixes?

The table shows the first upstream releases containing both fixes. Install the relevant patched release or a newer supported security release, after checking compatibility with your application.

Linux vendors can backport fixes while keeping an older base version. For example, Ubuntu lists 8.3.6-0ubuntu0.24.04.13 for Ubuntu 24.04. Check the full package revision against your vendor’s advisory; the short PHP version alone is not conclusive.

• PHP: patched releases
• Ubuntu: fixed package revisions (USN-8948-1)

What do the two vulnerabilities affect?

CVE-2026-109618 concerns memory corruption during out-of-memory handling. CVE-2026-109619 concerns stale internal state reused across requests. Both can lead to remote code execution without authentication under the conditions described in the official advisories.

PHP calls on all installations serving web requests to update, including Apache mod_php and PHP-FPM. The exact attack conditions vary with the runtime, application and configuration. A claim that every PHP server has already been hacked goes beyond what these advisories establish.

• PHP advisory: CVE-2026-109618
• PHP advisory: CVE-2026-109619

Is disabling upload progress enough?

No. Setting session.upload_progress.enabled = Off only blocks confirmed session-related paths for CVE-2026-109619. It does not fix every variant or CVE-2026-109618. A patched PHP package is still necessary.

If your administrator uses this temporary measure, it must apply before request parsing through php.ini, an FPM pool or server configuration, followed by a restart of every worker. PHP explicitly warns against relying on ini_set() or FPM .user.ini for this purpose. Ask who owns the actual patch rollout and when it will be completed.

• PHP: scope of the temporary mitigation

What about WordPress and older PHP branches?

This is a PHP runtime issue, not a WordPress plugin vulnerability. Updating WordPress, themes or plugins does not replace the PHP patch. WordPress’s own announcement asks site owners to check with their host. Its Site Health screen, under Info and Server, can help identify the web runtime.

PHP 8.1 and older are outside normal upstream support. A vendor may provide backported fixes, but that coverage must be verified. PHP 8.2 security support ends on 31 December 2026, so a longer-term upgrade also needs a place in the maintenance plan.

• WordPress: critical PHP security release
• PHP: supported versions and end dates
• Ubuntu: vendor-maintained security fixes

A practical checklist for your website

Use this checklist with the person who maintains your hosting. Record the result for each site, subdomain and separate application, rather than closing the task after one control-panel change.

• Identify the running environment List the PHP version and package, hosting account, FPM pool or container serving each site. A command-line php -v result may describe a different runtime.
• Prepare a recovery path Confirm a recent backup and a tested restore procedure. Agree a short maintenance window and identify the person responsible for checking the site afterwards.
• Apply and verify both fixes Ask for the package revision, vendor advisory and rollout time. Have the administrator restart or replace every affected worker and check that no old pool or container remains active.
• Test the business-critical flows Check login, contact forms, checkout, file uploads and scheduled work where applicable. Record any failures and the time they appeared so the maintainer can investigate.
• Keep evidence if something looks wrong Unexpected files, new administrator accounts or unusual outbound traffic deserve investigation. Preserve relevant logs; installing a patch does not by itself remove an existing compromise.

A message you can send to your hosting provider

Hello, could you confirm whether the PHP runtime serving our website includes the fixes for CVE-2026-109618 and CVE-2026-109619? Please share the full package version, the relevant security advisory and when the update was applied. Have all affected workers been restarted, and are any older pools or containers still serving requests? If only a temporary configuration change has been applied, when will the patched package be deployed?

Keep the reply in your maintenance records. If the answer only says “the upload progress setting was disabled”, ask for confirmation of the package update too.

Make the update part of an ongoing maintenance plan

For future incidents, agree who monitors security notices, who can update production and who verifies the result. A named owner and a small, repeatable checklist make urgent updates easier to complete.

If you need help checking your website’s runtime, planning a compatible upgrade or reviewing application security, share your setup with Pixel Shield. We can first clarify the scope and the evidence needed to verify the work.

• Discuss your website with Pixel Shield
• Website security checklist for small businesses