Уязвимост в PHP (PHP2Shell): какво се случи и защо поддръжката на сайт е важна

Уязвимост в PHP с името PHP2Shell позволи на атакуващи да изпълняват код на сървъри без парола – поправката излезе на 21 октомври 2026 г. в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Обновяването на WordPress не помага, защото проблемът е в самия PHP: защитен е само сайт, чийто сървър вече работи с поправената версия – а това е задача на поддръжката на сайт.

Миналата седмица беше от онези, в които се вижда разликата между сайт с поддръжка и сайт без поддръжка. Уязвимост в PHP – езика, на който работят WordPress, WooCommerce и по данни на W3Techs около 69% от сайтовете с известен сървърен език – стана публична ден преди планираното обявяване, а първите опити за атака бяха засечени часове преди да излезе поправката. По-долу описвам какво точно се случи, какво направихме на нашите сървъри и какво трябва да проверите вие още днес.

Какво е PHP2Shell – уязвимост в PHP, не в WordPress

PHP е езикът, на който сървърът „изпълнява“ сайта: всяко отваряне на страница, всяка поръчка и всеки формуляр минават през него. PHP2Shell е общото име на две критични уязвимости в самия интерпретатор на PHP – CVE-2026-109618 и CVE-2026-109619, и двете с оценка 9,2 от 10 по CVSS v4.0. Според официалното съобщение на PHP те позволяват отдалечено изпълнение на код (RCE) – тоест атакуващ без парола може да накара сървъра да изпълни негови команди.

Накратко, техническата причина е в начина, по който PHP прекъсва заявка при изчерпана памет или фатална грешка: част от данните остават „наполовина“ изчистени и могат да бъдат използвани от следваща заявка. Засегнати са всички инсталации на PHP, които обслужват уеб заявки – PHP-FPM, Apache mod_php, LiteSpeed и други, като най-рискова е mod_php. Това потвърждава и бюлетинът на CERT-EU.

Важното за собственика на сайт: уязвимост в PHP не се поправя с обновяване на WordPress, темата или плъгините. Поправя се само с нова версия на PHP на сървъра.

Хронология: какво се случи миналата седмица

Подробна хронология на атаките публикува Patchstack, а техническия анализ – Rapid7.

Какво направихме ние – поддръжка на сайт в реално време

Поддържам сайтове от 2012 г. насам и това беше една от най-сериозните уязвимости в PHP, които съм виждал. На сървъра, на който работят infobgnet.com и сайтовете на клиентите ни с поддръжка, поправените версии бяха инсталирани още на 21 октомври – PHP 8.3.36 и 8.2.35, плюс поправени версии и за по-старите клонове. След това проверих, че всички PHP процеси са рестартирани и работят с новата версия, а не със старата, останала в паметта.

Това е и най-честата грешка, която виждам: новата версия е инсталирана, но старите процеси продължават да работят. На пръв поглед всичко е наред, а сайтът остава изложен на уязвимост в PHP. Затова поддръжката на сайт не е „натисни бутона за обновяване“, а проверка след всяко обновяване.

Уязвимост в PHP: 6 стъпки, които да направите сега

1. Проверете версията на PHP. В WordPress отидете в Инструменти → Състояние на сайта → Информация → Сървър. Трябва да видите 8.5.12, 8.4.27, 8.3.36, 8.2.35 или по-нова версия от същия клон.
2. Попитайте хостинга писмено. Ако версията е по-стара, поискайте обновяване. На споделен хостинг това е задача на хостинг компанията – вие не можете да обновите PHP сами.
3. Уверете се, че PHP е рестартиран. Поправката на уязвимост в PHP действа чак след рестарт на PHP процесите. Добрият хостинг или поддръжката на сайт правят това автоматично.
4. Планирайте преминаване от PHP 8.1 и по-стари. Те вече не получават официални поправки, а PHP 8.2 спира да се поддържа на 31 декември 2026 г. Оптималното е PHP 8.3 или 8.4 – след тест на сайта на копие.
5. Сменете паролите и ключовете, ако сървърът е бил уязвим дълго. Изследователите са показали, че при атака може да се прочете паметта на PHP – с пароли, токени и API ключове. Сменете паролите на администраторите, на базата данни и ключовете за плащания.
6. Проверете сайта за следи от пробив през уязвимост в PHP. Непознати администратори, нови файлове в папките на темата и плъгините, странни пренасочвания. Ако не сте сигурни, поискайте безплатен SEO одит – в него проверяваме и сигурността.

Официалните инструкции на WordPress за обновяване на PHP са събрани на страницата Update PHP.

Коя версия на PHP е безопасна

Защо уязвимост в PHP е аргумент за поддръжка на сайт

