Critical PHP RCEs (CVE-2026-109618 / CVE-2026-109619) – impact on Cloudron apps?

[pathab]

Heads-up regarding the upcoming critical PHP security release:

CERT-EU advisory 2026-018 and the PHP project announced two critical vulnerabilities (CVE-2026-109618 and CVE-2026-109619, both CVSS 9.2) that can lead to unauthenticated remote code execution. They potentially affect PHP versions from 5 onwards.

Patches are scheduled for today, 21 October 2026 at 14:00 UTC (16:00 CEST).

Since many Cloudron apps run on the php-base images (WordPress, Nextcloud, BookStack, FreeScout, LAMP, etc.), will the php-base images and the affected app packages be updated shortly after the official PHP release?

Thanks for any info on the timeline.

https://cert.europa.eu/publications/security-advisories/2026-018/

https://www.php.net/archive/2026.php#2026-10-20-1

[james]

Hello @pathab
We are already looking into it.

[imc67]

Sharing what I did on my three servers while waiting for the patched images, in case it helps someone.

The leaked analyses (Hacker News, Sansec, Huntress) all point at session.upload_progress, and the circulating PoC sends a multipart POST with a PHP_SESSION_UPLOAD_PROGRESS field. None of my apps use that feature, so I switched it off everywhere. On Cloudron this is easy for most PHP apps, because /app/data/php.ini is linked as 99-cloudron.ini into both the Apache and the PHP-FPM conf.d:

; php2shell mitigation, remove after the patched image
session.upload_progress.enabled = Off

followed by apache2ctl -k graceful inside the container (and a USR2 to the php-fpm master for LimeSurvey, which uses FPM). That covered 47 installs (WordPress, Nextcloud, FreeScout, EspoCRM, Matomo, LimeSurvey, HumHub, Roundcube, LAMP) without any downtime. YOURLS has no /app/data/php.ini, but it reads /app/data/htaccess, so php_flag session.upload_progress.enabled off works there.

Two things I learned on the way: OIDC login doesn't protect a PHP app here, because the request is parsed by PHP before the app gets to the login check. proxyAuth does, because nginx stops the request before it reaches the app. And the WordPress maintenance mode doesn't help either, for the same reason.

There are also unverified claims of a second path through the general multipart parser, which the setting above wouldn't cover. Like many sites worldwide that went offline as a precaution today, I stopped 17 of my 53 PHP installs until the patched images are out: the ones nobody misses for a few hours (MainWP, Matomo, a staging site, personal tools) and all EspoCRM instances, because they hold personal data. The public websites, helpdesk and intranet stay up with the mitigation in place.

Looking forward to the patched php-base images. Is there already an idea of the timing?

[girish]

From what I read the php.ini fix is insufficient. The PHP devs mentioned that only a PHP update can fix the issue.

[girish]

the thread at https://phpc.social/@Girgias/117476510850918355

[girish]

Probably not the best thread to hijack but since we got so many questions already by email ... We have shutdown our support app freescout . Expect some delays if you reach us by email. The forum is still the best way to get support .

I am also trying to post updates on https://social.cloudron.io/@cloudron and https://x.com/CloudronIO

[jayonrails]

Update has been released.

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.

Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.

The vulnerabilities:

RCE via OOM corruption, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.
RCE via stale global state, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.
How to update:

Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Source downloads are on our downloads page. Windows source and binaries are on the same page.
Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages.
PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version.
If you rely on the volunteer-maintained rpms.remirepo.net, we urge you to switch to distribution packages or build from source, so you can immediately apply updates. The repo will not have updates today.
Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.
If you cannot update immediately: while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe.

RCE via OOM corruption (CVE-2026-109618):

Set memory_limit=-1, preferably in a way applications can't override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.
Set a low post_max_size. For applications that don't require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M. Keep upload_max_filesize below post_max_size. Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth. These limits must also cover requests without a usable Content-Length.
Use a container or cgroup limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.
RCE via stale global state (CVE-2026-109619):

Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants.
On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.
Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors or @ does not help.
Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing and cleanup.
The advisories linked above have the full technical details.

[privsec]

So do we just need to turn off all apps until the applicable updates for the apps are rolled out?

[dsp76]

We set our hosters firewall webhosting Ports (80/443) to selected (our own) IPs and do not allow any other traffic.
We used a script to find out about all our apps in the cloudron containers and their PHP version. So before we switch them on again, we also need to check the app images have been updated.

[nostrdev]

some examples of affected apps:

• nextcloud
• privatebin
• support
• yourls

[privsec]

Is there a full listing of all impacted apps?

[jdaviescoates]

@privsec follow the announcement thread, but yes, see this list https://forum.cloudron.io/post/131373

[joseph]

I will close this thread if that is OK. All the info is at https://forum.cloudron.io/topic/16170/security-issue-thread-php-and-emudhra-cert-compromise/ .

[p44]

@joseph Yes, is better to have one main thread