Critical PHP RCE (CVE-2026-109618): Updating on Elestio

Critical PHP RCE (CVE-2026-109618): Updating on Elestio

Last updated: 23 October 2026. All Elestio-built PHP images, including WordPress, Nextcloud, Moodle and GLPI, have been rebuilt on patched PHP and are available as updates in your dashboard. Services that run on the vendor's official image, such as Drupal, Matomo and Mautic, pick up the vendor's patched release through the same update. PrestaShop's official image moved to patched PHP 8.5.12 on 22 October, so every PHP service we track is now covered.

If you run anything PHP on Elestio, here is the short version: two critical vulnerabilities in PHP itself were disclosed on 21 October, both scored CVSS 9.2, and both can lead to unauthenticated remote code execution. The patched images are ready, and the update is in your hands.

You apply the update yourself from the dashboard. The steps are at the bottom of this post.

What Actually Broke

These are bugs in PHP's core, not in WordPress, Drupal, Nextcloud or any individual application. Every PHP application inherits them.

CVE-2026-109618 concerns how PHP handles running out of memory. PHP uses longjmp() to abandon the current context when an out-of-memory error hits, which can leave internal request data only partially initialised. Request cleanup then runs against that half-built state and treats it as valid. The PHP advisory is unusually direct about the result: "The confirmed impact is unauthenticated remote code execution as the web worker account," and complete RCE was "validated over HTTP against mod_php with default PHP input and memory limits."

CVE-2026-109619 is a stale global state bug. PHP workers hold global state for things like errors, sessions and extensions. Request-owned memory can stay referenced by those globals after the request heap is freed, and a later request handled by the same worker can act on the freed memory before initialisation resets it. The confirmed impact is "unauthenticated heap use-after-free, memory disclosure and remote code execution with the web worker's privileges."

Two details from the advisories are worth knowing. Apache mod_php is the most exposed configuration, because it unconditionally runs the request shutdown procedure even when request startup has already failed. And for CVE-2026-109619, one of the confirmed paths is session upload progress, which is enabled by default.

PHP published some temporary mitigations alongside the advisories, but describes them as incomplete. Updating is the only complete fix.

Versions

Branch Patched release Status
PHP 8.5 8.5.12 Supported
PHP 8.4 8.4.27 Supported
PHP 8.3 8.3.36 Security support to 31 Dec 2027
PHP 8.2 8.2.35 End of life 31 Dec 2026
PHP 8.1 and earlier No patch End of life, will not be fixed

Everything from PHP 5.4 up to 8.5.11 is affected. That is not a typo. If you are running PHP 7.4 somewhere because an old application needs it, that installation has no fix coming and never will.

One trap worth avoiding: a lot of the advice circulating today says "update to PHP 8.2 or newer". That is technically correct and short-sighted, because PHP 8.2 reaches end of life on 31 December 2026. If you are choosing a branch today, 8.3 or newer saves you doing this again in ten weeks.

What We Are Doing

Every Docker image that Elestio builds itself and that contains PHP has been rebuilt against the patched releases. Some services run on the vendor's official image instead, and for those we pick up the vendor's patched build.

WordPress images are already updated. That covers both the standard WordPress and WordPress Multisite templates, which are the bulk of PHP usage across the platform.

The other Elestio-built PHP images were rebuilt on 22 October. That includes Nextcloud, Moodle, GLPI, Leantime and phpMyAdmin. Drupal, Matomo, Mautic, Friendica, Pixelfed and OpnForm use the vendors' official images, which already ship patched PHP.

PrestaShop was the last one to land: its official image moved to PHP 8.5.12 on 22 October. Apply the update from the dashboard as described below.

Worth putting that timeline in context: the patched PHP releases landed on 21 October at around 14:00 UTC, and the Elestio-built images were all rebuilt within roughly a day.

How to Update Your Service

Rebuilt images do not install themselves. Apply the update from the dashboard:

  1. Open your service and go to Service Overview
  2. Find the Software auto update section
  3. Open Settings
  4. Click Update now

If you have automatic updates enabled, the update will be applied on its normal schedule without you doing anything. If you need it sooner than that, use Update now.

Troubleshooting

No update is showing. Refresh the dashboard first. If there is still nothing, contact Elestio support and we will check your deployment directly.

I don't know whether my service uses PHP. If it is a WordPress, Drupal, Magento, PrestaShop, Nextcloud, Matomo, Mautic, GLPI, LimeSurvey, Dolibarr, Moodle, FreeScout or Flarum deployment, it does. If you are unsure about something else, the rule of thumb is that any application you administer through a web interface written in PHP is in scope.

I updated, how do I confirm the PHP version? Your application runs inside a Docker container, so PHP is not installed on the VM itself and php -v from the host terminal will not tell you anything useful. Check inside the container instead. From the service terminal, list your containers and then run php -v in the right one:

docker ps --format '{{.Names}}'
docker exec -it <container-name> php -v

Compare the result against the table above.

I run a custom stack with my own Dockerfile. Elestio's rebuilds cover catalogue images. If you maintain your own image, rebuild it against a patched PHP base yourself.

I am stuck on PHP 7.x or 8.1 for application compatibility. There is no patch coming. Treat that as an application migration project and prioritise it accordingly, and in the meantime restrict network exposure to that service as far as you can.

On the Exploitation Question

Two vendors have reported activity already. Patchstack reported probing attacks shortly after the releases went out, and watchTowr reported observations through its own honeypot network on 21 October. Both are single-vendor telemetry and neither has been independently confirmed. The vulnerabilities are not listed in CISA's Known Exploited Vulnerabilities catalogue at the time of writing.

We would rather you treat that as a reason to patch promptly than as a reason to panic. Either way, the action is the same.

Both PHP advisories are linked above if you want the primary sources.

Questions about a specific service on your account are best sent to Elestio support, where we can look at your deployment directly.

Thanks for reading ❤️ We kept this post updated as the patched images rolled out.