PHP vulnerability

Community Support
21

yes you have to update php 8.3 and hestia-php. 8.3 has update available (servers are unavaliable sometimes…everyone is updating at the moment) but i am not sure about hestia-php

22

manually or wait until hestiacp releases an update?

23

Mostly the responsible guys put there website offline until they have the possibility to update. So - according to there behavior you may consider to take your hestia offline to.

24

that’s what i did. all websites were down, hestiacp’s disbaled. When php updates for php versions came i enabled websites…hestia still disabled until i find info how to udpate hestia-php 8.5.9-1+ubuntu24.04

25

Hello,

I’m looking for advice on addressing PHP2Shell (CVE-2026-109618 and CVE-2026-109619) on an older Hestia server:

  • Debian 10 Buster, amd64.
  • HestiaCP 1.8.12.
  • The panel uses hestia-php 8.2.11.
  • Hosted websites use several PHP versions, including 5.6, 7.0, 7.1, 7.2 and 8.0. PHP 7.4 is also installed.
  • Many websites run legacy Kohana and cannot immediately move to PHP 8.

As temporary mitigations, we disabled session.upload_progress.enabled, set post_max_size=8M and upload_max_filesize=7M, and restarted all PHP-FPM workers, including the panel’s PHP. We understand these measures do not fully fix the vulnerabilities.

Both the Hestia and Sury repository Release URLs for Buster currently return 404 when checked from this server.

My questions are:

  1. Will a patched hestia-php package be available for Debian 10 and remain compatible with Hestia 1.8.12?
  2. Is there a recommended way to obtain patched legacy PHP packages for this setup, particularly PHP 7.4, while keeping PHP-FPM and Hestia’s per-domain PHP selection working?
  3. Has anyone successfully integrated CloudLinux ALT-PHP/Hardened PHP or Freexian PHP LTS with Hestia on Debian 10? Are there documented limitations or instructions?

I’m looking for a short-term solution while assessing migration options. I understand that updating the panel’s PHP and updating the websites’ PHP are separate tasks.

Thank you.

26

I have upgraded my php to PHP 8.3.36 which is the patched version, now I just need hestiacp to release an update for thesitacp PHP

27

I’ve just updated to PHP 8.5.12 on Ubuntu 24.04.1 LTS ARM (arm64).

28

Working on a build for it

but will take about 30 min more

29

once you release the build will it automatically patch our current hestiacp php?

30

ca i use this for hestia instaled on Ubuntu 24.04.4 LTS ?

31

Will the upcoming HestiaCP update contain only PHP security updates, or can we also expect support for PHP 8.6 to be added?

32

Yes, this works on Ubuntu 24.04 LTS too. The sury.org repository covers both Debian and Ubuntu, and the PHP2Shell backports were published for both, including the legacy PHP branches.

The steps are the same. Just confirm you have the Sury repo enabled

34

I don`t have it .. i used this Heads Up! Upcoming Critical PHP Security Release - #4 by eris

35

Can I run systemctl stop hestia to stop hestiacp but will it keep my websites running?

36

After updating the php packages yes

37

ok great, yes I have updated my php 8.3 to the patched version

38

another guide about php vulnerabilities and solutions

image
image1001×855 43.1 KB

39

After i updated to php -v PHP 8.3.36 (cli) (built: Oct 21 2026 08:18:34) (NTS) can i change back the settings on :
memory_limit=-1
post_max_size = 8M
session.upload_progress.enabled=0

40

After updating it is not needed any more…

41

Hi everyone,

first of all, thanks to the Hestia team for the quick response and guidance around php2shell (CVE-2026-109618 / CVE-2026-109619).

I’ve patched the system PHP versions from the sury repo on both of our servers (Debian 12 and Ubuntu 22.04). The panel’s own PHP is still open: as of today, hestia-php in apt.hestiacp.com is at 8.5.9 for both bookworm and jammy. Until a fixed build is out, I’ve closed port 8083 in the firewall.

Two quick questions:

  1. Is there a rough ETA for a hestia-php package based on 8.5.12?
  2. If we need panel access before then, do you recommend the php.ini mitigation in /usr/local/hestia/php/lib/php.ini (memory_limit=-1, post_max_size=8M, session.upload_progress.enabled=0)? Since hestia-php is 8.5, should fatal_error_backtraces=0 go in as well?

No pressure, I know you’re building it. Thanks again for all the work!

Best regards,
Klaus