Накратко: Който иска да му бъде направена актуализация на PHP, се нуждае от повече от нови пакети: решаващи са правилното състояние на пакетите, рестартирането на всички PHP процеси и доказателство за това. Точно това предоставя нашата услуга за пач на PHP. Получавате писмено доказателство за всеки сървър, което можете да представите вътрешно или пред трети лица.
Защо актуализацията на PHP сама по себе си често не стига
От 21.10.2026 г. има пачове за уязвимостите на PHP2Shell CVE-2026-109618 и CVE-2026-109619. BSI препоръчва незабавна актуализация. На практика виждаме три типични спънки.
Първо, номерът на версията не винаги показва истинското състояние. Дистрибуциите и хостинг доставчиците понякога внасят backport-ове; тогава например Plesk продължава да показва 8.2.34, въпреки че пакетът е с поправка. Второ, след внасянето често продължават да работят стари PHP процеси. Новите файлове на диска не защитават, докато старите worker процеси работят в паметта. Трето, на един сървър често работят няколко PHP версии паралелно и една от тях бива забравена.
Актуализация на PHP: поправените версии
| Клон | Поправено от | Предишно състояние | Бележка |
|---|---|---|---|
| PHP 8.5 | 8.5.12 | 8.5.11 | допълнително проверете fatal_error_backtraces |
| PHP 8.4 | 8.4.27 | 8.4.26 | |
| PHP 8.3 | 8.3.36 | 8.3.35 | |
| PHP 8.2 | 8.2.35 | 8.2.34 | поддръжката приключва на 31.12.2026 г. |
| PHP 8.1 и по-стари | няма официални актуализации | – | само минимални backport-ове на изходния код за 7.4, 8.0, 8.1 |
При пакети от дистрибуции или от хостинг доставчици меродавно не е числото след „PHP“, а състоянието на пакета, което доставчикът потвърждава като поправено. Как да го проверите сами, е описано на страницата Как да проверите правилно PHP версията и състоянието на пача.
Как помага PHP SOS конкретно?
- Опис: Събираме всички PHP инсталации на сървъра, режима на работа (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed) и коя версия ползва кой уебсайт.
- Внасяне на актуализацията: Инсталираме поправените версии от източника на пакети на Вашата дистрибуция, на Вашия панел или на официалния проект. За контейнери изграждаме с Вас нови образи (images).
- Рестартиране на всички процеси: Рестартираме изцяло PHP-FPM, Apache, LiteSpeed или съответните worker процеси и проверяваме, че никой процес не е по-стар от актуализацията. Основите са описани на страницата Рестартиране на PHP-FPM и на всички worker процеси.
- Проверка на функциите: Отваряме най-важните страници и функции, например началната страница, входа, формулярите и касата, и проверяваме протоколите за грешки.
- Доказателство: Получавате за всеки сървър протокол с версия, състояние на пакетите, момент на рестартирането и неуредени въпроси.
Типична проверка след рестартирането изглежда така:
# Версия на PHP CLI и на двоичния файл на FPM (пътят зависи от системата)
php -v
php-fpm8.3 -v
# Време на стартиране на FPM процесите: трябва да е след актуализацията
ps -o pid,lstart,cmd -C php-fpm8.3
Особени случаи: панели, контейнери и няколко PHP версии
На сървъри с Plesk или cPanel PHP версиите често идват от източниците на пакети на панела, а не от дистрибуцията. Там проверяваме всяка инсталирана версия поотделно, дори и такива, които в момента не са зададени на никой уебсайт. Неизползваните остарели версии премахваме след уговорка, за да не бъдат случайно активирани отново.
В Docker и Kubernetes среди актуализацията на хоста не стига. PHP е в образа (image) и само новоизграден образ с поправена основа, внедрен във всички работещи контейнери, затваря уязвимостта. Проверяваме и дали по-стари образи в регистри или във внедрявания още се ползват. Подробности има на страницата Пачване на PHP в Docker контейнери.
При mod_php PHP работи директно в процеса на Apache. Екипът на PHP оценява риска там като най-висок. Затова след актуализацията самият Apache трябва да се рестартира изцяло; обикновено презареждане на конфигурацията не винаги е достатъчно.
Какво получавате от нас
- протокол за пача за всеки сървър: инсталирани пакети, версии, източник, момент
- доказателство, че всички PHP процеси са рестартирани
- списък на проверените уебсайтове и функции
- бележки за системи, които не са могли да бъдат пачнати, с обосновка
- препоръка за по-нататъшния път, например при PHP 8.2 заради близкия край на поддръжката
Какво ни е нужно от Вас
- Достъп: SSH с администраторски права или достъп до панела (Plesk, cPanel и подобни)
- Прозорец за поддръжка: кога е позволено кратко рестартиране
- Лице за контакт: за въпроси и за одобрението след проверката на функциите
- Резервни копия: потвърждение, че има актуален архив, или поръчка да се направи такъв предварително
- Бележки за собствени разработки: особени PHP разширения или конфигурации, които трябва да се вземат предвид
При споделен хостинг без собствен достъп до сървъра не можем сами да пачваме. Тогава Ви помагаме да зададете правилните въпроси на хостинг доставчика и да оцените отговора.
Какво не обещаваме
Услугата за пач затваря известната уязвимост. Тя не отговаря на въпроса дали сървърът е бил компрометиран преди актуализацията и не премахва внедрен злонамерен софтуер. Ако искате да знаете това, подходящата поръчка е спешната помощ при PHP2Shell с търсене на следи.
За PHP 8.1 и по-стари вече няма официални актуализации. Тук прилагаме временни мерки и препоръчваме преминаване към поддържана версия. Гаранция за съвместимост с Вашия CMS не даваме по памет, а я проверяваме по системните изисквания на производителя.
Често задавани въпроси
Защо сървърът ми показва стара PHP версия и след актуализацията?
Причините могат да са две. Или дистрибуцията е внесла backport, тогава номерът на версията остава същият, въпреки че пакетът е с поправка. Или стари PHP процеси още работят в паметта и трябва да се рестартират.
Кои PHP версии затварят PHP2Shell?
Уязвимостта е поправена в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35, публикувани на 21.10.2026 г. При пакети от дистрибуции е меродавно състоянието на пакета, което доставчикът потвърждава като поправено.
Може ли актуализацията да осакати уебсайта ми?
Актуализация в рамките на една и съща основна версия, например от 8.3.35 до 8.3.36, по правило е безопасна. Кратко рестартиране на PHP процесите обаче е необходимо. Съгласуваме с Вас времевия прозорец и след това проверяваме страниците.
С пача всичко ли е уредено?
За самата уязвимост да, щом всички процеси са рестартирани. Дали някой е проникнал преди пача, той не показва. За това е нужна отделна проверка.