Сайт без поддръжка разчита на това, че някой друг ще забележи проблема. При PHP2Shell между изтичането на информацията и първите атаки минаха часове, а не седмици. Ето какво прави редовната поддръжка на сайт в такава ситуация:

При INFOBGNET поддръжката на сайт е €70 на месец и включва обновявания на WordPress, темата и плъгините, резервни копия, наблюдение на сигурността и скоростта, грижа за хостинга и домейна и до 1 час корекции. За онлайн магазините подробностите са в статията за поддръжка на онлайн магазин.

Какво следва след тази уязвимост в PHP

Историята не приключва с обновяването от 21 октомври. Ето какво да имате предвид през следващите седмици:

• Третата уязвимост в PHP (CVE-2026-115560) ще бъде поправена в следващото редовно обновяване. Дотогава PHP препоръчва настройката session.upload_progress.enabled да е изключена. Тя засяга само сайтове с нестандартни настройки на сесиите, но е добре хостингът ви да я е изключил.
• Сървърите с Windows получиха на 26 октомври допълнителни версии – PHP 8.5.12-1, 8.4.27-1, 8.3.36-1 и 8.2.35-1 – с поправка в библиотеката Brotli (съобщение на PHP). Ако сайтът ви е на Windows сървър, обновете и тях.
• PHP 8.2 спира да се поддържа на 31 декември 2026 г. Следващата уязвимост в PHP след тази дата няма да бъде поправена за 8.2, затова преминаването към 8.3 или 8.4 е най-добре да стане сега, а не след инцидент.
• Нови опити за атака. След всяка голяма уязвимост в PHP ботовете продължават да сканират сайтове седмици наред. Сайтовете с непоправени версии ще бъдат атакувани дълго след като новините утихнат.

Именно тук поддръжката на сайт се отплаща: някой следи тези дати вместо вас и обновява навреме – преди следващата уязвимост в PHP, а не след нея.

Чести проблеми след обновяване на PHP

• Сайтът „чупи“ след преминаване към нова версия на PHP. Причина: стар плъгин или тема, писани за PHP 7. Решение: тест на копие на сайта (staging), обновяване или смяна на проблемния плъгин и чак тогава смяна на версията на живия сайт.
• Версията е обновена, но проверката пак показва уязвимост в PHP. Причина: старите PHP процеси не са рестартирани. Решение: рестарт на PHP-FPM/LiteSpeed или поискайте това от хостинга.
• Хостингът не отговаря или няма дата за обновяване. Причина: евтин или неподдържан хостинг. Решение: преместване на сайта при доставчик, който обновява в деня, в който излезе поправка за уязвимост в PHP – това е част от поддръжката на сайт.
• „Обнових WordPress, значи съм защитен.“ Причина: объркване между WordPress и PHP. Решение: проверка на версията на PHP в „Състояние на сайта“ – WordPress обновяване не беше нужно и не беше пускано за PHP2Shell.

Ако искате да прочетете повече за основните навици за сигурност, вижте как да останем в безопасност онлайн.

Често задавани въпроси

Засегнат ли е моят WordPress сайт от PHP2Shell?

Засегнат е, ако сървърът работи с версия на PHP преди 8.5.12, 8.4.27, 8.3.36 или 8.2.35. Проверете в „Инструменти → Състояние на сайта → Информация → Сървър“. Самата версия на WordPress няма значение.

Трябва ли да обновя WordPress заради уязвимостта в PHP?

Не. Уязвимостта е в PHP, затова поправката е нова версия на PHP на сървъра. Обновяването на WordPress остава важно по принцип, но не решава този проблем.

Какво е CVE-2026-115560 от 23 октомври?

Трета уязвимост в PHP, свързана с прогреса на качване на файлове в сесиите. Тя засяга само приложения с нестандартни настройки на сесиите и ще бъде поправена в следващото редовно обновяване. Дотогава PHP препоръчва настройката session.upload_progress.enabled да е изключена.

Използвам PHP 7.4 – какво да правя?

PHP 7.4 отдавна не се поддържа официално. Има само минимални поправки в изходния код, които някои доставчици вграждат. Най-сигурното решение е преминаване към PHP 8.3 или 8.4 след тест на копие на сайта.

Колко струва поддръжката на сайт при INFOBGNET?

€70 на месец. Включва обновявания, резервни копия, наблюдение на сигурността и скоростта, хостинг и домейн и до 1 час корекции месечно.

Нужда от помощ?

Ако не сте сигурни коя версия на PHP използва вашият сайт или дали хостингът ви е реагирал навреме, пишете ни – ще проверим. А ако искате повече никога да не мислите за това, вижте нашата поддръжка на сайт.