News

0.12.0: security updates inside every site’s container

25 October 2026

October has brought one security fix after another, in PHP, Node.js, nginx, webmail and the server’s own kernel. PHP2Shell, below, was the loudest. The pattern behind it mattered more: a hosting account’s container was built once, and after that nothing in it was ever updated. 0.12.0 changes that, and fixes the rest of the month’s list.

Every site’s container now gets its security updates. Since 0.11.1 the panel has kept PHP patched in each account. Now it does the same for everything else in the container: Node.js, .NET, Java, Python, and the system libraries underneath them (OpenSSL, PCRE2, curl and the rest). That includes CVE-2026-111497, a bug in the Brotli decompression library that Node.js uses, for which working attack code is public. After the update, the panel brings each account to the fixed versions (Node.js 22.23.4, .NET 8.0.32) one account at a time, restarts a site only if it was running the replaced files, and rebuilds the images new sites start from. It never moves a site to a new major version of its runtime.

nginx 1.30.6 with OpenSSL 3.5.9. nginx fixed five vulnerabilities on 14 October. Three of them apply to how the panel uses nginx: an overflow when evaluating string expressions (CVE-2026-93479), body injection over HTTP/3 (CVE-2026-95101), and an overflow with alias combined with a rewrite (CVE-2026-15176). The update installs the new build only after nginx -t accepts the configuration, and puts the old one back if it does not.

Webmail is Roundcube 1.7.5. Its last two releases fixed a stored cross-site scripting attack that needed no click at all, delivered in an email attachment, and command injection against the mail server. Webmail keeps its settings and contacts, and nobody is signed out.

The per-account cache no longer accepts the commands of CVE-2026-63639. Each account’s object cache runs on the server itself, so a flaw in it is a way from a site to the server. Debian has no fixed package yet, and Ubuntu offers one only through its paid Pro subscription. The panel does not wait for either: it switches the affected command off, along with two other commands no site needs. Each cache is emptied once when this takes effect, and fills again on its own.

Your server’s own updates still matter. Several Linux kernel bugs on CISA’s list of actively exploited vulnerabilities are ways out of any container, OmegaPanel’s included. They are fixed by the operating system’s own updates, which take effect only after a reboot. When the Server page shows Pending reboot, reboot the node from there.

Operators: install 0.12.0 when the panel offers it. If you sell through WHMCS or Blesta, update the module files there too; the release notes on the Server page list the rest. On a server with many sites, the container updates take a few hours in the background.

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 another customer’s site. Getting from the container to the server would take a second, separate vulnerability.

Webmail is the exception. It runs in one container per server, shared by every mailbox on it, and its login page is public. An attack through webmail’s PHP would reach webmail’s data and the mail of whoever uses webmail on that server, though still not the server itself.

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.ini cannot 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.