Is Render patched for PHP2Shell? How to confirm yours

Render's own documentation says it has no native PHP runtime: PHP runs from a Docker image you supply. At our check on 26 October 2026 we found no Render PHP2Shell notice, so the PHP in your service is whatever your image contains. Rebuild the image on PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, deploy it, then check the running service.

Our earlier host matrix, snapshot 22 October, listed Render as "Unknown" with no patch note. That has not changed at this check. The wider picture is covered in the rest of this article.

Does Render run PHP for me?

Render's language support page lists Node.js and Bun, Python, Ruby, Go, Rust and Elixir as natively supported. For anything else it says to deploy a Docker image, and it names PHP as an example. It discusses no PHP versions.

Other image-based platforms put you in the same position, as with rebuilding on Fly.io or redeploying a Heroku app. That decides who owns the fix. On a native runtime, the platform picks the language version at build time. For PHP on Render, you pick it, in a Dockerfile or in an image you built elsewhere. A site on Render is in scope for PHP2Shell if that image runs PHP to serve web requests, whatever the framework on top. The PHP project says every installation serving web requests is in scope (php.net, 21 October 2026). The write-up of which installs are affected has the full scope.

Sites on Render that do not run PHP are not affected by this bug. A Node.js, Python or static service has no PHP engine to fix.

What does Render say it patches?

Render's shared responsibility model says Render is responsible for making sure the underlying operating systems are patched and for keeping the runtime environments for supported programming languages and frameworks up to date. It lists application-level configuration and regular security assessments as the customer's.

The page does not mention customer container images or base images. Because PHP is not a supported language on Render's own list, we read that sentence as not covering your PHP. This is our reading, not a Render statement. If you want it confirmed, ask Render the question further down.

Each provider draws this line a little differently, and the other host status pages show how. On Google's side, what the Cloud Run bulletin says is a useful contrast. For the general question of who patches what, see how patching duties split between host and site owner.

Why does a restart on Render not fix it?

Render's deploys page describes Restart service as redeploying the running commit: the new instance uses the exact same Git commit and configuration as the one it replaces. The Docker image is the same one, so the PHP is the same one. The reason a restart matters on a normal server is covered in PHP-FPM restart after update. On Render, a restart cannot do the job at all, because the code you need is not in the image yet.

Three things keep the old PHP alive after the official image moves:

1. Layer cache. Render's Docker page says it caches all intermediate build layers. Docker's own docs say the cache for RUN instructions is not invalidated automatically between builds, so an old package layer can be reused.
2. A mutable tag. The same Render page says its public image cache means a mutable tag such as latest might give a build that uses a cached, less recent version. It advises immutable tags or registry credentials.
3. No redeploy on tag change. For prebuilt images, Render's image deploy docs say image-backed services do not automatically redeploy when a new image is associated with their tag.

How do I fix it on Render?

Pick the row that matches how your service gets its image. In the dashboard a service's source is either built from a Dockerfile in your repository or pulled as a prebuilt image from a registry. The Blueprint spec calls these runtime: docker and runtime: image (Blueprint spec).

Built from a Dockerfile in your repo

Render builds the image with BuildKit on each deploy (Docker docs). Change the base image line to a fixed release, for example an official php image on 8.4.27 or later. The official image library lists the four fixed releases on Debian trixie and bookworm and Alpine 3.24 and 3.23 (Docker library). Commit it. Then use Clear build cache & deploy, which Render's deploys page lists next to Deploy latest commit and Restart service.

Render's deploys page describes that option as clearing cached build artifacts. It does not say it drops every Docker layer. Changing the FROM line already gives you a different base, which is the safer lever. If you install PHP with apt or apk in a RUN line on an older base, that layer can be reused, so clear the cache as well.

Prebuilt image from a registry

Build and push a new image on a fixed release under a tag you have never used. Then either change the tag or digest in the service settings, or use Manual Deploy > Deploy latest reference, which Render's image docs give for pulling the currently tagged image. A deploy hook can also take an imgURL parameter with a different tag or digest. Everything except the tag or digest must match the service's default image URL.

Your checklist

• List every Render service that runs PHP, including workers, cron jobs and staging copies (inventory guide)
• Update each base image or package line to a fixed release, or to a package that names both CVEs
• Use a new, specific image tag, not latest
• Deploy with Clear build cache & deploy, or Deploy latest reference for prebuilt images
• Read the deploy log and confirm it is the new build
• Check the running service from its Shell page, then write the result down with the time

The container-side detail is on PHP2Shell Docker image patched. The general steps are in the PHP2Shell fix guide.

How do I check the PHP version Render is running?

Render's shell documentation says you can open a shell from a service's Shell page in the dashboard, with an Instance dropdown if you run several, or use render ssh. Paid web services, private services and background workers have both. Free web services have neither, so for those you rely on your build log.

In the shell, ask the PHP binary that serves requests, not the command line. For an FPM image that is the FPM binary.

php-fpm -v

php -v reports the command line binary, which can be a different build. If your base is a distribution package rather than the official image, read the package changelog for both CVE ids, because a fixed package can still report an old number (backport trap).

What do I ask Render?

Only ask Render about anything Render maintains. Your image is yours. If you want their position on the PHP2Shell fixes and on the shared responsibility line above, send this and keep the reply:

For [service name or domain], is any PHP component maintained by Render, such as a base image, template or Blueprint, affected by CVE-2026-109618 or CVE-2026-109619? If yes, which fixed version or build replaces it, and do I need to redeploy? If no, please confirm that the PHP in a Docker-based service is the customer's to rebuild.

Am I affected? A three-state self-test

What if my Render service runs PHP 8.1 or older?

The PHP project says 8.1 and older no longer receive project updates. It published minimal source backports for 7.4, 8.0 and 8.1 (php.net). The official Docker library file lists no 8.1 or older tags, so a pinned php:8.1 base has no official fixed image to move to. The options are in PHP 8.1 and older. In order: move to 8.4 or 8.5 after testing, use a vendor image whose changelog names both CVEs, or apply the interim settings from the PHP notice while you plan the move. The notice says there are no complete mitigations and that updating is the only reliable route (checked 24 October 2026).

Was anything exploited on Render?

We found no Render statement on that and no breach 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 any attempts would have succeeded on real systems (AWS, vendor-claimed). The CISA catalog entries we could read on 24 October, dated 8 to 23 October, did not include either CVE (CISA). We did not run a full search by CVE id, so check it yourself.

If a service was reachable and unpatched from 17 October, look in uploaded files and mounted disks for PHP files you did not put there, new admin accounts, scheduled tasks and unexpected outbound connections. Replacing a container does not remove anything stored on a persistent disk or in a database. The list is in a step-by-step compromise checklist. Wondering whether a WordPress site on Render is covered? Does PHP2Shell affect WordPress answers that.

PHP posted a separate informational notice on 23 October for CVE-2026-115560, tied to session upload progress, and recommends session.upload_progress.enabled=0 until the next bugfix release (php.net). The changelog showed no 8.5.13 entry at our check (PHP 8 changelog).

If you manage Render services for clients, the agency triage list groups the work by owner. If you want an outside view of what a site shows, 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.