News
PHP2Shell: contained, and patched
22 October 2026
On 21 October the PHP project published two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, known together as PHP2Shell. They are in every PHP from 5.4 on, need no login and no particular script, and were being attacked within a day. Each lets an attacker run their own code through a site’s PHP.
On OmegaPanel, the bugs could not reach the server. Every hosting account runs its PHP in a container of its own. An attacker who used PHP2Shell against a site would land inside that site’s container, with that site’s files and its database. They would not reach the server it runs on, and not any other customer’s account. Getting from the container to the server would take a second, separate vulnerability.
That is containment, not immunity: the site itself would still be compromised. So the fix ships as well, in the next update:
- Session upload progress is switched off for every site, on every PHP
version, in a way a site’s own
.user.inicannot undo. It is how one of the two bugs is reached. - PHP is upgraded in place. After the update, the panel upgrades the PHP in every account’s container to the fixed build, one account at a time, and checks that the site is serving afterwards. That is PHP 8.2.35, 8.3.36 and 8.4.27, and the patched builds of 5.6 to 8.1. An account that is stopped is upgraded when it next starts. Webmail’s PHP is upgraded the same way.
- PHP 5.6 to 8.1 no longer get releases from the PHP project. Their patched builds come from the same Debian packages the panel installs PHP from, and the fix there is narrower than on 8.2 and later. Moving such a site to 8.2 or newer is the better answer, and the panel’s version check says before the move whether the site’s code will run there.
Operators: install the update when the panel offers it. Nothing else needs doing.