PHP Security Advisory 2026 (PHP2Shell)
Last updated: 21 October 2026 — awaiting upstream PHP patches.
Stop your Coolify container or isolate your instance from the public internet until you can install the emergency Coolify release. Your already deployed applications will continue running.
What is happening?
Two reported PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, are being discussed as PHP2Shell, with reports of leaked exploit information and a proof of concept. They are reported to allow remote code execution, meaning an attacker could run code on an affected server. See watchTowr's vulnerability FAQ for the reported CVE details.
The PHP security team's official announcement schedules a security release for Wednesday, 21 October 2026 at 14:00 UTC to address two critical vulnerabilities, each rated CVSS v4.0 9.2. PHP may release earlier if vulnerability details become public or active exploitation is observed. Affected versions, fixed versions, and full technical details will be published with that release.
At the time of this update, the PHP patches and the emergency Coolify release are not yet available. The reported exploit details and affected version ranges have not been confirmed in PHP's advance notice. Take the precautions below while waiting for the fixes.
Do not rely on configuration workarounds
Community suggestions include changing PHP configuration, disabling session upload progress, and configuring a reverse proxy or WAF to block certain requests or suspected payloads. These measures are easy to misconfigure. Even when checked against PHP's source code and the PHP manual, they are not official PHP mitigations and must not be treated as sufficient protection for an unpatched PHP runtime.
When someone suggested that disabling session upload progress might be enough, PHP core developer Gina Peter Banyard replied:
The only thing I can say is that the only mitigation is patching / upgrading PHP. I sadly know too much.
Treat any configuration or request-filtering stopgap only as an attempt to lower risk for a few hours. Do not rely on it to keep an unpatched instance publicly accessible or delay updating. Stop or isolate Coolify as described below, and update PHP as soon as fixed builds are available. For Coolify itself, install the emergency Coolify release containing those fixes.
Cloudflare WAF: stopgap protection
On 21 October 2026, Cloudflare CTO Dane Knecht announced that Cloudflare had deployed an initial set of WAF rules for the known exploit vectors, available to all customers, including the Free plan. He also reported early attacks and said Cloudflare was updating its mitigations as new vectors emerged. Cloudflare's WAF changelog lists emergency updates to both its Managed and Free rulesets on that date.
Cloudflare explicitly describes this protection as a stopgap only. It does not fix PHP or guarantee coverage of every exploit vector. WAF protection applies to traffic proxied through Cloudflare; requests that reach your origin directly bypass it.
Self-hosted users should keep Coolify stopped or isolated as described below and patch as soon as fixed builds are available. For Coolify, install the emergency Coolify release. Update the PHP runtimes in your deployed applications separately, even if those applications are behind Cloudflare.
Coolify Cloud users
The Coolify team has already disabled the vulnerable features in Coolify Cloud and completed a thorough security review. Coolify Cloud has not been compromised by these vulnerabilities. No action is required from you to isolate the Coolify Cloud dashboard; the team manages its mitigation and updates.
These protections apply to the Coolify Cloud platform. They do not protect PHP applications you deploy on your own servers through Coolify Cloud. Review those applications separately, isolate them if necessary, and update their PHP runtimes as soon as patched versions are available.
Self-hosted Coolify users
Choose one of the following temporary isolation measures immediately. Keep it in place until you have installed the emergency Coolify release containing the PHP fixes.
Option 1: Stop Coolify (recommended)
Connect over SSH to the server running your Coolify instance and run:
docker stop coolifyThis stops the Coolify container and makes the dashboard and API unavailable, including through your instance domain. You cannot manage resources through Coolify while it is stopped; webhook-triggered deployments and Coolify's background tasks will also be unavailable.
Your already deployed applications, databases, and services will continue running. Leave Docker, the Coolify proxy, and your application containers running.
Once the emergency release is available, follow the terminal upgrade process over SSH by selecting the Terminal tab in the upgrade guide. The upgrade process starts Coolify automatically after updating it. You do not need to start the unpatched container first, and automatic updates cannot run while Coolify is stopped.
When patches are available
The Coolify team will publish an emergency release after PHP releases the patches.
- Coolify Cloud: the team will update the platform. Update your own PHP applications separately.
- Self-hosted Coolify: check the Coolify release notes for the emergency release, then follow the upgrade guide. If Coolify is stopped, use the terminal upgrade process and specify the announced patched Coolify version.
- Before restoring public access: verify that the emergency Coolify version is running. You can then restore the instance domain and any public access you need, or continue using the SSH tunnel.
Updating Coolify does not update the PHP runtimes inside your deployed applications. For both self-hosted and Cloud users, review every PHP application, update its runtime or container image to a patched version, and rebuild or redeploy it as appropriate. Isolating or stopping Coolify does not isolate those applications.