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

[Bitpalast]

session.upload_progress.enabled = Off

cannot be trusted as an effective mitigation.

 

[Mehl]

Yeah, the latest information shows exactly that. Forget the scripts, we'll just have to wait for a fix.

 

[SpyQ]

Safest option is just to block all HTTP and HTTPS traffic to your server for now

 

[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.