Open Source Projects

Hotfix: PHP security updates for MultiPHP versions

PHP released fixes today for CVE-2026-109618 and CVE-2026-109619: critical, unauthenticated remote code execution affecting every PHP version up to 8.5.11, including PHP-FPM, which every iNetPanel site and the panel itself run on. They are fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, which sury.org already publishes for Debian 12 and 13.

What to do on every iNetPanel server

1. Update iNetPanel to 1.28.1 (Settings -> Updates, or ).
2. Run as root. It installs the fixed PHP packages; PHP-FPM restarts on its own.

If you skip step 2, the nightly system update (00:00 by default) installs them. Check what you are running with .

What this release fixes

On servers installed with iNetPanel 1.26.0 or later, a PHP version added through MultiPHP never received updates. The installer's pin that stops a second PHP stack being pulled in also blocked upgrades of versions installed on purpose, so sites on those versions would have stayed on the vulnerable build. The nightly update () now lets every installed PHP version update from sury, while versions that are not installed stay blocked. Servers installed before 1.26.0 were not affected by this. The panel's own PHP version was always updated normally.

PHP 8.1 and older cannot be fixed

php.net has released no fix for PHP 8.1 or older, and none is available from sury. Move any site on PHP 5.6-8.1 to PHP 8.2 or later (Multi-PHP -> Per-Domain PHP Version).

Security and hardening release.

SECURITY (GHSA-mcpc-fxm3-3973, reported by nullsleuth): the setup wizard staged three files for privileged sudo cp in world-writable /tmp under fixed names. A local unprivileged user could pre-create the path as a symlink and have the root cp copy a root-only file into a world-readable destination. All staging moves to /var/lib/inetpanel/staging (owner-only 0700) with unlink-then-O_EXCL writes. Affects fresh installs only; the wizard is locked after setup.

FIXED (#24): MultiPHP could never install any PHP version. The installer pins every version except the panel's own to Pin-Priority -1, which in APT means 'never install' - so 'apt-get install php8.3-fpm' returned 'has no installation candidate' on every fresh install. MultiPHP now lifts the block for the requested version only, for the duration of the run, leaving the pin's real job (stopping phpmyadmin dragging in a second PHP stack) intact.

FIXED: panel_update deleted its own Apache origin config on every nightly run. /etc/cron.d entries do not inherit PATH from /etc/crontab, so apache2ctl and the a2* helpers were unreachable and a failed configtest was misread as 'my config is broken'.

FIXED: per-domain PHP version switching was broken - its pool copy and removal matched no sudoers rule, so the vhost was repointed at an FPM socket that was never created. Now delegated to multiphp_manage.

HARDENING: hosted sites no longer serve dot-files (.git, .env) or directory listings, existing vhosts included. Static-asset cache headers added (conservative: fonts 30d, images 7d, CSS/JS 1h, HTML untouched). Both sudoers writers now validate with visudo before installing, and four unrestricted root grants (sed, usermod, dpkg, apt-get) were removed after verifying each unused. mod_remoteip is configured at install instead of up to a week later. Backup-restore no longer generates shell scripts to run through a wildcard sudo grant.

Hotfix: the weekly Cloudflare RemoteIP refresh deleted its own Apache config every Monday. /etc/cron.d files do not inherit PATH from /etc/crontab, so apache2ctl and the a2* helpers (all in /usr/sbin) were unreachable under cron; the script read that as its own config being invalid and removed it, leaving a dangling symlink. After the next Apache reload mod_remoteip went inert, every tunnelled request appeared to come from 127.0.0.1, and because fail2ban's ignoreip covers 127.0.0.1/8 that made all tunnelled traffic invisible to every jail. The script now sets PATH itself, verifies its tools before writing anything, checks install's exit status, and no longer assumes a failing configtest is its own fault. Recommended for every install behind a Cloudflare Tunnel.