Question ETA for critical PHP security updates (CVE-2026-109618 / CVE-2026-109619)?

[manni]

I am asking myself how to deal with the old PHP 5.3 and 5.6 Sites… yes out of date, but still appx 750 Webs in produktive State here…

 

[SpyQ]

I am asking myself how to deal with the old PHP 5.3 and 5.6 Sites… yes out of date, but still appx 750 Webs in produktive State here…

These versions will not be fixed for this issue.

 

[Hangover2]

@manni For PHP5.6+ you can be sure that deb.sury.org will release free patched versions. For PHP <=5.5 checkout TuxCare.

 

[Mehl]

I am asking myself how to deal with the old PHP 5.3 and 5.6 Sites… yes out of date, but still appx 750 Webs in produktive State here…

 

[danami]

@Mehl You might want to look at the "TuxCare Extended Lifecycle Support for PHP extension" in the Plesk extension directory. I haven't used it myself but I would imagine that they will be likely be backporting the fix into older PHP EoL versions (if they can). I think they go all the way back to PHP 5.6.

 

[Mehl]

@danami that was meant for @manni I guess. I am on current versions all the way.

 

[Hangover2]

@danami TuxCare goes even back to PHP 5.2.

 

[JVG]

Will version 7.4 get patched?

 

[Harm Jakob Tolsma]

Will version 7.4 get patched?

Nope. 7.4 is end of life. Only php 8 will receive patches.

 

[frg62]

Only from PHP 8.2.
8.0 and 8.1 will not be updated.

 

[mike_tcis]

Added the following ModSecurity/WAF rule to our Plesk instances that *may* mitigate exploit for now, will for sure break file uploads and possibly other things.

SecRule REQUEST_HEADERS:Content-Type "@contains multipart" "id:1026100,phase:1,deny,status:403,log,t:none,t:lowercase,msg:'php2shell mitigation: multipart request blocked',tag:'CVE-2026-109618',tag:'CVE-2026-109619'"

Use at your own risk.

 

[Harm Jakob Tolsma]

Added the following ModSecurity/WAF rule to our Plesk instances that *may* mitigate exploit for now, will for sure break file uploads and possibly other things.

SecRule REQUEST_HEADERS:Content-Type "@contains multipart" "id:1026100,phase:1,deny,status:403,log,t:none,t:lowercase,msg:'php2shell mitigation: multipart request blocked',tag:'CVE-2026-109618',tag:'CVE-2026-109619'"

Use at your own risk.

A core php developer posted that only patching will solve the problem.

Gina Peter Banyard (@[email protected])

@[email protected] The only thing I can say is that the only mitigation is patching / upgrading PHP. I sadly know too much.

phpc.social

 

[Mehl]

A core php developer posted that only patching will solve the problem.

Gina Peter Banyard (@[email protected])

@[email protected] The only thing I can say is that the only mitigation is patching / upgrading PHP. I sadly know too much.

phpc.social

that was a reply to the "session.upload_progress.enabled = off" solution.
The modSecurity solution is working BEFORE any request reaches PHP. So that might / Bshould work! With all the downsides, of course.

 

[Harm Jakob Tolsma]

that was a reply to the "session.upload_progress.enabled = off" solution.
The modSecurity solution is working BEFORE any request reaches PHP. So that might / Bshould work! With all the downsides, of course.

The keywords "might" and "should" here say enough.

 

[Mehl]

well, we're all struggling - and we don't know when plesk wil build and release the updates.
I am pretty sure, that the rule (not done by me!) takes care of Content-Type "@contains multipart" actions.
The "might" is, because we are not sure, that this is really how the exploit works.
But when the new version is released, we can take a look. If it is true, that this is the only attack vector, we can use the rule.

 

[skibbler]

@danami TuxCare goes even back to PHP 5.2.

we tried deploying Tuxcare PHP for our customers, but the Ubuntu package is a complete mess, there are Cpanel and Almalinux-specific files scattered around, and the systemd service definitions are broken, it feels more like a poorly adapted port than a package properly built and tested for Ubuntu.

In its current state, I wouldnt trust it in a _production_ Plesk environment and honestly, given these packaging and service integration issues, I wouldnt feel comfortable running it on Almalinux either, if the basics are this broken, it raises serious concerns about the overall quality and reliability of the package.

 

[keuta]

Some news from plesk :
https://support.plesk.com/hc/en-us/...mote-code-execution-in-PHP-shipped-with-Plesk

A fix is in development. The PHP vendor has scheduled the release of fixed PHP versions for 21 October 2026 at 14:00 UTC (PHP News Archive | 20 Oct 2026). After that, Plesk will rebuild the following and deliver them to Plesk servers:

PHP builds from Plesk: 7.4 (EOL), 8.0 (EOL), 8.1 (EOL), 8.2, 8.3, 8.4, 8.5
Plesk Obsidian 18.0.80 and 18.0.81 will receive a fix for sw-engine (PHP engine used by Plesk itself)

 

[JVG]

I understand we may not know yet but, will disabling hosting on affected domains (below patched PHP versions) be enough to temporarily mitigate the exploit?

 

[frg62]

Some news from plesk :
Vulnerability CVE-2026-109618 and CVE-2026-109619: Remote code execution in PHP shipped with Plesk

A fix is in development. The PHP vendor has scheduled the release of fixed PHP versions for 21 October 2026 at 14:00 UTC (PHP News Archive | 20 Oct 2026). After that, Plesk will rebuild the following and deliver them to Plesk servers:

PHP builds from Plesk: 7.4 (EOL), 8.0 (EOL), 8.1 (EOL), 8.2, 8.3, 8.4, 8.5
Plesk Obsidian 18.0.80 and 18.0.81 will receive a fix for sw-engine (PHP engine used by Plesk itself)

You mean that Plesk will be able to provide patches for PHP 7.4 (EOL), 8.0 (EOL), 8.1 (EOL)?

If yes, this are excellent news.

 

[Mehl]

Just now: RELEASED!

PHP: News Archive - 2026

PHP is a popular general-purpose scripting language that powers everything from your blog to the most popular websites in the world.

www.php.net