Няколко версии на PHP на един сървър: пачнете всяка поотделно

Накратко: Ако на един сървър работят няколко версии на PHP, след PHP2Shell всяка трябва да бъде проверена, актуализирана и рестартирана поотделно. Типични източници са операционната система, хостинг панели като Plesk или cPanel, външни източници като sury.org или Remi, CloudLinux, LiteSpeed и самостоятелно компилирани версии. Едва пълен списък от пакети, файлове и работещи процеси показва дали наистина няма пропусната версия.

Забравената версия

Сървър, който работи от няколко години, събира версии на PHP както таванът старите мебели. Панелът донесе три клона, за един клиент се добави по-стара версия от външен източник, операционната система има своя. Всяка от тях някога е била инсталирана с основателна причина. Само че днес никой не помни коя още е нужна.

След PHP2Shell точно това е проблем. Поправките излязоха на 21 октомври 2026 г. за PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Всяка инсталация на сървъра ги получава обаче по собствен път, от собствен поддържащ на пакета и в собствено време. За PHP 8.1 и по-стари има само минимални backport-ове на изходния код. Който актуализира само основната версия, оставя другите отворени.

Откъде идват многото версии

Следният преглед назовава типични източници и примерни пътища. Точните пътища се различават според версията и дистрибуцията.

Особено коварни са пакетите от sury.org, защото ползват същите пътища като дистрибуцията. Дали php8.3 идва от Debian или от sury.org, показва едва източникът на пакета. Особеностите описват статиите Хранилището sury.org и Хранилището Remi. Как Plesk управлява своите версии, описва страницата Plesk сървър: проверка и пачване на версиите на PHP.

Намиране на всички PHP инсталации

Надежден списък се получава от три гледни точки. Командите са само за четене и в зависимост от сървъра могат да работят известно време.

# 1. Пакети: какво знае управлението на пакетите
dpkg-query -W -f='${Package}\t${Version}\n' '*php*' 2>/dev/null | grep -E "fpm|cli|cgi|mod-php|lsphp"
rpm -qa 2>/dev/null | grep -iE "php.*(fpm|cli|cgi|litespeed)|^php-[0-9]|^ea-php|^alt-php" | sort

# 2. Файлове: изпълними PHP бинарни файлове, и извън управлението на пакетите
find / -xdev -type f \( -name 'php' -o -name 'php[0-9]*' -o -name 'php-fpm*' -o -name 'php-cgi*' -o -name 'lsphp*' \) -perm -u+x 2>/dev/null

# 3. Процеси: какво наистина работи в момента, с време на стартиране
ps -eo pid,user,lstart,cmd | grep -E "[p]hp-fpm|[p]hp-cgi|[l]sphp|[a]pache2|[h]ttpd|[f]rankenphp"

Сверете трите списъка. Файл без пакет сочи към самостоятелно компилирана или ръчно копирана версия. Процес без съответстващ файл може да сочи към изтрита, но още работеща инсталация. При Apache проверете допълнително дали е зареден PHP модул, например с apache2ctl -M или httpd -M. Контейнерите и Kubernetes подовете се появяват в тези списъци само отчасти и изискват отделна проверка на образите.

Пачване на всяка версия поотделно

Щом всяка инсталация има ред във Вашия списък, за всяка следва един и същ ход:

1. Изяснете отговорността: Пачът идва ли от дистрибуцията, от панела, от външен източник, или от Вас самите?
2. Оценете състоянието: официално коригирана версия, потвърден backport, неизяснено или отворено.
3. Актуализирайте: по пътя на съответния източник, не по друг.
4. Рестартирайте: услугата на тази версия, не само основната. При mod_php - уеб сървъра. Подробности има в Рестартиране на PHP-FPM и на всички worker-и.
5. Проверете: сравнете времето на стартиране на процесите с момента на актуализацията.
6. Документирайте: версия, състояние на пакета, доказателство, време на рестарта.

За версии, за които няма пач, до миграцията важат преходните мерки от php.net. Приложете ги за всяка версия отделно, защото всяка инсталация има собствен php.ini и собствени пулове.

Коя версия ползва командният ред, коя - контейнерът?

Две области особено често изпадат от търсенето. Първата е командният ред. При Debian и Ubuntu системата за алтернативи решава кой бинарен файл стои зад командата php. update-alternatives --display php показва кои версии са регистрирани и коя важи в момента. Cron задачи, които извикват фиксиран път като /usr/bin/php7.4, обаче заобикалят тази настройка. Затова си заслужава да погледнете crontab файловете на всички потребители и конфигурацията на панели, които създават собствени cron задачи.

Втората област са контейнерите. Docker контейнер на сървъра носи собствена версия на PHP, която не се появява в нито един списък с пакети на хоста. docker ps показва работещите контейнери; дали вътре има PHP и в коя версия, разкрива поглед в образа или php -v в контейнера. Пачът там се прави не на хоста, а чрез ново изграждане на образа и подмяна на контейнера.

По-малкото е по-сигурно

Най-добрата проверка е онази, която не се налага да правите. Всяка инсталирана версия на PHP удвоява усилията при следващата уязвимост. След PHP2Shell затова си заслужава ясно правило: всяка версия на сървъра има нужда от цел и от отговорно лице. Онова, което няма, първо се деактивира и след период на наблюдение се премахва. Повече по темата има в статията Изключване на стари версии на PHP в хостинг панела.

Как помага PHP SOS конкретно?

• Съставяме за Вашите сървъри пълен списък на всички PHP инсталации от пакети, файлове, процеси и контейнери.
• Изясняваме за всяка версия произхода, отговорността и състоянието на пача.
• В рамките на PHP Patch Service актуализираме всяка версия, рестартираме всяка услуга и документираме състоянието.
• Заедно с Вас определяме кои версии остават, и премахваме останалите контролирано.

Често задавани въпроси

Източници

• php.net: Съобщения за сигурност
• php.net: Поддържани версии
• Red Hat Security Bulletin RHSB-2026-013