Накратко: PHP2Shell е името на две критични уязвимости в сигурността на самия PHP, CVE-2026-109618 и CVE-2026-109619. Чрез тях атакуващите могат на уязвими уеб сървъри да изпълняват злонамерен код без удостоверяване. Помага само актуализацията до поправена PHP версия с последващо рестартиране на всички PHP процеси.
Какво е PHP2Shell?
PHP е езикът за програмиране, върху който работи голяма част от всички уебсайтове: фирмени сайтове с WordPress или TYPO3, онлайн магазини със Shopware или WooCommerce, вътрешни портали и собствени разработки. На 21 октомври 2026 г. проектът PHP публикува актуализации за сигурност за две уязвимости, станали известни под името PHP2Shell.
И двете уязвимости са оценени с CVSS v4.0 9,2, т.е. като критични. Последицата и в двата случая е една и съща: отдалечено изпълнение на злонамерен код, без атакуващият да трябва да се удостоверява. Специалистите говорят за „unauthenticated Remote Code Execution“ (отдалечено изпълнение на код без удостоверяване). Който може да изпълнява код на сървъра, може в най-лошия случай да чете данни, да вгражда задни вратички или да използва сървъра за други атаки.
Важно за разбирането: уязвимостта не е в определен CMS или добавка, а в PHP. Затова актуализация на WordPress, Shopware или TYPO3 не я затваря.
Защо уязвимостта е толкова сериозна?
Три неща правят PHP2Shell особено деликатна от гледна точка на органите по сигурността:
- Обхват: Засегнати са обичайните режими на работа на PHP, а именно PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Palo Alto Networks (Unit 42) преброи над 22,6 милиона изложени на риск, потенциално уязвими инстанции.
- Не е нужно влизане: Атакуващият не се нуждае нито от парола, нито от потребителски акаунт.
- Ранен момент: При Apache с mod_php според екипа на PHP е показан експлойт още преди да започне да се изпълнява какъвто и да е код на приложението. Защитните функции в рамките на уебсайта тогава не действат.
BSI обяви ниво на предупреждение 3 (оранжево). То препоръчва незабавна актуализация и, когато това не е възможно веднага, засегнатите уеб сървъри да се изключат временно от мрежата.
Кои сървъри са засегнати от PHP2Shell?
Уязвимостите са поправени в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. По-старите версии на тези клонове са засегнати. За PHP 8.1 и по-стари вече няма официални актуализации; според специализираната преса са засегнати почти всички версии чак до PHP 5.4. Пълния преглед ще намерите на страницата Кои PHP версии са засегнати?.
Една особеност: Linux дистрибуциите и хостинг доставчиците понякога внасят поправките като backport. Тогава например Plesk продължава да показва 8.2.34, въпреки че грешката е отстранена. Меродавни са състоянието на пакета и потвърждението на доставчика. Как да го проверите, обясняваме на страницата Как да проверите правилно PHP версията и състоянието на пача.
Какво е доказано, какво е неизвестно?
Доказани са двата номера CVE, поправените версии и временните мерки, публикувани от php.net. На 23 октомври се добави съобщение за друга уязвимост, CVE-2026-115560, която действа само при необичайна конфигурация.
Вероятно е, че атакуващите продължават активно да търсят непачнати сървъри. Според съобщения в медиите първият опит за атака е наблюдаван още на 17 октомври, т.е. преди публикуването на пачовете. Cloudflare съобщи за опити за атака и внедри защитни правила, но посочва, че правила само по данните от заявките не са достатъчни.
Неизвестно е колко сървъра вече са били атакувани успешно. Потвърдени успешни атаки в голям мащаб според BSI отначало не са били известни. Няма публикувани, потвърдени Indicators of Compromise. Затова дали един сървър е бил засегнат, може да се прецени само чрез анализ на поведението. Времевия ход обобщава хронологията от 17 до 25 октомври.
Какво трябва да направят фирмите сега
- Изяснете кой е отговорен: собствен сървър, управляван сървър или хостинг доставчик.
- Актуализирайте PHP до поправена версия или потвърден backport.
- Рестартирайте всички PHP процеси. Новите файлове сами не стигат, докато стари процеси работят в паметта.
- Запазете логовете, и то от 20 октомври нататък. Специализираната преса съветва тези данни да се съхраняват.
- Проверете за следи. Пачът не премахва вече внедрен злонамерен софтуер и не доказва, че преди това нищо не е станало. Бележки по темата дава страницата Вече компрометиран ли съм?.
Една актуализация затваря вратата, но не почиства. Ако сървърът Ви е бил достъпен между 17 октомври и пача, проверката за следи е задължение, а не по желание.
Как помага PHP SOS конкретно?
Със спешната помощ при PHP2Shell поемаме стъпките, които много фирми не могат да покрият вътрешно в кратък срок:
- Опис: Установяваме PHP версията, режима на работа и състоянието на пакетите на всеки засегнат сървър.
- Пач или преходен период: Внасяме актуализацията или, където това още не е възможно, прилагаме временните мерки на php.net и изясняваме въпроса дали сървърът трябва да бъде временно изключен от мрежата.
- Рестартиране и доказателство: Рестартираме всички PHP процеси и документираме състоянието преди и след това.
- Проверка на следите: Запазваме логовете от 20 октомври нататък и проверяваме за аномалии, докато инцидентът бъде приключен и документиран.
Често задавани въпроси
PHP2Shell уязвимост на WordPress ли е?
Не. Уязвимостите са в PHP, т.е. в езика за програмиране, върху който работят WordPress, Shopware, TYPO3 и много други системи. Затова актуализация на CMS не ги затваря. Решаващо е състоянието на PHP на сървъра.
Трябва ли аз като клиент на хостинг доставчик сам да направя нещо?
При споделен хостинг по правило хостинг доставчикът внася актуализацията на PHP. Все пак трябва да поискате писмено потвърждение, че използваната от Вас PHP версия е пачната и рестартирана. Дали преди пача е станало нещо, актуализацията не показва.
Откъде идва името PHP2Shell?
Името описва последицата: чрез PHP атакуващият може в най-лошия случай да получи команден ред, т.е. shell, на сървъра. Официалните означения са номерата CVE-2026-109618 и CVE-2026-109619.
Означава ли изключването на уебсайта ми офлайн, че вече е бил атакуван?
Не непременно. Някои доставчици са изключили уебсайтове от мрежата превантивно, както препоръчва BSI, когато актуализацията не е възможна веднага. Това е защитна мярка, а не доказателство за атака.