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

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. We are rebuilding every Elestio image that contains PHP. WordPress images are already updated. The rest are in progress and we expect all of them to be done during the afternoon of 22 October.

When your image is ready, you update it 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

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 Elestio Docker image that contains PHP is being rebuilt against the patched releases.

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 remaining PHP-based images are rebuilding now. That includes services like Drupal, Magento, PrestaShop, Nextcloud, Matomo, Mautic, GLPI, LimeSurvey, Dolibarr, Moodle, FreeScout and Flarum. We expect all PHP images to be current during the afternoon of 22 October.

Worth putting that timeline in context: the patched PHP releases landed on 21 October at around 14:00 UTC. Rebuilding the full catalogue inside roughly a day is about as fast as it can be done once upstream ships.

How to Update Your Service

Rebuilt images do not install themselves. Once your service shows an available update, apply it 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.

Check back if your service has not been rebuilt yet. Non-WordPress images are landing through 22 October.

Troubleshooting

No update is showing yet. Your image may not have been rebuilt yet. Non-WordPress PHP images are rolling out through the afternoon of 22 October.

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? Run php -v in the service terminal and check it 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 will update this post if the rebuild timeline changes.