Critical PHP flaws allow remote code execution; DigitalOcean urges patching

What the vulnerabilities allow

According to DigitalOcean, either flaw lets an attacker execute arbitrary code on a server running PHP, which could lead to full compromise of the affected system. The company says the vulnerabilities affect every PHP version from PHP 5 onward.

DigitalOcean states that no complete mitigations exist except patching. PHP underpins a large part of the web, including WordPress, Drupal, Laravel and custom applications, as well as Cloudways by DigitalOcean.

The PHP project has released fixes for the currently supported branches:

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

For PHP 8.1 or earlier, no patch is available. DigitalOcean advises anyone on an end-of-life version to plan an immediate upgrade to a supported one.

Which DigitalOcean products are affected

DigitalOcean lists several products as affected. Marketplace 1-Click images, including WordPress, LAMP, LEMP and Laravel, have been delisted until they are patched, so new deployments do not start out vulnerable. Instances already deployed do not update themselves, and customers must update PHP on them.

Functions offers PHP runtimes 8.2, 8.3, 8.4 and 8.5. The runtimes have been patched, and customers need to redeploy to pick up the new levels. App Platform's PHP buildpack has also been patched. Customers should redeploy, and those using their own Dockerfile or container image must update the PHP version in that image first.

Cloudways is handled by DigitalOcean. According to the company, it is actively patching PHP 5.6 and above across the platform, using an extended LTS partnership for older instances, and is not forcing customers to migrate to newer PHP versions. In the meantime it has applied PHP's temporary mitigations and targeted WAF rules. SnapShooter is fully patched as of publication.

Droplets, GPU Droplets, Paperspace, Kubernetes (DOKS), MicroVMs, Container Registry and snapshots or backups are listed as not affected by default, but customers must check their own workloads. For example, restoring a snapshot or backup made before patching brings back the vulnerable PHP, and images in Container Registry stay vulnerable until rebuilt and pushed again. Managed databases, storage, networking, inference and monitoring products do not use PHP, according to DigitalOcean.

Recommended steps for customers

DigitalOcean recommends first taking an inventory of every system running PHP, including bundled installs such as WordPress, other CMS instances, admin panels like phpMyAdmin and legacy apps. Patches should then be applied immediately. Users of PHP-based software such as WordPress or Laravel may also need provider-specific patches.

Those who cannot update at once can consult the PHP Foundation's published measures to reduce exposure, though DigitalOcean stresses these do not make an installation safe on their own. It also advises restricting public access to PHP applications that do not need to be internet-facing and keeping firewall, WAF rules and monitoring in place. The company notes that Cloudflare has released emergency WAF rules.

For customer-managed Droplets, the PHP version can be checked with php -v. On Ubuntu and Debian, the update is sudo apt update followed by sudo apt install --only-upgrade 'php*'. For CentOS, Fedora, Rocky Linux and AlmaLinux, sudo dnf upgrade 'php*' applies once patches arrive. DigitalOcean notes that this family was still working on releasing patches at publication. PHP-FPM or the web server must be restarted after updating. For containerized workloads, the base image or Dockerfile should be updated to a patched release, then rebuilt and redeployed.

What it means for users

With public exploit code available and no full workaround, the practical advice from DigitalOcean is to find and patch every PHP instance quickly. Customers on managed services such as Cloudways get much of this handled for them, but anyone running self-managed Droplets, containers, restored snapshots or older PHP versions must act themselves. Operators on PHP 8.1 or earlier face an upgrade, since no official fix will be released for them.