CVE-2026-109618 and CVE-2026-109619: what should you do now?

Two critical PHP flaws now have patches. The immediate task is to identify the web runtime actually serving your application, deploy the fixes and verify every running worker. Updating application code alone does not update PHP.

The short answer

Treat this as a runtime change, not a routine application release. Find the PHP runtime, SAPI, full package revision and webserver configuration serving production traffic. Have the responsible operator deploy an official patched release or a vendor-confirmed backport. Restart the relevant workers and processes, then verify the running web environment and the flows your product depends on.

What happened on 20 and 21 October?

On 20 October, PHP gave advance notice of a security release scheduled for 21 October at 14:00 UTC. Both issues were rated CVSS v4.0 9.2. On 21 October, PHP published fixes and repository advisories for CVE-2026-109618 and CVE-2026-109619.

PHP confirms that both vulnerabilities can allow unauthenticated remote code execution. In practical terms, code may run with the web worker’s permissions without an application login. That threatens confidentiality, integrity and availability, but it does not prove that every deployment is exploitable or already compromised.

One flaw concerns invalid internal request state after memory exhaustion. The other concerns worker state that still refers to memory released by an earlier request. Both are PHP runtime defects, rather than faults that a framework update can remove.

Reuters reported precautionary website shutdowns by government organisations in the Netherlands and Finland, including the Dutch cybersecurity agency. This illustrates service disruption and precautionary action. It is not evidence that those organisations were compromised.

Which environments need attention?

PHP’s warning covers installations serving web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP considers mod_php the highest-risk deployment. Remote execution has been demonstrated there, including an attack path before application code runs.

Evidence varies by SAPI and CVE. For CVE-2026-109618, source analysis supports FPM susceptibility, but the advisory does not report a complete demonstrated FPM exploit. FrankenPHP is assessed as likely susceptible from source analysis. LSAPI application-specific exploitation is considered likely but unvalidated. For CVE-2026-109619, however, session-lifecycle RCE was validated against both mod_php and FPM, with application-dependent conditions. Other variants depend on configuration and state. Absence of a demonstrated exploit is not a reason to skip the patch.

Do not turn that warning into a claim that every PHP or WordPress site can definitely be taken over. Establish your actual configuration and patch status. Updating WordPress, Shopware, Laravel or Symfony does not itself replace PHP. Composer manages dependencies and platform constraints, not the installed PHP runtime.

Which releases contain the fixes?

Within each supported branch, use the following patched release or a later official release retaining both fixes. These are fixes for the two CVEs, not a security guarantee for your whole system.

A Linux distribution or LTS vendor may backport the fixes into a package whose visible PHP version remains older than upstream. Read the full package version and revision alongside that vendor’s advisory. Ask the hosting provider to confirm remediation of both CVEs in the environment actually handling requests.

PHP 8.1 and older no longer receive regular PHP-project releases. There is an important incident-specific exception: PHP made minimal source backports available for 7.4, 8.0 and 8.1. These do not restore regular support or automatically patch a vendor package. Obtain explicit vendor confirmation or move to a supported branch.

PHP 8.2 reaches end of life on 31 December 2026. Apply the immediate fixes and schedule a supported-branch upgrade. This release does not extend the support window.

An operational checklist for today

1. Inventory internet-facing PHP services, including older deployments and separate containers. Associate each runtime with an application and an accountable owner.

2. Establish who operates hosting and PHP. The product team identifies critical behaviour; the platform or hosting operator patches the runtime; external suppliers confirm the systems they control. Assign one person to track completion across the chain.

3. Record the active web runtime, SAPI, package revision and vendor status for both CVEs. A command-line interpreter can differ from the one serving HTTP traffic.

4. Follow the existing change procedure for backups or recovery points where needed. Plan recovery from a failed update without unnecessarily leaving the vulnerable service public.

5. Deploy an official fix or an approved, documented vendor backport to every relevant host, container and replica.

