Critical PHP vulnerabilities: how we responded to protect our customers

On October 21, 2026, PHP released security updates addressing CVE-2026-109618 and CVE-2026-109619. Both are rated critical, with a CVSS v4.0 score of 9.2 out of 10, and can allow an attacker to execute code without logging in. The PHP security team’s announcement urges administrators to update immediately.

Davey Winder’s reporting in Forbes highlighted the urgency ahead of the release. With the technical advisories now public, administrators can assess their systems against the confirmed details.

These flaws affect the PHP runtime: the software on a server that executes PHP applications. Updating a website’s content management system or plugins alone does not repair the underlying runtime.

• CVE-2026-109618: unsafe handling of memory exhaustion. PHP can be interrupted while internal request data is only partially initialized, then treat that data as valid during cleanup. Researchers demonstrated remote code execution against Apache’s mod_php, including an attack path that runs before application code begins. Read the PHP advisory.
• CVE-2026-109619: stale state between requests. A PHP worker can retain references to memory that has already been released. A later request handled by the same worker can encounter that stale state. Exploitability depends on the application, configuration, and execution path. Read the PHP advisory.

Before a patch is available, a provider has to make a decision about continued exposure. In this case, we temporarily took customer web applications offline and kept them offline through the server patching process.

We understand the cost of that interruption. Websites and applications support sales, customer service, publishing, and everyday operations. Our decision was to accept controlled downtime while we addressed vulnerabilities that could give an attacker access to the systems behind those services.

We use Cloudflare for our customers. Its web application firewall protections were available before PHP released the patch, providing an additional layer of defense during the response.

In its account of the mitigation, Cloudflare reported observing attack traffic and attempts to adapt malicious requests to bypass its protections. Cloudflare also advised customers to apply the PHP updates even with its protections in place.

That distinction guided our response. Firewall mitigation helped reduce exposure, but it did not replace the need to fix PHP itself. We kept the applications offline until we could patch the servers.

We patched the servers as part of the response. PHP’s October 21 security releases are:

• PHP 8.2: 8.2.35
• PHP 8.3: 8.3.36
• PHP 8.4: 8.4.27
• PHP 8.5: 8.5.12

The official remediation guidance explains that configuration changes can reduce exposure to specific attack paths, but updating is the complete solution. Administrators using distribution packages should check their vendor’s security updates, since a vendor may backport the fixes.

We have also been in direct contact with DigitalOcean’s CEO to help ensure PHP versions on its platform are brought up to the latest patched releases. That work extends the response beyond the servers we patch ourselves: the platform options our customers depend on need to keep pace with the security release.

We investigated whether any servers had been compromised. Patching addresses the vulnerability going forward; investigation addresses whether an attacker had already gained access.

Those are separate questions. The availability of an update, or its installation, does not establish what happened before the patch was applied. Our response included both the remediation work and the investigation.

If you manage your own infrastructure, apply a PHP release or vendor package containing fixes for both CVEs. Make sure the running services use the patched software, including restarting the relevant PHP workers or services as required by your deployment. Keep available firewall protections enabled while completing the update.

If a hosting provider manages PHP for you, ask it to confirm that the version serving your application includes both fixes. For older PHP installations, check whether your vendor provides a backported fix or whether you need to move to a supported release. PHP’s security announcement sets out the available options.

For our customers, this incident shows what ongoing infrastructure and maintenance involves: making decisions about exposure, working with providers, applying updates, and investigating possible compromise. Sometimes that responsibility means interrupting access to an application while we address the risk. We take that decision seriously.