DigitalOcean PHP2Shell status: Droplets and App Platform

DigitalOcean's only PHP2Shell notice that we found is an App Platform release note dated 22 October 2026: the PHP buildpack now includes the fixed versions, and you must force a rebuild and deploy to use them. We found no DigitalOcean notice about Droplets, which you administer yourself. Confirm the fixed PHP package and a restart or redeploy time.

Our earlier host matrix, snapshot 22 October, listed DigitalOcean as "Unknown". The App Platform release note landed that same day, so the status below is newer than that snapshot. The rest of the matrix is in the host-by-host breakdown, and the other hosting guides are collected under the hosts topic.

Which DigitalOcean product are you on?

"DigitalOcean" is several products with different owners of the PHP. The answer to "who patches" changes with the product, so find yours first.

The PHP project says every PHP installation serving web requests is in scope: PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed (php.net, 21 October 2026). Which product you use changes who acts, not whether the fix is needed.

What did DigitalOcean say about App Platform?

DigitalOcean's release notes carry one October 2026 entry, dated 22 October. It says the PHP buildpack moved to version 298 and added PHP 8.5.3 to 8.5.12, 8.4.18 to 8.4.27, 8.3.31 to 8.3.33, 8.3.35 to 8.3.36 and 8.2.31 to 8.2.35. It states that 8.5.12, 8.4.27, 8.3.36, 8.2.35 and 8.1.34 include fixes for the two CVEs.

The same entry gives two instructions. Force rebuild and deploy your app to use a patched runtime. If composer.json pins an exact PHP version, change it to a range such as ^8.5.0 so a patched version can be selected. The note does not use the name "PHP2Shell"; it names the CVE ids.

The buildpack reference agrees. At our check it listed the default as 8.5.12, ranges up to 8.4.27, 8.3.36, 8.2.35 and 8.1.34, and said it was last verified 23 October 2026. PHP 8.1 is end of life upstream, and the PHP project shipped minimal source backports for it (php.net). Plan a move off it; what to do on an end-of-life PHP has the options.

Does restarting my App Platform app apply the fix?

No. DigitalOcean's docs say a restart redeploys an exact copy of your container without fetching updates. A force rebuild redeploys with the latest source and builds a new container image. The patched buildpack only matters to a rebuilt image.

In the control panel the path is Apps, your app, Actions, Force Rebuild and Deploy. You can choose whether to clear the build cache.

An app whose composer.json pins an exact PHP version may rebuild onto the same unpatched version. That is the trap specific to this platform. Read the build log after the deploy: DigitalOcean's deployment docs show it under the Activity tab. The log should show the PHP version the build resolved.

• Open your app's composer.json and note whether PHP is pinned to an exact version
• Change an exact pin to a range inside a supported branch, for example ^8.5.0
• Run Force Rebuild and Deploy, and note the deployment time on the Activity tab
• Read the build log and write down the resolved PHP version
• Repeat for every component and every app that uses PHP, including workers and staging

How do I patch a Droplet?

A Droplet is a server you administer. We found no DigitalOcean PHP2Shell notice about Droplets and no entry on its status page at our check. That is silence, and it means the PHP on your Droplet is whatever your package manager last installed.

Open the Web Console from the Droplet's page, or use SSH (console docs, SSH docs). DigitalOcean lists the console's requirements: the Droplet agent, a supported Linux distribution, SSH allowed through firewalls, and a public IP, so Private Droplets cannot use it. Then follow the channel steps in PHP2Shell fix: patch PHP, restart workers, verify it ran.

The fixed package depends on your distribution. Canonical lists 8.1.2-1ubuntu2.28 for 22.04, 8.3.6-0ubuntu0.24.04.13 for 24.04 and 8.5.4-0ubuntu1.5 for 26.04, and tells you to restart applications after the upgrade. Debian's tracker records fixes through DSA-6574-1 for trixie and DLA-4848-1 for bookworm. Those version numbers differ from upstream ones, which is why a package can be fixed and still look old.

Then the part people skip. A PHP-FPM or Apache process loads its code when it starts. Installing the package does not replace a running worker, so the service has to restart (why the restart matters). If your Droplet runs containers, the image must be rebuilt and the container replaced (container steps).

What about 1-Click images and Functions?

DigitalOcean's Marketplace page says apps it supports are actively updated and maintained by DigitalOcean, SharkLabs apps are experimental, and others are maintained by the vendor. It does not say who updates packages on a Droplet after you create it from an image. Treat the PHP on that Droplet as yours, and do not assume the image keeps itself current.

A server built from an older image needs the package update above, whatever PHP version the image shipped with. The same Droplet-style question for another VPS provider is answered in the Linode and Akamai check.

DigitalOcean Functions lists a PHP runtime (8.0 and 8.2 to 8.5; page last verified 13 March 2026). We found no PHP2Shell note for it. That stays unknown. Ask support, using the question below.

What do I ask DigitalOcean support?

For App Platform and Functions, DigitalOcean is the party that knows. Send this and keep the reply:

For [your app or domain], is the PHP runtime that serves web requests patched for CVE-2026-109618 and CVE-2026-109619? Please give the fixed buildpack, package or backport identifier, confirm which deployment or restart happened after the fix, and say whether I need to rebuild, redeploy or change a setting such as an exact PHP pin.

For a Droplet, support cannot see inside your server, so the evidence comes from you:

• The package changelog or version naming both CVEs (dpkg -l or apt changelog on Debian and Ubuntu)
• The time the PHP-FPM or Apache service last started, later than the install time
• The PHP that serves the domain, not the command line php -v
• Every virtual host and pool, if the server runs more than one PHP version
• Any cron, queue or staging process that runs its own PHP

Am I affected? A three-state self-test

Was anything exploited on DigitalOcean?

We found no DigitalOcean statement on that, and no breach report tied to its platform. Across the internet, AWS reported PHP2Shell attempts against its honeypots on 17 October, four days before disclosure, and again on 21 October. AWS says it is unclear whether those attempts would have succeeded on real systems (AWS Security Blog, vendor-claimed). In the CISA catalog entries we could read on 24 October, neither CVE appeared (CISA KEV). We did not search the whole catalog by CVE id, so check it yourself.

If your PHP was reachable and unpatched from 17 October, look for PHP files you did not upload, scheduled tasks you did not create, new administrator accounts and unexpected outbound connections from the server. A patch does not remove anything planted earlier. The steps are in a walkthrough for checking a compromised site.

Is there a newer PHP issue to watch?

The PHP project posted an informational advisory on 23 October 2026 for a separate issue, CVE-2026-115560, tied to session upload progress. It recommends setting session.upload_progress.enabled=0 until the next regular bugfix release, and says the full advisory comes with that release (php.net). The changelog showed no 8.5.13 entry at our check (PHP 8 changelog). It is a different issue from the two PHP2Shell CVEs. We will update this page when PHP publishes more.

What is the bug, without the exploit?

Both CVEs are memory-safety problems in the PHP engine, reachable by an unauthenticated web request. CVE-2026-109618 is remote code execution through out-of-memory handling that leaves request data partly initialised. CVE-2026-109619 is remote code execution through request state that outlives its memory and is reused by a later request in the same worker (php.net). We do not reproduce exploit material, and you do not need it to fix a server or an app. A plainer walk-through is in the two CVEs explained, and every fixed release by branch is in the fixed-versions table.

Not sure which of your sites run PHP on DigitalOcean? The inventory guide shows how to list them. The free scan reads the stack your site serves and matches each version to known vulnerabilities. It is a lookup: it can say a version is affected, not whether your setup is exposed.