6. Restart the relevant PHP workers and processes. Updated files on disk do not prove that long-running processes use them.

7. Verify the active version or vendor package fix from the running production environment. Retain evidence in the change record without exposing diagnostic details publicly.

8. Exercise login, sessions, uploads, imports, forms, APIs and critical transaction flows. Have the product owner confirm the important outcomes, not just a successful homepage load.

9. Review existing logs and monitoring for unusual behaviour. This article provides no indicators of compromise. Suspected compromise requires specialist incident response.

10. Name the person or team responsible for future runtime and dependency updates. If immediate patching is genuinely impossible, assess isolation or temporary shutdown rather than treating a WAF or configuration change as complete protection.

What temporary measures can and cannot do

PHP documents measures that reduce exposure to particular paths. None is a complete solution. The operator should read the official advice and assess availability and application impact; a single copied setting is not a replacement for the patch.

For CVE-2026-109618, PHP describes administratively removing the PHP memory limit, conservative request and upload limits, and frontend or container boundaries. None is a complete solution: underlying allocation failure remains possible. PHP warns that certain process memory limits can cause the vulnerable failure rather than prevent it.

For CVE-2026-109619, PHP describes disabling session upload progress and, on PHP 8.5, fatal-error backtraces, then restarting every worker. These measures must take effect before request parsing. They block confirmed paths, not every variant, and are not a complete solution.

PHP also advises removing invalid or deprecated per-request settings that cause diagnostics before initialisation, and fixing reachable fatal errors and timeouts. This is not complete mitigation either; hiding diagnostics does not protect the runtime. PHP does not confirm a WAF as complete protection. Updating is the only complete solution for these flaws.

The ownership problem behind an emergency patch

tre plus analysis: runtime ownership often sits between the product team, hosting company and application supplier. An application can look maintained while its runtime has no clear owner. Missing inventories, unsupported branches and reliance on plugin updates make emergency changes harder than they need to be.

Agree in advance who watches runtime advisories, who authorises a change, who installs it and who validates production afterwards. Maintain a supported-branch upgrade path and rehearse patch validation. A supplier saying that the application is current is not evidence that PHP is patched.

When to involve a security specialist

Possible compromise, forensic work and incident response belong with a specialist security provider. A penetration test does not replace patching. tre plus is not offering a SOC, forensics, a penetration-testing service or emergency response here. Closing the vulnerability does not establish that earlier access or unwanted changes have been removed.

Making maintenance part of development

Runtime maintenance, automated tests, code review and CI/CD checks need an owner inside the development process. Our guide to secure software development describes how to organise ownership, controls and maintenance across the whole lifecycle. Our nearshore PHP developers page describes ongoing development work. Developer as a Service and Team as a Service are collaboration models, not incident-response services; our approach to nearshore developers keeps product ownership with your organisation.

Frequently asked questions

Is every PHP website vulnerable?

PHP warns installations serving web requests. Actual exploitability depends on the runtime, configuration, build and application behaviour. Verify the patch rather than assuming every site is exploitable or already compromised.

Do WordPress or Composer update PHP?

No. WordPress updates its application, and Composer manages dependencies and platform requirements. The hosting, package or container operator must update the PHP runtime.

Is a WAF enough?

No complete WAF mitigation is confirmed by PHP. Apply both fixes. Where that cannot happen immediately, assess isolation or temporary withdrawal from public access.

What if we run PHP 8.1 or an older branch?

Ask the vendor for documented remediation of both CVEs or upgrade to a supported branch. PHP’s exceptional minimal source backports for 7.4, 8.0 and 8.1 do not restore regular support.

Do PHP workers need to restart after updating?

Yes. Restart every relevant worker and process, then verify the active environment. The official temporary configuration measures also require restarting every worker.

How do we verify a hosting provider’s backport?

Get the complete installed package version and revision plus the vendor advisory recording fixes for both CVEs. Ask for confirmation that all active workers and replicas run that package. The visible PHP branch number alone is insufficient.