Накратко: PHP End of Life означава: проектът PHP вече не доставя актуализации за сигурност за този клон. PHP2Shell показва ясно последствията, защото за PHP 8.1 и по-стари няма официална поправка, а PHP 8.2 приключва на 31.12.2026. Който днес работи на стар клон, трябва да планира преминаването още сега, а не при следващия спешен случай.
Какво означава PHP End of Life
Всеки клон на PHP, например 8.2 или 8.3, се поддържа от проекта PHP само за ограничен период. Първо има корекции на грешки и актуализации за сигурност, по-късно само актуализации за сигурност. След това поддръжката приключва напълно. Актуалните периоди php.net публикува на страницата за поддържаните версии.
След края на поддръжката софтуерът продължава да работи. Ако обаче стане известна нова уязвимост, от проекта PHP вече няма пач. Сървърът остава уязвим, докато някой друг не го поправи или докато не преминете към поддържан клон.
За ръководството и ИТ ръководителите това е преди всичко въпрос на планиране. Миграцията може да се подготви спокойно. Под натиск на времето след критично съобщение тя става скъпа и рискова.
Какво показва PHP2Shell за остарелите версии
На 21.10.2026 проектът PHP публикува пачове за две критични уязвимости, CVE-2026-109618 и CVE-2026-109619. И двете позволяват отдалечено изпълнение на злонамерен код без вход в системата и са оценени с CVSS v4.0 9,2. Според специализираната преса са засегнати почти всички версии чак до PHP 5.4.
| Клон | Статус според проекта PHP | Поправка за PHP2Shell |
|---|---|---|
| PHP 8.5 | поддържан | 8.5.12 |
| PHP 8.4 | поддържан | 8.4.27 |
| PHP 8.3 | поддържан | 8.3.36 |
| PHP 8.2 | поддържан до 31.12.2026 | 8.2.35 |
| PHP 8.1, 8.0, 7.4 | няма официални актуализации | само минимални backport корекции на изходния код |
| PHP 7.3 и по-стари | няма официални актуализации | няма backport от проекта PHP |
За 8.1 и по-стари остава само пътят през backport корекции от дистрибуции или хостинг доставчици. Те често продължават да показват старата версия, въпреки че са пачнати. Дали backport е внесен, може да потвърди с обвързваща сила само доставчикът. Подробности има на страницата PHP 8.1 и по-стари: какво важи сега, а пълния преглед на страницата Кои версии на PHP са засегнати?.
PHP 8.2 още е получил корекцията за PHP2Shell, но достига края на поддръжката на 31.12.2026. Който мигрира сега от 8.1, трябва да избере директно по-нов клон.
Рисковете от остарели версии на PHP накратко
На преден план е рискът за сигурността, но той не е единственият. Остарелите версии на PHP водят до още проблеми:
- Няма пачове за нови уязвимости: Всяка бъдеща слабост остава отворена или зависи от backport корекции на трети страни.
- Остарели библиотеки: Актуалните пакети изискват по-нови клонове на PHP. Корекциите за сигурност в библиотеките тогава не могат да се внесат, както показва наръчникът composer audit.
- Зависимост от доставчика: Хостинг доставчиците таксуват за стари версии надценка или прекратяват експлоатацията им. Срокът тогава определя доставчикът, а не Вие.
- Проблеми с доказването: Пред застрахователи, възложители или при одити неподдържана версия трудно може да се обоснове. Дали от това възникват договорни или правни последици, изяснете със застрахователя или с адвокат.
- Растящо усилие за миграция: Колкото по-голямо е разстоянието до актуалната версия, толкова повече код трябва да се адаптира.
Особено често са засегнати по-стари магазинни системи и дълго неприпипвани индивидуални разработки. Типичен пример е Shopware 5, който често още работи на по-стари клонове на PHP.
Инвентаризация: кои версии на PHP работят при Вас?
Първата стъпка е пълната картина. На много сървъри паралелно работят няколко версии на PHP, например за стар уебсайт, който никой вече не държи под око. Тези команди само четат:
# Версия на командния ред
php -v
# Инсталирани версии при Debian/Ubuntu
ls /etc/php/
# Инсталирани версии в Plesk
ls /opt/plesk/php/ 2>/dev/null
# Работещи PHP процеси с версията в името
ps -eo user,cmd | grep -E "[p]hp-fpm|[p]hp[0-9.]*-cgi|[l]sphp" | sort | uniq -c
Запишете за всеки уебсайт: домейн, версия на PHP, режим на работа, CMS с версия, отговорно лице. Този списък е същевременно основа за Вашия авариен план. При споделен хостинг версиите обикновено ще намерите в клиентското меню на хостинг доставчика.
Планиране на миграцията: как да действате
Миграцията към поддържан клон по правило следва едни и същи стъпки, независимо от системата:
- Определете целта: изберете клон, който според php.net ще се поддържа възможно най-дълго и според системните изисквания на производителя пасва на Вашата CMS.
- Проверете съвместимостта: CMS, разширения, теми и собствен код. Данните са на официалната страница на съответния производител.
- Създайте staging: копие на уебсайта с новата версия на PHP, включително базата данни.
- Тествайте: всички важни процеси, от формуляра за контакт до процеса на поръчка, както и лога на грешките за предупреждения.
- Превключете и рестартирайте: сменете версията, рестартирайте всички PHP процеси, проверете функционирането и лога на грешките.
Планирайте реалистично. Малък уебсайт с актуална CMS често се превключва бързо. Магазин, нараснал с години, с много разширения и собствен код, напротив, може да изисква адаптиране на код и разширения, дори до преминаване към нова основна версия на магазинната система. Изяснете рано кой решава вътрешно, какъв бюджет е предвиден и дали трябва да се включат външни разработчици.
Определете освен това как занапред ще следите краищата на поддръжката. Фиксиран срок в годината, в който сверявате списъка на Вашите уебсайтове с данните на php.net, предотвратява същото тясно място да възникне отново след две години.
До превключването използвайте преходните мерки на php.net, например session.upload_progress.enabled=0 в конфигурацията на сървъра. Те не са пълна защита, но намаляват риска.
Как конкретно помага PHP SOS?
- Установяваме всички версии на PHP, режими на работа и приложения на Вашите сървъри.
- Оценяваме риска за всеки уебсайт и определяме с Вас реда и целевата версия.
- До миграцията въвеждаме преходни мерки и получаваме от доставчика потвърждения за backport корекциите.
- Мигрираме през staging среда и документираме теста и превключването.
Хода описва услугата PHP 8.1 и по-стари: миграция към поддържана версия.
Често задавани въпроси
Кога завършва поддръжката на PHP 8.2?
PHP 8.2 достига края на поддръжката от проекта PHP на 31.12.2026. Корекцията за PHP2Shell клонът още е получил с версия 8.2.35, а за по-късни уязвимости след това не може да се очаква официална актуализация.
Получава ли PHP 8.1 пач срещу PHP2Shell?
От проекта PHP за 8.1 и по-стари вече няма официални актуализации. Има само минимални backport корекции на изходния код за 7.4, 8.0 и 8.1. Дали и как Вашият хостинг доставчик или дистрибуция ги внася, трябва да попитате доставчика.
Сигурна ли е стара версия на PHP с backport корекции от хостинг доставчика?
Backport корекциите могат да затворят конкретни уязвимости, но не заместват поддържан клон. Те зависят от доставчика, често идват по-късно и не покриват всяка уязвимост. Като трайно решение затова не са подходящи.
Откъде да знам дали моята CMS работи с нова версия на PHP?
Проверете системните изисквания на официалната страница на производителя и тествайте в staging среда. За разширенията и темите важи същото, защото те често са истинското тясно място.