Fly.io PHP2Shell status: rebuild your image to confirm

We found no PHP2Shell notice from Fly.io at our check on 26 October 2026, and none is needed to know who acts: Fly runs the container image you give it, so the PHP inside is yours. Rebuild the image on PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, run fly deploy, then confirm the new release and a fixed PHP in a running Machine.

Silence from a host is not a status, so we list Fly.io's own PHP2Shell status as unknown. Other incidents from the same weeks are on the October 2026 tracker, and the rest of the PHP2Shell pages are collected under all the PHP2Shell guides.

Who patches PHP on Fly.io?

You do. Fly's registry guide describes the split: you build, tag and push the image, and Fly runs it as a Firecracker VM. The Machines page says a Machine is created by fetching your container from the registry and building a root file system from it. Nothing in either page describes Fly updating packages inside your image.

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). A Fly app is in scope the same way any container is. Which tool built it does not matter. If you also run PHP outside containers, patching the PHP runtime and restarting workers is covered separately.

Fly's configuration reference says an image build is deployed with no build process, as is. That path never rebuilds anything for you. Image-based platforms such as Render and Heroku have their own answers.

Why does a restart not fix it?

A container keeps the PHP it was built with. Fly's fly machine restart page describes restarting one or more Machines, and says nothing about fetching a new image. We would not rely on a restart to change the PHP in your image.

fly deploy is the command that builds a new image and replaces running instances. Its default strategy is rolling, and --no-cache tells the builder not to use its build cache. The cache is the second trap. An apt-get install layer can be reused from before 21 October and still contain the old package.

The Fly Laravel guide says fly launch generates a Dockerfile and fly deploy redeploys after changes. It does not name the PHP version the file installs, so read your own file instead of trusting a default.

How do I patch a Fly.io app?

Run these from a machine or CI job that can build your image. Try them on a staging app first if you have one.

• Find the build path in fly.toml: a dockerfile, an image, or a builder setting
• Open the Dockerfile and read the first FROM line and every PHP install line
• Move the base to a fixed release, or to a distribution package that names both CVEs in its changelog
• Deploy with a fresh build: fly deploy --no-cache -a <app>
• Repeat for every app and process group that runs PHP, including workers, queues and staging
• Redeploy any app that shares the Dockerfile, so none keeps the old image

For the official php image, the library file lists 8.5.12, 8.4.27, 8.3.36 and 8.2.35 and no 8.1 or older tags at our check (docker-library). Ubuntu and Debian ship fixes under their own version numbers. Debian's tracker, for example, records 8.4.27-1~deb13u1 for trixie (Debian), and Canonical tells you to restart applications after the upgrade (Canonical). That is why a fixed package can still look old. Container steps in more depth are in the Docker image guide.

How do I confirm what is running?

Check what Fly is running, not what your repository says. Each of these reads state.

With several Machines, select each in turn with -s; the ssh console page says it lets you choose from the accessible Machines. A partial rollout can leave one on an old image.

What do I ask Fly.io?

Fly can see which image you deployed and when. It cannot see inside your PHP. Ask only about what Fly controls, and keep the reply.

For [app name]: which image reference and digest does the current release run, when was that release created, and are all Machines for this app on it? Is any PHP component in my deployment maintained by Fly rather than built from my own Dockerfile or image setting?

If you use someone else's image, ask its publisher instead. This page on who is responsible helps decide who answers.

Am I affected? A three-state self-test

What if my app is on PHP 8.1 or older?

The PHP project says 8.1 and older no longer receive project releases (php.net), and the official image file lists no tags for them. Fly has no fix to offer for a branch upstream has dropped. Move to a supported branch and test, or use a vendor image whose changelog names both CVEs. The 8.1 and older guide covers the interim settings PHP recommends.

Was anything exploited on Fly.io?

We found no Fly.io statement on that, and no incident report tied to its platform. AWS reported PHP2Shell attempts against its honeypots from 17 October, four days before disclosure, and says it is unclear whether they would have succeeded on real systems (AWS Security Blog, vendor-claimed). Neither CVE appeared in the CISA catalog entries we could read on 24 October (CISA KEV). We did not search the whole catalog by CVE id, so check it yourself.

If your app was reachable and unpatched from 17 October, check for PHP files you did not upload, new admin accounts, scheduled tasks you did not create and unexpected outbound connections. A deploy replaces the Machines but does not tell you what ran in the old ones or what secrets they could read. The steps are in a post-compromise checklist for PHP2Shell.

Is there a newer PHP issue to watch?

On 23 October 2026 the PHP project posted an informational advisory for a separate issue, CVE-2026-115560, tied to session upload progress. It recommends session.upload_progress.enabled=0 until the next regular release (php.net). The changelog showed no 8.5.13 entry at our check (PHP 8 changelog). 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 a request partly initialised. CVE-2026-109619 is remote code execution through request state that outlives its memory and is reused by a later request (php.net). We do not reproduce exploit material, and you do not need it to fix an app.

Not sure which of your apps run PHP? 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.