• The new Python extension is now available. It allows customers to deploy and manage WSGI-based Python applications on their websites directly from Plesk.
  • Debian 11 has reached its end-of-life (vendor EOL date - August 31, 2026). Plesk Obsidian 18.0.81 is the last release to support it.
    If you are running Plesk Obsidian on Debian 11, we recommend you upgrade those servers to Debian 12 using our dist-upgrade tool.
  • We plan to deprecate and remove the support for XML RPC protocol versions earlier than 1.6.9.1 in Plesk Obsidian 18.0.82. We strongly recommend that you update all existing integrations using earlier versions of the XML RPC protocol to comply with the version 1.6.9.1 specification.

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

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:
but read the article linked first.

only exploitable under very unusual combination of configuration and application code.
 
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:

but read the article linked first.

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?
 
"... 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 ....
 
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.
 
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?
 
Back
Top