Накратко: От уязвимостта в сигурността на PHP PHP2Shell са засегнати клоновете 8.2 до 8.5 до изданията от 21 октомври 2026 г., а според специализираната преса почти всички версии чак до PHP 5.4. Поправена е в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. За PHP 8.1 и по-стари вече няма официални актуализации, а само минимални backport-ове на изходния код за 7.4, 8.0 и 8.1.
Кои версии е засегнала уязвимостта в PHP?
PHP2Shell обхваща двете уязвимости CVE-2026-109618 и CVE-2026-109619, оценени съответно с CVSS v4.0 9,2. И двете позволяват изпълнение на злонамерен код отдалечено без удостоверяване. На 21 октомври 2026 г. в 14:00 UTC (16 ч. германско време) проектът PHP публикува поправки за всички поддържани клонове.
| PHP клон | Последно състояние преди поправката | Поправено от | Поддръжка |
|---|---|---|---|
| 8.5 | 8.5.11 | 8.5.12 | официално поддържан |
| 8.4 | 8.4.26 | 8.4.27 | официално поддържан |
| 8.3 | 8.3.35 | 8.3.36 | официално поддържан |
| 8.2 | 8.2.34 | 8.2.35 | приключва на 31.12.2026 г. |
| 8.1, 8.0, 7.4 | всички състояния | няма официално издание | само минимални backport-ове на изходния код |
| 7.3 до 5.4 | според специализираната преса почти всички са засегнати | няма актуализация | от години без поддръжка |
Данните за 8.2 до 8.5 идват от съобщенията на php.net. Твърдението за версиите до PHP 5.4 идва от специализираната преса; пълен официален списък за старите версии няма.
За нетехническите хора в няколко изречения: ако на Вашия сървър стои версия от колоната „Поправено от“ или по-висока и след това всички PHP процеси са рестартирани, PHP2Shell е затворена. Ако там стои по-стар номер, или е замесен backport, който Вашият доставчик трябва да потвърди, или уязвимостта е отворена. При съмнение попитайте Вашия ИТ екип или хостинг доставчик точно за тези три точки: версия, backport, рестартиране.
Засегнати режими на работа
Номерът на версията е само половината от отговора. Засегнати са всички обичайни начини PHP да работи на уеб сървър: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Екипът на PHP оценява риска при mod_php като най-висок, защото там е показан експлойт още преди да започне да се изпълнява какъвто и да е код на приложението. Подробности има на страницата Защо mod_php носи най-висок риск.
Защита не идва от приложението: било то WordPress, Shopware, TYPO3, Laravel или собствена разработка, актуализацията на приложението не затваря уязвимостта в PHP.
Backport-ове: когато номерът на версията лъже
Много Linux дистрибуции и хостинг доставчици доставят PHP в собствени пакети. Вместо да преминат към нова версия на upstream, те вграждат поправката като backport в съществуващата си версия. Това има практична последица: показваният номер остава стар. Пример от актуалната ситуация е Plesk, който може да продължава да показва 8.2.34, въпреки че грешката е отстранена.
За Вас това означава: таблицата по-горе важи за официалните издания на php.net. При пакети от Вашата дистрибуция или от хостинг доставчика решават състоянието на пакета и потвърждението на доставчика. Как да проверите и двете, показва страницата Как да проверите правилно PHP версията и състоянието на пача. За бързия тест в командния ред:
php -v
apt policy php8.3-fpm # Debian/Ubuntu, името на пакета се различава според версията и източника
dnf info php-fpm # семейство RHEL
Поправен номер на версията на диска все още не означава, че той работи. Едва след рестартирането на всички PHP процеси сървърът работи с коригирания код.
Какво важи за PHP 8.1 и по-стари?
За PHP 8.1, 8.0 и 7.4 има само минимални backport-ове на изходния код, т.е. поправки в изходния код, които някой трябва сам да поеме и да компилира. Официални издания не излизат. Някои дистрибуции с дългосрочна поддръжка вграждат такива поправки в пакетите си; дали това важи за Вашата система, може да се изясни само по changelog-а на пакета или при доставчика.
В дългосрочен план няма заобикаляне на поддържаната версия. Коя PHP версия понася Вашият CMS или магазин, проверете според системните изисквания на производителя, например на wordpress.org, shopware.com или typo3.org. Повече има на страницата PHP 8.1 и по-стари: какво важи сега.
А CVE-2026-115560?
На 23 октомври php.net публикува бележка за трета уязвимост. Тя действа само при необичайна конфигурация на сесиите. Поправена версия към състоянието от 25 октомври още няма; до следващото редовно издание с поправки на грешки средството е session.upload_progress.enabled=0. Списък с версиите се очаква едва с пълния advisory.
Как помага PHP SOS конкретно?
- Опис: Събираме всички PHP версии на Вашите сървъри, също и второстепенните инсталации за отделни уебсайтове, които лесно се пропускат.
- Сверяване: За всяка инсталация изясняваме дали има официално издание, backport на дистрибуцията или няма поправка.
- Актуализация с доказателство: Чрез услугата за пач на PHP внасяме поправката и рестартираме всички процеси.
- План за миграция: За версии без официални актуализации планираме преминаването чрез миграция от PHP 8.1 и по-стари и осигуряваме сървъра дотогава.
Често задавани въпроси
Още ли е сигурен PHP 8.3.35?
Не, освен ако Вашият доставчик не е внесъл backport. 8.3.35 е последното състояние преди поправката; PHP2Shell е поправена в клона 8.3 от 8.3.36. При пакети от дистрибуции номерът може да остане същият, въпреки че грешката е отстранена. Тогава значение имат changelog-ът на пакета или потвърждението на доставчика.
Засегнат ли е PHP 7.4 от PHP2Shell?
Според специализираната преса са засегнати почти всички версии чак до PHP 5.4. За 7.4, 8.0 и 8.1 има само минимални backport-ове на изходния код и никакви официални издания. Преминаването към поддържана версия е надеждният път.
Защо Plesk показва 8.2.34, въпреки че е пачнато?
Дистрибуциите и хостинг доставчиците понякога внасят поправките като backport в съществуващите си пакети. Номерът на версията тогава остава същият, а грешката все пак е отстранена. Проверете състоянието на пакета или поискайте от доставчика потвърждение за пача.
Коя PHP версия да избера сега?
Поддържана версия, която Вашето приложение допуска според системните изисквания на производителя. PHP 8.2 достига края на поддръжката на 31.12.2026 г.; който така или иначе сменя сега, трябва да го планира.