Is Heroku patched for PHP2Shell? How to confirm it

Heroku published fixed PHP runtimes for PHP2Shell (CVE-2026-109618 and CVE-2026-109619) on 21 October 2026 and tells customers to redeploy their apps to pick them up. An app that has not been deployed since still runs the old runtime. Check the build output of your latest deploy for a fixed version.

What did Heroku actually say?

Heroku's changelog entry, dated 21 October 2026, is the only PHP2Shell statement from Heroku we found at our check on 26 October 2026. It lists four new runtimes: PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. It says the new versions fix the two critical remote code execution flaws, and that customers should redeploy to pick them up (Heroku changelog).

The entry gives a date but no time of day, no per-app status and no list of apps still on an old build. Heroku's later stack update on 22 October lists no PHP packages (Heroku changelog, 22 October). Nothing Heroku has published tells you which runtime your own app runs. Other platform hosts have the same gap, for example Render and Fly.io, and there are more host-by-host checks.

Why is a redeploy needed?

A Heroku PHP app gets its runtime when it is built. Heroku reads composer.lock, or composer.json if there is no lock file, and installs the newest PHP version that matches your constraint (Heroku, Specifying a PHP runtime). If you declare nothing, you get the newest version available on your stack (Heroku, PHP behavior). A build made before 21 October picked the older runtime, and the running release still carries it.

Heroku also warns against exact pins: "Never specify an exact version like 8.4.27" (Heroku, Specifying a PHP runtime). The reason applies here. A constraint such as ^8.4.0 lets a rebuild move to the fixed release, while an exact pin to an older number keeps the old runtime on every rebuild.

Which Heroku PHP version is the fixed one?

Heroku's PHP support page lists these runtimes per stack at our check on 26 October 2026 (Heroku, PHP support).

Branch dates are from php.net's supported versions page, read 24 October 2026. Heroku-22 is deprecated and reaches end of life on 30 April 2027 (Heroku, Stacks; Heroku changelog). An app on PHP 8.1 therefore has two clocks running. The longer read is on PHP 8.1 and older.

The 8.1.34 trap

PHP 8.1.34 is the one number where the version tells you nothing. Heroku rebuilt 8.1.34 on Heroku-22 with the backport and kept the number (Heroku changelog). An app built before the rebuild and an app built after it print the same php (8.1.34) line.

For PHP 8.1 on Heroku the evidence is the date of your latest deploy, not the version. A deploy on 22 October 2026 or later is the cautious reading, because Heroku's entry gives no time of day for the rebuild. If your last deploy was on 21 October, ask Heroku when the rebuilt runtime was available. Heroku calls the result a minimal mitigation rather than a supported release (Heroku changelog).

How do I confirm my Heroku app runs a fixed PHP?

Do this for every app, including staging, review and worker apps. Each Heroku app has its own releases.

• Run heroku stack -a <app> and note the stack. The fixed runtimes depend on it
• Open composer.json and composer.lock. Note the php constraint and make sure it is not an exact pin to an older number
• Redeploy from your normal pipeline so Heroku builds a new release
• Read the build output for the line under "Installing platform packages", such as php (8.4.27), and compare it with the table above
• Run heroku releases -a <app> and confirm the newest Deploy release is the one you just made
• Save the build output, the release number and the time. This is your evidence

If you deploy a Docker image on the container stack, Heroku's stack update says you must rebuild your image to pick up base image updates (Heroku changelog, 22 October). Then the PHP is whatever your Dockerfile installs, and the changelog above does not apply. See the Docker image page. Custom buildpacks are also outside what Heroku's notice covers.

What do I ask Heroku support?

Use this when a deploy cannot be done this week, or when you need a time for a PHP 8.1.34 build.

For app [app name] on stack [stack], is the PHP runtime that serves web requests patched for CVE-2026-109618 and CVE-2026-109619? Please give the runtime build or backport identifier, the date and time the fixed runtime became available on this stack, and confirm whether I need to redeploy or change a setting for this app.

Keep the reply with its date. Heroku's documentation does not say what support can see for a given app, so treat the reply as one piece of evidence next to your own build output.

Am I affected? A three-state self-test

Who is in scope on Heroku?

Any app that serves web requests through PHP. The PHP project says every PHP installation serving web requests is in scope, including PHP-FPM, mod_php, CGI, FrankenPHP and LiteSpeed (PHP notice). Heroku's PHP buildpack runs Apache or Nginx with PHP, so a PHP app is in scope until it runs a fixed build (Heroku, PHP support).

Apps on Node.js, Ruby, Python or Java are not affected by these two CVEs. A WordPress or Laravel app on Heroku is, because the flaw sits under the framework. Updating WordPress, plugins or Composer packages does not change the PHP runtime. The wider explanation of the flaw is in our PHP2Shell explainer, and patching the PHP runtime is covered for other platforms.

Was my Heroku app exploited before I redeployed?

Nothing on Heroku's side tells you, and we cannot see it from outside. The indicators of compromise to look for are on their own page. AWS reported PHP2Shell attempts against its honeypots from 17 October 2026, four days before disclosure, and says "it remains unclear" whether any would have succeeded on real systems. It also reports broad attempts after disclosure (AWS Security Blog). The running tally is in what is known about exploitation. At our check on 24 October 2026, neither CVE appeared in the part of the CISA catalog that we could read. Search it directly before relying on that.

Heroku dynos discard local file changes whenever they restart (Heroku, Dyno restarts), so files planted on a dyno rarely survive a restart. That does not cover everything an attacker could reach with code running in your app. Look at the places that persist: your database, admin users, scheduled jobs, add-on settings, and config vars. Rotate secrets the app could read if anything looks wrong. The steps are in the rotation guide.

Is there a newer PHP issue on Heroku?

The PHP project posted an informational notice on 23 October 2026 for CVE-2026-115560, a separate issue that needs an unusual session configuration, with a full advisory promised for the next release (php.net). It is a different problem from the two PHP2Shell CVEs. We found no Heroku statement about it at our check. We will update this page when one appears.