Анализирахме следното твърдение: вярно ли е, че
администраторите на уебсайтове могат да проверят пълното отстраняване на уязвимостите PHP2Shell чрез проверка на потвърдените от доставчиците корекции, на работещата среда на PHP, която реално обслужва техните сайтове, на рестартирането на услугите и на признаци за евентуален пробив?
Официалните указания сочат, че проверката на защитата изисква контрол на активната уеб услуга и рестартиране на процесите, докато само номерът на версията не доказва защита и не показва дали преди това е имало пробив.
Защо обновяването на PHP не доказва, че даден сайт е в безопасност
Инсталирането на спешна корекция за сигурност не гарантира, че даден уебсайт е защитен или че в него не е проникнато.
Историята продължава
Новите корекции за PHP2Shell оставят уебсайтове уязвими
27 октомври 2026 г.Производителите на устройства пуснаха спешни актуализации, но цялостната защита на системите остава незавършена.
Същината
Два критични дефекта в софтуерния двигател PHP, който поддържа голяма част от интернет, позволяват на външни лица да поемат контрол върху сървъри без парола. Макар официалните поправки вече да са достъпни, инсталирането на актуализация не защитава уебсайта автоматично, тъй като машините често запазват стария софтуерен код зареден в оперативната памет. Истинската сигурност изисква потвърждение, че обновеният код реално обслужва трафика, временно изключване на настройка при качването на файлове и цялостен преглед на системните записи за следи от пробиви, започнали дни преди публичните предупреждения.
Акценти
- Уязвимости в двигателя PHP позволяват на външни лица да изпълняват неоторизирани команди без влизане в системата.
- Зловредни скенери започнаха да търсят слабостта на 17 октомври — три дни преди официалните публични предупреждения.
- Доставчикът на защита за WordPress Wordfence блокира над 74 000 опита за атака и сканиране според първоначалната си телеметрия.
- Спешните актуализации, инсталирани на даден сървър, не защитават посетителите, докато фоновите уеб процеси не бъдат изрично рестартирани.
- Отделна уязвимост, оповестена на 23 октомври, изисква администраторите да прегледат настройките за качване на файлове, преди да обявят пълна защита.
Из дневника на редактора
В компютърната сигурност инсталирането на софтуерно обновление е едва половината от възстановяването. Докато администраторът не докаже, че старият софтуер е напълно спрян и че никой не е проникнал в системата преди това, зелената отметка остава просто предположение.
Кой участва
PHP Security Team и PHP Foundation
Екипът от доброволци и фондацията с нестопанска цел, които отговарят за програмния език PHP
цел → Издават работещи корекции за сигурност, поясняват техния обхват и насочват хостинг компаниите към сигурно отстраняване на проблемите
Собственици на сайтове и системни администратори
Притежателите на сайтове и техническите специалисти, управляващи уеб сървъри
цел → Потвърждават, че всяка работеща уеб програма е коригирана, и проверяват дали минали атаки са успели
CloudLinux
Търговски софтуерен доставчик, който поддържа сървърни операционни системи за хостинг компании
цел → Предоставя коригирани пакети за по-стари версии на PHP и документира доказателства за пренесени поправки (backports)
cPanel
Популярен графичен контролен панел за управление на уеб сървъри
цел → Разпространява работещи актуализации и помага на хостинг администраторите да открият и поправят засегнатия софтуер
Docker
Софтуерна компания, която пакетира уеб приложения в изолирани среди, наричани контейнери
цел → Пуска поправени базови конфигурации и гарантира, че клиентите подменят съществуващите активни контейнери
Wordfence
Компания за киберсигурност, защитаваща сайтове на WordPress със защитни стени и скенери
цел → Следи трафика от атаки в интернет, отделя блокираните сканирания от реалните пробиви и обучава собствениците на сайтове
Amazon Threat Intelligence
Звеното за проучване на киберзаплахи на Amazon, което наблюдава трафика в интернет за атаки
цел → Засича ранни опити за атака, споделя индикатори за компрометиране и помага на защитниците да проверят старите системни записи
CERT-EU
Агенцията за киберсигурност, която защитава институциите на Европейския съюз
цел → Издава технически предупреждения за публичните органи и проверява практическите мерки за защита
Накратко
Изтеглянето на корекция за сигурност не доказва, че даден сайт е защитен. Това разминаване има сериозни последици, тъй като PHP е основният софтуерен двигател зад WordPress и милиони бизнеси в интернет, а поредица от уязвимости, известни като PHP2Shell, позволява на външни лица да изпълняват злонамерени команди без въвеждане на парола. Много собственици на сайтове смятат, че автоматичната актуализация решава проблема, но старата уязвима версия може да продължи да работи тихо на заден план дори след изтеглянето на новите файлове.
Вълна от неоткрити пробиви в сървъри най-вероятно ще засегне незабелязано сайтове, чиито собственици смятат, че рутинното обновяване е свършило работата. Този изход е вероятен, защото хиляди автоматизирани опити за пробив започнаха дни преди публичните предупреждения, а обичайните актуализации на сървърите не спират старите работещи процеси и не проверяват дали преди това в системата не са проникнали нападатели.
Потвърждаването на сигурността изисква три отделни стъпки: доказване, че инсталираният софтуерен пакет съдържа необходимата поправка; потвърждение, че активният уебсайт реално е рестартиран с коригирания код; и преглед на системните регистрационни файлове на сървъра за минали опити за атака. На 23 октомври разработчиците добавиха и отделно предупреждение за настройка при качването на файлове, което прави окончателното заключение за пълна безопасност още по-трудно за доказване.
Как се разви
Тих технически дефект прераства в спешна тревога
Проблемът започва с дефект в управлението на паметта, забелязан при рутинна техническа поддръжка на PHP — езика, който генерира уеб страници при поискване. На 11 август 2026 г. двама независими изследователи съобщават, че тази уязвимост позволява на външни нападатели да поемат пълен контрол върху сървър. Трети доклад на 24 август потвърждава сериозността на заплахата. В продължение на два месеца специалистите работят конфиденциално по изграждането на поправка, без да предупреждават обществеността. Тази поверителност се нарушава на 20 октомври, когато идентификационните номера на дефектите изтичат в интернет. Това налага спешното официално публикуване на поправките ден по-рано от предвиденото. Впоследствие Amazon разкрива, че зловредни скенери са опитвали да използват пробива още на 17 октомври.
Поправката пристига, но инсталирането ѝ е едва половината от задачата
Официалните корекции се появиха на 21 октомври, но простото им сваляне не направи сайтовете автоматично защитени. Тъй като уязвимостта засяга ядрото на PHP, а не WordPress или конкретна тема, обновяването на стандартните файлове на самия сайт не промени нищо. Освен това операционните системи под Linux често прилагат поправки към по-стари софтуерни версии, без да променят основния номер на версията. Това означава, че даден сайт може да показва стар номер, но да е защитен, или обратно — да изписва нова версия, докато на заден план продължава да се изпълнява незащитена програма. Както показа Как тайният план за поправка на PHP2Shell се разпадна преди премиерата, прибързаните внедрявания крият рискове от критични пропуски: дистрибуции като Ubuntu изрично предупредиха, че автоматичните инструменти за обновяване невинаги рестартират фоновите уеб услуги, оставяйки стария и уязвим код зареден в оперативната памет.
Различните сървърни конфигурации изискват напълно различни проверки
Следващото препятствие се корени във факта, че повечето собственици на сайтове нямат пряк достъп до сървърите, които обслужват тяхното съдържание. Потребител на споделен хостинг, който дели една машина с хиляди други клиенти, не може да изпълнява административни команди; той трябва да изиска писмено потвърждение от своя доставчик, указващо конкретно инсталираната поправка и извършеното рестартиране на услугите. Професионалните системни администратори трябваше да преглеждат системните дневници, за да се уверят, че скритите фонови работни процеси са спрени. Компаниите, използващи контейнери на Docker, бяха изправени пред друг капан: изтеглянето на обновен базов образ не променя контейнера, който вече работи активно. Междувременно Wordfence засече над 74 000 опита за атака в интернет. Макар тези опити да бяха блокирани, наличието на инсталирана поправка в момента не отговаря на въпроса дали даден нападател не е проникнал в системата преди нейното въвеждане.
Ново предупреждение променя стандарта за защита
На 23 октомври изискванията за обявяване на пълна защита се промениха отново. Хостинг доставчикът CloudLinux предупреди, че стандартните автоматизирани инструменти често не разпознават специфични вътрешни корекции за сигурност, което означава, че на отчет от софтуерен скенер без отчетени грешки не може да се вярва сляпо. В същия ден основният проект PHP съобщи за отделна уязвимост, свързана с функцията за проследяване на напредъка при качване на файлове. Макар тя да не създава критичен риск за всеки сървър, поддръжката посъветва администраторите да изключат тази функция, докато излезе стандартна софтуерна поправка. Агенцията за киберсигурност на Европейския съюз също препоръча тази мярка. В резултат на това обявяването на даден сървър за напълно защитен вече налага три независими проверки: доказване, че първите два дефекта са поправени; потвърждение, че настройката за качване на файлове е изключена; и проверка, че системните записи не съдържат следи от чуждо проникване.
Докъде стигна историята
Официални корекции за първоначалните уязвимости PHP2Shell вече съществуват, но доказването на тяхната ефективност изисква конкретни действия според архитектурата на сайта. Клиентите на споделен хостинг се нуждаят от изрично писмено потвърждение от своите доставчици, което да посочва точно инсталираните пакети и рестартирането на услугите. Системните администратори трябва да инспектират активните системни процеси и да потвърдят, че по-старите версии са напълно прекратени. Операторите на среди с контейнери трябва да изтрият и създадат наново активните си системи от проверени софтуерни образи. При всички видове инфраструктура проверката единствено на номера на версията или разчитането на стандартна зелена отметка остават недостатъчни.
Работещата поправка не гарантира, че сървърът е избегнал предходен пробив. Администраторите трябва да съхранят регистрационните файлове на уеб сървърите и операционните системи поне от 17 октомври насам, когато бяха засечени най-ранните опити за проникване. При поява на съмнителни файлови промени или неочаквани процеси сървърът трябва да бъде изолиран, паролите — сменени, а системите — възстановени от надеждни резервни копия. В следващия етап администраторите трябва да следят за редовната актуализация на PHP за отстраняване на новия проблем с качването на файлове, да проверят пренесените поправки от доставчиците на хостинг системи и да удостоверят, че сървърите са прекратили окончателно работата на уязвимите процеси.
PHP2Shell: кризата със сигурността на PHP
Спешната поправка за сигурност на PHP предизвика недоказани опасения за пробив
21 октомври 2026 г.Публикации в интернет твърдяха, че новата актуализация за програмния език, задвижващ милиони уебсайтове, е неефективна, но техническите проверки не откриха компрометиран защитен код.
Спешни корекции в PHP след изтичане на експлойти и ранни атаки срещу уеб сървъри
21 октомври 2026 г.Милиони сървъри са изложени на риск от отдалечен контрол, след като критични уязвимости изтекоха публично преди официалните поправки.