Light desk with ample empty space, with a laptop and compact computer at the right edge.

Critical PHP vulnerabilities: What to check and update now

Two critical PHP flaws can allow remote code execution without a login. Find the fixed versions and check whether your website is actually using the updates.

As of 22 October 2026

The PHP project released updates for two critical vulnerabilities on 21 October. The flaws can allow attackers to execute code remotely without logging in. If you run PHP applications, check the PHP version your website actually uses. Updating the CMS alone is not enough. Official PHP security announcement

Which PHP versions fix the vulnerabilities?

For supported PHP branches, these are the first upstream releases to include fixes for both flaws:

PHP branch First version with both fixes
PHP 8.2 8.2.35
PHP 8.3 8.3.36
PHP 8.4 8.4.27
PHP 8.5 8.5.12

PHP release announcement and update guidance

Distribution and LTS packages may show an older base version even when they already include the fixes. These security patches are known as backports. Check the vendor advisory and full package version for CVE-2026-109618 and CVE-2026-109619. The base version alone does not establish whether a system is vulnerable or patched. Red Hat’s explanation of backports

PHP 8.1 and earlier branches no longer receive regular security updates from the PHP project. You need a verified vendor backport or a move to a supported branch. Because of the severity of these flaws, the PHP team has exceptionally provided minimal source-code backports for PHP 7.4, 8.0 and 8.1. These do not restore regular support. CERT-EU guidance on older PHP branches

PHP 8.2 also needs a longer-term upgrade plan: its regular security support from the PHP project ends on 31 December 2026. Plan that migration alongside the immediate patch. PHP support schedule

Which systems should you check?

Check every PHP installation that handles web requests. This explicitly includes PHP-FPM, Apache with mod_php, CGI, FrankenPHP and LiteSpeed. The PHP team considers mod_php the highest-risk setup. That does not mean other configurations are safe. Include administration interfaces, appliances and other products that embed PHP. CERT-EU guidance on affected systems

For WordPress sites, an up-to-date WordPress installation and current plugins do not prove that the underlying PHP version is patched. WordPress is not planning a separate update for these two issues. PHP itself needs updating; on a hosted service, that falls to the responsible operator. WordPress security notice

Laptop with abstract code-like lines and a green progress bar beside a compact computer on a light desk.

What causes the two vulnerabilities?

Both flaws affect the PHP runtime. The PHP advisories rate each as critical, with a CVSS v4.0 score of 9.2 out of 10.

CVE-2026-109618: An out-of-memory condition can interrupt a request before PHP has fully prepared its internal data. Request cleanup can then corrupt memory. For Apache with mod_php, the PHP team describes a demonstrated attack that requires no login and can take effect before the application code runs. PHP advisory for CVE-2026-109618

CVE-2026-109619: Internal state from a request can retain references to memory that has already been freed. When the same worker handles a later request, it may use that stale state. This can also lead to code execution. The conditions depend on the way PHP is deployed and on the application. PHP advisory for CVE-2026-109619

Five checks for your PHP update

The UK’s NCSC recommends identifying PHP systems, prioritising those exposed to the internet and applying updates as soon as possible. Check vendor guidance for products that embed PHP too. NCSC recommended actions

  1. Find the systems and assign responsibility. List websites, applications, administration interfaces and containers that use PHP. Identify who is responsible for each one.
  2. Check the right PHP installation. Establish the PHP and package versions used by the web service. A command-line version check may refer to a different installation.
  3. Verify both fixes. Compare the package version with the PHP release or the vendor advisory for both CVEs. If you use a hosting service, ask the operator to confirm the status.
  4. Check the running processes. After updating, confirm that all affected workers or containers are using the fixed code. Follow the vendor’s restart and deployment instructions.
  5. Record the result and keep monitoring. Document the system, package version, time and findings. Investigate suspicious activity separately: a successful patch does not tell you whether an attack happened beforehand.

The update procedure depends on your hosting service and installation. Follow your vendor’s product-specific instructions.

What if you cannot update immediately?

The PHP team lists temporary configuration changes that reduce exposure to particular attack paths. They explicitly do not make an installation fully safe. Changing a single upload setting is therefore not a complete solution. Agree any temporary measures with the team responsible for the system and follow the full technical guidance. PHP guidance on temporary measures

If the fix cannot be applied immediately, CERT-EU recommends considering temporary isolation of internet-facing applications until the fix has been applied and verified. Decide what restrictions are needed for the particular system. CERT-EU guidance on temporary isolation

Who is responsible for the update at your provider?

For self-managed applications, patching is the responsibility of your IT team or the operator you have appointed. For managed services, it should be just as clear who assesses the flaw, applies the fix and checks the running processes afterwards.

Ask your IT team or hosting provider directly: Do our PHP systems include the fixes for CVE-2026-109618 and CVE-2026-109619 — and are our web applications already using them?

You might also be interested in