Mitigation Of Critical PHP CVEs
Posted: 22nd Oct 2026
On October 21st, 2026, the PHP project disclosed a set of critical remote code execution vulnerabilities affecting PHP 5 through to 8.5. The "php2shell" vulnerabilities are trivially exploitable, making rapid response essential. This post explains what happened, what we did, and what you need to know.
What Are The Vulnerabilities?
The PHP security team released patches for several critical issues across PHP 8.2, 8.3, 8.4, and 8.5. The most severe involve state corruption via unexpected bailout conditions (CVE-2026-109618 and CVE-2026-109619), which can be triggered to achieve remote code execution. Additional high-severity issues were also patched across PHP's standard library, OpenSSL, and SOAP extensions.
The exploitability is notably low-effort — PHP's own security advisory explicitly flagged these as requiring immediate action. The primary attack surface involves multipart HTTP requests, which are commonly used for file uploads and form submissions.
Who Is Affected?
Any Servd project running a version below the patched releases is potentially vulnerable:
PHP 8.2.x → upgrade to 8.2.35
PHP 8.3.x → upgrade to 8.3.36
PHP 8.4.x → upgrade to 8.4.27
PHP 8.5.x → upgrade to 8.5.12
Projects running PHP 8.1 or lower do not receive security patches from the PHP project and remain vulnerable. We strongly recommend upgrading to PHP 8.2 or higher.
As of writing, we have not received any reports from customers nor have detected any indications that any Servd projects have been compromised.
What Did We Do?
We were monitoring the PHP security advisories ahead of public disclosure and acted before the CVEs were published.
03:02 UTC, October 21st — Cloudflare updates it's WAF to block php2shell exploits. Projects protected by Servd's Ingress Platform now have a first line of defence against attacks. Older projects still running Servd's legacy ingress are still vulnerable at this point.
09:12 UTC, October 21st — We deployed a block to all multipart upload requests across all Servd-hosted projects after early information became available. This temporarily caused file uploads to return 403 errors, but it closed the primary attack vector immediately while we waited for official patched PHP builds. We began tracking the issue on our status page.
14:54 UTC, October 21st — We had infrastructure in place and were awaiting the official PHP images from the PHP project.
17:12 UTC, October 21st — Official patched images were published. We began rolling out updated runtime bundles containing PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12.
17:33 UTC, October 21st — We made patched PHP versions available to all customers.
As of 22nd October, we are automatically rebuilding deployed bundles for all projects running PHP 8.2 or higher, replacing them with builds with a safe version of PHP. When the safe bundle is deployed to an environment, the multipart upload block is automatically lifted.
What Do You Need To Do?
First, check the PHP version each of your project environments is running by logging into your Craft admin panel and accessing the "System Report" utilities page.
If it's on PHP 8.2 or above and a new bundle has not been deployed since 17:33 UTC October 21st, then we recommend performing the following steps in the Servd dashboard for each of your project environments:
- Visit the [Environment] > Settings page
- Click the Create Bundle button
- Select the same commit that you currently have deployed
- Check the "Deploy to [environment]" checkbox
- Click Create Bundle
If it's on PHP 8.1 or lower then the project environment's multipart upload block will remain in place until you upgrade to PHP 8.2 or above. We recommend upgrading as soon as possible. You can change your PHP version as per these steps.
If you have any concerns about your project or notice anything unexpected, please send an email to support@servd.host.
A Note On Our Approach
We made a deliberate call to disrupt file uploads briefly rather than leave projects exposed to a trivially exploitable RCE. We know that's a trade-off that affects real users, and we don't take it lightly. In cases like this — where the severity is critical and the exploitation bar is low — we believe a short-term disruption is the right call.
We'll continue monitoring the situation and will update this post if anything changes.
