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

[danami]

Guys there is another unpatched PHP RCE: CVE-2026-115560. Make sure to set `session.upload_progress.enabled=0` in all your PHP.ini files:

https://twitter.com/x/status/2113580383875019242

 

[Mehl]

Guys there is another unpatched PHP RCE: CVE-2026-115560. Make sure to set `session.upload_progress.enabled=0` in all your PHP.ini files:

https://twitter.com/x/status/2113580383875019242

but read the article linked first.

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

only exploitable under very unusual combination of configuration and application code.

 

[Bitpalast]

Guys there is another unpatched PHP RCE: CVE-2026-115560. Make sure to set `session.upload_progress.enabled=0` in all your PHP.ini files:

https://twitter.com/x/status/2113580383875019242

but read the article linked first.

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

only exploitable under very unusual combination of configuration and application code.

"... Since this setup is unlikely in practice, ..."
Really? Hackers will just upload their own script that configures the system the way they want it, then start the attack.

One strategy would be to set

php_admin_flag[session.upload_progress.enabled] = off

in the additional directives, so that the value cannot be changed by the subscription owner via an .ini file. It will end up in the /opt/plesk/php/<version>/etc/php-fpm.d/*.conf file of the domain. But that can be tedious if you have many domains on a server as it needs to be done on a "per domain" basis.

Another solution can be

sed -i 's/;session.upload_progress.enabled = On/session.upload_progress.enabled = O/g' /opt/plesk/php/<version>/etc/php.ini
sed -i 's/;user_ini.filename = ".user.ini"/user_ini.filename = ""/g' /opt/plesk/php/<version>/etc/php.ini
service plesk-php<version>-fpm restart

That will set the variable for all PHP instances using that version while it disables user .ini files altogether. As the session.upload_progress variable cannot be set by ini_set() it will keep an attacker from making the environment fit a malicious purpose.

Opinions on this?

 

[Mehl]

"... Since this setup is unlikely in practice, ..."
Really? Hackers will just upload their own script that configures the system the way they want it, then start the attack.

One strategy would be to set

in the additional directives, so that the value cannot be changed by the subscription owner via an .ini file. It will end up in the /opt/plesk/php/<version>/etc/php-fpm.d/*.conf file of the domain. But that can be tedious if you have many domains on a server as it needs to be done on a "per domain" basis.

Another solution can be

That will set the variable for all PHP instances using that version while it disables user .ini files altogether. As the session.upload_progress variable cannot be set by ini_set() it will keep an attacker from making the environment fit a malicious purpose.

Opinions on this?

That must be authorized and authenticated hackers though ....

 

[Bitpalast]

That must be authorized hackers though ....

Just think about all the domains that are compromised through successful hacking attempts already. I am not speaking about new attempts, just use the existing infections. There are tons of Joomla and Wordpress installations that are malware infected, and these already have the possibility to upload scripts into the subscription freely.

 

[Mehl]

Well, I guess then this vulnerability is your smallest problem. If they are already in the system, why would the hackers want another way to break in?

 

[Bitpalast]

Well, I guess then this vulnerability is your smallest problem. If they are already in the system, why would the hackers want another way to break in?

There is a critical distinction between two types of attacks: compromising individual websites within a hosting subscription and gaining command-line or root access to the underlying server.

The former is serious but typically limited to activities such as distributing spam, hosting phishing pages, or attacking other systems. The latter potentially compromises the entire server.

PHP2Shell exploits fall into this far more dangerous category, as does the newly disclosed vulnerability. The particular concern is that attackers who already control compromised websites could escalate their access. By uploading custom PHP scripts and manipulating certain PHP settings, they may be able to establish the conditions necessary for a PHP2Shell exploit, turning an isolated website compromise into a server-wide security breach.

For this reason, I believe describing the scenario as "unlikely" significantly understates the risk. Once an attacker has compromised a hosting subscription, they may be able to deliberately establish the conditions required for exploitation. What might otherwise be considered an unlikely scenario can thus become a deliberately prepared, attack-ready environment.

And for the same reason I believe that disabling user defined .ini files plus disabling session.upload_progress.enabled is essential - until PHP provides another fix for the mess.

 

[Mehl]

There is a critical distinction between two types of attacks: compromising individual websites within a hosting subscription and gaining command-line or root access to the underlying server.

The former is serious but typically limited to activities such as distributing spam, hosting phishing pages, or attacking other systems. The latter potentially compromises the entire server.

PHP2Shell exploits fall into this far more dangerous category, as does the newly disclosed vulnerability. The particular concern is that attackers who already control compromised websites could escalate their access. By uploading custom PHP scripts and manipulating certain PHP settings, they may be able to establish the conditions necessary for a PHP2Shell exploit, turning an isolated website compromise into a server-wide security breach.

For this reason, I believe describing the scenario as "unlikely" significantly understates the risk. Once an attacker has compromised a hosting subscription, they may be able to deliberately establish the conditions required for exploitation. What might otherwise be considered an unlikely scenario can thus become a deliberately prepared, attack-ready environment.

And for the same reason I believe that disabling user defined .ini files plus disabling session.upload_progress.enabled is essential - until PHP provides another fix for the mess.

ok, I agree that setting wouldn't harm any application so why not. I just wanted to avoid panicking about this. It's far from the threat that php2shell was.

 

[WebHostingAce]

A new informational security advisory has been published, which may still be relevant even for servers running the latest patched PHP versions.

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

 

[pleskuser67553]

"... Since this setup is unlikely in practice, ..."
Really? Hackers will just upload their own script that configures the system the way they want it, then start the attack.

One strategy would be to set

in the additional directives, so that the value cannot be changed by the subscription owner via an .ini file. It will end up in the /opt/plesk/php/<version>/etc/php-fpm.d/*.conf file of the domain. But that can be tedious if you have many domains on a server as it needs to be done on a "per domain" basis.

Another solution can be

That will set the variable for all PHP instances using that version while it disables user .ini files altogether. As the session.upload_progress variable cannot be set by ini_set() it will keep an attacker from making the environment fit a malicious purpose.

Opinions on this?

Is it not as simple as adding/amending to session.upload_progress.enabled=0 the php.ini for each version handler?

 

[pleskuser67553]

Is it not as simple as adding/amending to session.upload_progress.enabled=0 the php.ini for each version handler?

View attachment 29786

No, because session.upload_progress.enabled can be set per directory with .user.ini, if my understanding here is correct PHP: List of php.ini directives - Manual

 

[pleskuser67553]

One strategy would be to set
in the additional directives, so that the value cannot be changed by the subscription owner via an .ini file. It will end up in the /opt/plesk/php/<version>/etc/php-fpm.d/*.conf file of the domain. But that can be tedious if you have many domains on a server as it needs to be done on a "per domain" basis.

Okay, for people who want a GUI method, I think this can be applied at the Service Plan level. Head to the PHP Settings tab, and scroll down to Additional directives.

Warning though, if a subscription is locked it won't sync this change, so you have to unlock for syncing or set up a new service plan and pull the locked subscriptions over to the new service plan.

[php-fpm-pool-settings]
php_admin_flag[session.upload_progress.enabled] = off

phpinfo() check.

 

[pleskuser67553]

Okay, for people who want a GUI method, I think this can be applied at the Service Plan level. Head to the PHP Settings tab, and scroll down to Additional directives.

However, this appears to deactivate and disable the ability to use Performance Booster for PHP, implying possible overwrite of existing Additional Directives at the domain level. Order of actions needs testing.

 

[brother4]

I think the focus will remain on PHP for a while longer now that even the mainstream news has covered it. Node.js, Java, and the others managed to stay under the radar, even though they also had major vulnerabilities—or take, for example, the Pip issue surrounding Python and the eMudhra/certifi package.

 

[pleskuser67553]

One strategy would be to set
in the additional directives, so that the value cannot be changed by the subscription owner via an .ini file. It will end up in the /opt/plesk/php/<version>/etc/php-fpm.d/*.conf file of the domain. But that can be tedious if you have many domains on a server as it needs to be done on a "per domain" basis.

Is there a reason why:

[php-fpm-pool-settings]
php_admin_flag[session.upload_progress.enabled] = off

is ignored in php.ini for the handler and ignored in panel.ini? Is [php-fpm-pool-settings] with php_admin_flag in these places something to be considered for development? I think this would be super helpful for admins. @Sebahat.hadzhi, any insight?