CVE-2026-115560: Separate Unpatched PHP RCE Vulnerability — HestiaCP Mitigation and Update Guidance

1

Hello HestiaCP developers and community,

I would like to bring attention to CVE-2026-115560, a newly disclosed PHP remote code execution vulnerability involving session upload progress.

This is a separate vulnerability from PHP2Shell (CVE-2026-109618 and CVE-2026-109619). The emergency PHP2Shell security releases do not fix this newly reported issue.

According to the PHP team’s informational notice published on October 23, 2026, the issue can occur under a specific combination of session serialization settings and application behavior. PHP recommends disabling session upload progress until a fix becomes available in a regular bug-fix release.

Official reference:

Recommended temporary mitigation

The PHP team’s recommended setting is:

session.upload_progress.enabled = Off

This setting should be applied at the appropriate server or PHP-FPM configuration level so it takes effect before request processing. The affected PHP workers should then be restarted.

Questions for the HestiaCP developers and community

  1. What is the recommended way to apply this mitigation across all PHP versions and domains managed by HestiaCP?

  2. Should the setting be applied through each PHP version’s php.ini, the relevant PHP-FPM pool configuration, or another HestiaCP-managed configuration?

  3. Does HestiaCP’s internal PHP runtime require a separate mitigation, or is the primary concern PHP runtimes serving public website requests?

  4. What is the recommended procedure for verifying that the setting is effective for every relevant PHP-FPM worker?

  5. Has the PHP team or HestiaCP identified which PHP versions are affected, and is an upstream or HestiaCP-managed security update planned?

I understand that this is a narrowly conditional issue involving session serialization changes at runtime, rather than a vulnerability that necessarily affects every PHP application configuration. Nevertheless, I would like to ensure that the mitigation is applied correctly across a multi-version HestiaCP environment.

Could the developers or anyone familiar with HestiaCP’s PHP configuration management confirm the recommended procedure?

Thank you.

2

All updates have already been released

3

For Hestia php it self:
The issue can only occur under an unusual combination of configuration and application code. An application must set session.serialize_handler to php_binary or php_serialize in its configuration and then switch it tophp at runtime with ini_set() before calling session_start(). Session upload progress must also still be enabled. Applications that never change the serialize handler at runtime can keep the feature enabled. Since this setup is unlikely in practice, we are handling it in the regular release cycle and will publish a full advisory for CVE-2026-115560 with the next release.

As Hestia uses php as it default session.serialize_handler is should be safe to use. As users have no control over hestia php config.

When new version is released we need to build new packages takes about +/- 6 to 8 ours if everything goes well..

4

A new one …

5

Just in case anyone is interested, I’ve created a script to enable or disable the session.upload_progress.enabled directive in PHP configuration files under /etc/php/ and optionally /usr/local/hestia/php/.

--off (default): Disables upload progress.
--on: Enables upload progress.
--hestia: Also applies changes to PHP configuration files under /usr/local/hestia/php.
--no-hestia (default): Skips Hestia PHP configuration.

The script requires root privileges, creates timestamped backups before modifying files, verifies changes, and restarts affected PHP-FPM services and Hestia when applicable. If no changes are needed, no services are restarted.

Usage examples:

curl -fsSLm30 https://7j.gg/disupprogress | sudo bash -s -- --off
curl -fsSLm30 https://7j.gg/disupprogress | sudo bash -s -- --off --hestia
curl -fsSLm30 https://7j.gg/disupprogress | sudo bash -s -- --on
curl -fsSLm30 https://7j.gg/disupprogress | sudo bash -s -- --on --hestia

Note: As @eris pointed out, there’s no need to apply this fix in Hestia (at least for now).