Накратко: Дали ъпгрейд на PHP или backport е правилният избор, зависи от това колко още трябва да работи Вашата система и колко добре е доказан backport-ът. Backport на собствената дистрибуция върху поддържана операционна система е пълноценен път. Backport-овете на изходния код, трети източници и комерсиалната дългосрочна поддръжка за PHP 8.1 и по-стари са мостове със срок. В дългосрочен план помага само преходът към версия на PHP, която PHP проектът още поддържа официално.
Защо въпросът след PHP2Shell е спешен
На 21.10.2026 г. PHP проектът отстрани PHP2Shell във версиите 8.5.12, 8.4.27, 8.3.36 и 8.2.35. За PHP 8.1 и по-стари вече няма официални издания, а само минимални backport-ове на изходния код за 7.4, 8.0 и 8.1. Според специализираната преса са засегнати почти всички версии чак до PHP 5.4.
Така много оператори на стари системи стоят пред един и същи въпрос: достатъчно ли е уязвимостта някак да се закърпи, или сега трябва да дойде ъпгрейдът, отлаган с години? Какво означава ъпгрейдът на практика, описва нашето предложение за миграция от PHP 8.1 и по-стари. Какво важи без официален ъпдейт, е описано в PHP 8.1 и по-стари: какво важи сега. Този материал помага за преценката между двете.
Какви видове backport има
„Backport“ е събирателно понятие. Винаги се има предвид, че корекция от по-нова версия се пренася в по-стара. Кой го прави и колко добре е проверено обаче се различава силно.
- Backport на дистрибуцията: Debian, Ubuntu, Red Hat и други пренасят корекции за сигурност в PHP пакетите на своите поддържани издания. Номерът на версията при това често остава същият; според съобщенията например Ubuntu 24.04 след ъпдейта продължава да показва 8.3.6. Поправката се доказва чрез changelog-а на пакета и съобщенията за сигурност на дистрибуцията.
- Трети източник: Хранилището sury.org на Ondřej Surý според съобщенията е предоставяло билдове за всички клонове от 5.6 до 8.5. То не е архивът за сигурност на Debian. Подробности има в Хранилището sury.org.
- Backport на изходния код от PHP проекта: За 7.4, 8.0 и 8.1 има минимални пачове в изходния код, но не и готови издания. Който ги ползва, трябва сам да компилира PHP, да го тества и занапред да го поддържа.
- Комерсиална дългосрочна поддръжка: Доставчици като TuxCare ELS или Zend/HeroDevs предлагат поддръжка за стари версии. Дали и кога покриват PHP2Shell, трябва да се потвърди писмено; в известните източници това не беше доказано. Повече в Дългосрочна поддръжка за стари версии на PHP.
Ъпгрейд на PHP или backport: сравнението
| Критерий | Ъпгрейд до поддържана версия | Backport (според вида) |
|---|---|---|
| Защита срещу PHP2Shell | Да, с 8.2.35, 8.3.36, 8.4.27 или 8.5.12 | Да, ако е пълен и доказан |
| Бъдещи ъпдейти за сигурност | Официално до края на поддръжката на версията | Само докато съответният доставчик поддържа |
| Доказателство | Номер на версията плюс рестарт | Changelog на пакета с номера на CVE, потвърждение от доставчика |
| Усилия сега | От средни до големи, нужни са тестове за съвместимост | Малки при дистрибуция, големи при самостоятелна компилация |
| Усилия по-късно | От малки до следващия скок на версията | Растат с всяка нова уязвимост |
| Риск за приложението | Несъвместимости със стар код и разширения | Малък, поведението остава до голяма степен същото |
| Пригодност като трайно решение | Да | Само backport на дистрибуцията в рамките на поддържана операционна система |
Редът „Усилия по-късно“ е най-важният. PHP2Shell няма да е последната уязвимост. Всеки месец на версия без официална поддръжка означава, че следващото съобщение отново ще постави същия въпрос.
Коя целева версия при ъпгрейд?
Според php.net за всеки клон на PHP важи: две години активна поддръжка, след това две години само корекции за сигурност. От това следват тези крайни дати за поддръжката на сигурността:
| Версия | Поддръжка на сигурността до |
|---|---|
| PHP 8.2 | 31.12.2026 г. |
| PHP 8.3 | 31.12.2027 г. |
| PHP 8.4 | 31.12.2028 г. |
| PHP 8.5 | 31.12.2029 г. |
Ъпгрейдът до 8.2 затова е само кратка междинна станция. Който така или иначе мигрира, трябва да се цели във версия с по-дълъг хоризонт, доколкото CMS, магазинът и разширенията я поддържат. Това проверявате в системните изисквания на производителя, а не по памет. Как работи цикълът на издания, обяснява Версии на PHP и цикъл на издания.
Независимо от пътя: след инсталирането всички PHP процеси трябва да бъдат рестартирани. Backport, който само стои на диска, не защитава, докато стари worker работят в паметта.
Прагматичен ред за стари системи
- Веднага: Задайте временните мерки според php.net или изключете системата временно от мрежата, ако няма наличен доказан пач.
- През следващите дни: Инсталирайте доказан backport, по възможност от собствената дистрибуция или с писмено потвърждение на доставчика.
- Паралелно: Проверете съвместимостта на приложението с поддържана версия и определете график.
- През следващите месеци: Ъпгрейд до целевата версия, подготвен в тестово копие, с план за връщане назад.
Да гледате на backport-а като на мост, а не като на цел, е решаващата мисъл.
Кога за това не Ви трябва доставчик
Ако Вашият сървър работи на поддържан Debian, Ubuntu или RHEL и дистрибуцията предоставя backport-а, достатъчен е обикновен ъпдейт с рестарт и поглед в changelog-а. Това може да направи сам опитен администратор. Помощ си струва при самостоятелни компилации, трети източници, много стари версии или приложение, чиято съвместимост никой вече не обхваща.
Как помага PHP SOS конкретно?
- Проверяваме кои версии на PHP и източници на пакети работят на Вашите сървъри и дали има доказан пач.
- Инсталираме backport-ове, рестартираме и документираме доказателството чрез changelog-а.
- Тестваме Вашето приложение в копие срещу целевата версия и назоваваме несъвместимостите.
- Планираме и придружаваме ъпгрейда в рамките на миграцията от PHP 8.1 и по-стари.
Извод
Backport-ът на дистрибуцията е пълноценен път, всички останали backport-ове са мостове. Който е заседнал на PHP 8.1 или по-стар, трябва да използва backport-а, за да спечели време за ъпгрейда, а не за да го отлага още.
Често задавани въпроси
Също толкова сигурен ли е backport, колкото и ъпгрейд?
За конкретно поправената уязвимост backport може да е равностоен, ако е пълен и доказан. Той обаче поправя само това, което е пренесено назад. Ъпгрейдът до поддържана версия носи допълнително всички бъдещи официални ъпдейти за сигурност.
По какво разпознавам, че моят backport покрива PHP2Shell?
По changelog-а на пакета: в него трябва да са посочени номерата CVE-2026-109618 и CVE-2026-109619. Под Debian и Ubuntu това показва apt-get changelog, в семейството на RHEL rpm -q --changelog. Номерът на версията сам по себе си не е доказателство.
Докога PHP 8.2 получава ъпдейти за сигурност?
Според php.net поддръжката за сигурност на PHP 8.2 приключва на 31.12.2026 г. Който днес актуализира до 8.2, трябва веднага да планира и следващата стъпка.
Има ли смисъл от комерсиална дългосрочна поддръжка за стари версии на PHP?
Тя може да бъде мост, ако ъпгрейд в кратък срок е невъзможен. Поискайте писмено потвърждение дали и от кога PHP2Shell е покрита. В досега известните източници това не беше доказано.