# Ъпгрейд на PHP или backport? Решението за стари системи

> Ъпгрейд на PHP или backport след PHP2Shell? Какви видове backport има, колко струват и кога само преходът към поддържана версия помага.

Източник: https://phpsos.de/bg/blog/php-upgrade-oder-backport/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** Дали ъпгрейд на 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 и по-стари](https://phpsos.de/bg/leistungen/php-migration-legacy/). Какво важи без официален ъпдейт, е описано в [PHP 8.1 и по-стари: какво важи сега](https://phpsos.de/bg/php2shell/php-8-1-und-aelter/). Този материал помага за преценката между двете.

## Какви видове backport има

„Backport“ е събирателно понятие. Винаги се има предвид, че корекция от по-нова версия се пренася в по-стара. Кой го прави и колко добре е проверено обаче се различава силно.

1. **Backport на дистрибуцията:** Debian, Ubuntu, Red Hat и други пренасят корекции за сигурност в PHP пакетите на своите поддържани издания. Номерът на версията при това често остава същият; според съобщенията например Ubuntu 24.04 след ъпдейта продължава да показва 8.3.6. Поправката се доказва чрез changelog-а на пакета и съобщенията за сигурност на дистрибуцията.
2. **Трети източник:** Хранилището sury.org на Ondřej Surý според съобщенията е предоставяло билдове за всички клонове от 5.6 до 8.5. То не е архивът за сигурност на Debian. Подробности има в [Хранилището sury.org](https://phpsos.de/bg/blog/sury-repository-php/).
3. **Backport на изходния код от PHP проекта:** За 7.4, 8.0 и 8.1 има минимални пачове в изходния код, но не и готови издания. Който ги ползва, трябва сам да компилира PHP, да го тества и занапред да го поддържа.
4. **Комерсиална дългосрочна поддръжка:** Доставчици като TuxCare ELS или Zend/HeroDevs предлагат поддръжка за стари версии. Дали и кога покриват PHP2Shell, трябва да се потвърди писмено; в известните източници това не беше доказано. Повече в [Дългосрочна поддръжка за стари версии на PHP](https://phpsos.de/bg/blog/langzeitsupport-alte-php-versionen/).

## Ъпгрейд на 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 и цикъл на издания](https://phpsos.de/bg/php/release-zyklus/).

> **Важно:**
> Независимо от пътя: след инсталирането всички PHP процеси трябва да бъдат рестартирани. Backport, който само стои на диска, не защитава, докато стари worker работят в паметта.

## Прагматичен ред за стари системи

1. **Веднага:** Задайте временните мерки според php.net или изключете системата временно от мрежата, ако няма наличен доказан пач.
2. **През следващите дни:** Инсталирайте доказан backport, по възможност от собствената дистрибуция или с писмено потвърждение на доставчика.
3. **Паралелно:** Проверете съвместимостта на приложението с поддържана версия и определете график.
4. **През следващите месеци:** Ъпгрейд до целевата версия, подготвен в тестово копие, с план за връщане назад.

Да гледате на backport-а като на мост, а не като на цел, е решаващата мисъл.

### Кога за това не Ви трябва доставчик

Ако Вашият сървър работи на поддържан Debian, Ubuntu или RHEL и дистрибуцията предоставя backport-а, достатъчен е обикновен ъпдейт с рестарт и поглед в changelog-а. Това може да направи сам опитен администратор. Помощ си струва при самостоятелни компилации, трети източници, много стари версии или приложение, чиято съвместимост никой вече не обхваща.

## Как помага PHP SOS конкретно?

- Проверяваме кои версии на PHP и източници на пакети работят на Вашите сървъри и дали има доказан пач.
- Инсталираме backport-ове, рестартираме и документираме доказателството чрез changelog-а.
- Тестваме Вашето приложение в копие срещу целевата версия и назоваваме несъвместимостите.
- Планираме и придружаваме ъпгрейда в рамките на [миграцията от PHP 8.1 и по-стари](https://phpsos.de/bg/leistungen/php-migration-legacy/).

## Извод

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 е покрита. В досега известните източници това не беше доказано.

## Източници

- [PHP: Поддържани версии](https://www.php.net/supported-versions.php)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [Debian Security Tracker](https://security-tracker.debian.org/)
- [Ubuntu Security Notices](https://ubuntu.com/security/notices)
