Анализирахме следното твърдение: вярно ли е, че
уязвимостта PHP2Shell застрашава уебсайтове с компрометиран PHP независимо от използваната платформа за съдържание, докато отговорността за инсталирането на поправката зависи от това кой контролира хостинг средата?
Официалните предупреждения и независимите технически анализи потвърждават, че PHP2Shell засяга самия език PHP, а не отделните системи за управление на съдържание, което разделя отговорността за обновяването между споделените хостинг доставчици, операторите на платформи и собствениците на частни сървъри.
Отстраняването на уязвимостта PHP2Shell зависи от това кой управлява сървъра
Дефект в основата на интернет заплашва милиони сайтове, но защитата изисква намеса на ниво сървър, а не на самото приложение.
Историята продължава
Корпоративните защитни стени бързат да затворят критичен пробив в уеб софтуер
31 октомври 2026 г.Водещите доставчици на киберсигурност пускат извънредни корекции, докато корпоративните мрежи остават уязвими за атаки.
Защо обновените уебсайтове остават уязвими за атаки
30 октомври 2026 г.Инсталирането на последните софтуерни корекции вече не е достатъчно, за да гарантира защитата на дадена онлайн услуга.
Пропуски в популярен уеб език засягат корпоративните защитни стени
27 октомври 2026 г.Дефекти в масово използван програмен инструмент принуждават охраната на фирмените мрежи да изчаква специализирани софтуерни поправки от производителите.QNAP пусна корекции за шест платформи за съхранение на данни след пробив в сигурността
24 октомври 2026 г.Производителят защити шест операционни системи срещу отдалечено превземане, но четири специализирани серии остават уязвими.
Нова уязвимост в PHP усложнява защитата на уебсайтовете
24 октомври 2026 г.Самото инсталиране на софтуерни обновления може да се окаже недостатъчно, ако определени системни настройки останат активни.
Отстраняването на уязвимостите PHP2Shell оставя мрежовото оборудване за сигурност без защита
23 октомври 2026 г.Доставчиците на уеб хостинг внедряват поправки за критични пробиви в интернет, докато ключов мрежов хардуер остава уязвим в очакване на обновления.
Същината
Две критични уязвимости, известни под името PHP2Shell, застрашават уебсайтовете, разчитащи на езика за програмиране PHP, който стои зад близо 70% от разпознаваемите сървъри в глобалната мрежа. Тъй като проблемът се крие в самия език, а не в софтуерни платформи като WordPress или Drupal, обновяването на обикновени добавки не премахва опасността. Официалните системни поправки излязоха на 21 октомври, но реалната защита зависи от това кой управлява конкретната машина: хостинг компаниите трябва да обновят споделените платформи, а собствениците на самостоятелни сървъри — да инсталират пакетите и да рестартират услугите си сами. Въпреки че опитите за сканиране започнаха преди публикуването на официалните защити, реални успешни пробиви в работещи сайтове все още не са регистрирани.
Акценти
- PHP управлява 69,3% от всички уебсайтове с разпознаваемо сървърно програмиране.
- Екипът на проекта PHP публикува извънредни защитени версии 8.2.35, 8.3.36, 8.4.27 и 8.5.12 на 21 октомври.
- Опити за експлоатация на слабостта бяха засечени в системи примамки още на 17 октомври, преди официалното оповестяване.
- CloudLinux осигури коригирани пакети за всички засегнати версии на операционната система до 19:50 UTC на 22 октомври.
Из дневника на редактора
Защитата на един уебсайт изисква контрол не само върху видимата платформа, но и върху софтуерния двигател под нея. Когато сривът настъпи на ниво език за програмиране, сигурността не зависи от графичните теми или добавките, а единствено от този, който управлява физическия или виртуален сървър, където се изпълнява кодът.
Кой участва
PHP Security Team and PHP Foundation
Екипът по сигурността и фондацията с нестопанска цел, поддържаща езика за програмиране PHP
цел → Отстраняват грешки в изходния код, координират сигналите за сигурност и предоставят защитени версии на софтуерните разпространители
Hosting providers and PHP distributors, including cPanel and CloudLinux
Доставчици на хостинг и софтуерни дистрибутори, включително cPanel и CloudLinux
цел → Създават и разпространяват обновени системни пакети и актуализират машините на клиентите на споделен хостинг
Website owners and infrastructure administrators
Собственици на уебсайтове и системни администратори
цел → Проверяват коя версия на PHP обслужва реалния трафик, инсталират системни обновления и следят дали хостинг доставчиците са приложили нужните корекции
Calif, OpenAI and Wiz Research
Независими екипи за киберсигурност, открили и тествали уязвимостите
цел → Локализират слабостите в кода, уведомяват конфиденциално разработчиците и изпитват предложените поправки преди официалното им публикуване
Automattic
Търговското дружество, управляващо издателски платформи, сред които WordPress.com, WordPress VIP и Pressable
цел → Внедрява защитни поправки в управляваните от компанията сървъри без необходимост от действия от страна на клиентите
Google Cloud, Amazon Web Services and Cloudflare
Глобални доставчици на облачна и мрежова инфраструктура, управляващи хостинг платформи, мрежови филтри и наблюдение на заплахи
цел → Защитават управляваните клиентски услуги, блокират зловредния трафик и насочват потребителите как да обновят самостоятелните си системи
Unknown attackers
Неидентифицирани извършители, изпращащи зловредни цифрови заявки към уязвими системи
цел → Сканират публичните сървъри с цел кражба на поверителни данни или придобиване на контрол над чужд хардуер
Ordinary website visitors
Потребители, които разглеждат уебсайтове, пазаруват онлайн и подават лични данни през електронни форми
цел → Опазват профилите и информацията си, без да разполагат с пряк начин за инсталиране на поправки по сървърите
Накратко
Обновяването на системи като WordPress няма да защити даден уебсайт, ако програмната среда, върху която той работи, остане уязвима. Десетки милиони страници разчитат на езика PHP за обработка на потребителски входове, пазарски колички и формуляри. Два критични дефекта при управлението на паметта в него позволяват на външни нападатели да извличат данни или да поемат пълен контрол над съответната машина.
Отстраняването на опасността изисква системните администратори и доставчиците да обновят активната инсталация на PHP или да внедрят коригирани пакети от своите доставчици на софтуер. Този процес вероятно ще протича неравномерно през следващите седмици, тъй като отговорностите са разпределени между различни доставчици, а много собственици на уебсайтове нямат пряк достъп до машините, обслужващи тяхното съдържание.
Самата уязвимост се намира изцяло в програмната среда PHP, която изпълнява кода на платформи като WordPress, Drupal или индивидуални уеб разработки. Екипът на проекта публикува официални поправки на 21 октомври за версии от 8.2 до 8.5. Кой трябва да ги приложи обаче зависи от хостинг архитектурата: компаниите за споделен хостинг и изцяло управляваните платформи актуализират системите служебно, докато наемателите на виртуални частни сървъри или самостоятелни контейнери трябва да инсталират пакетите сами. Обикновените посетители нямат технически начин да защитят даден сайт отвън, макар че към момента няма потвърдени успешни пробиви в реални системи.
Как се разви
Рутинен одит превърна стар технически сигнал в извънредна ситуация
Рутинна проверка на изходен код прерасна в мащабна кампания в технологичния сектор, след като отдавна известен проблем с паметта се оказа значително по-опасен от първоначалните оценки. Програмист забелязва потенциален дефект при управлението на оперативната памет още през 2024 г. по време на външен одит от френската компания за киберсигурност Quarkslab, но работата по отстраняването му спира, тъй като промяната в кода застрашава съвместимостта със съществуващи уеб приложения. Ситуацията се променя рязко на 30 юли 2026 г., когато специализираната компания Calif започва цялостна проверка по програмата Patch the Planet на OpenAI — инициатива с изкуствен интелект (AI) за повишаване на сигурността на ключов софтуер с отворен код. До 11 август проверката дава първото потвърдено практическо доказателство, че нападател може да изпълнява отдалечени команди през въпросната слабост. Публичните предупреждения се появяват на 20 октомври в дискусионни форуми като Hacker News, което принуждава екипа на PHP да потвърди проблема и да подготви спешни обновления.
Уязвимостта се пренася в основите на уеб платформите
Фокусът на техническите проверки бързо се премести от конкретните уеб страници към програмния механизъм, който ги изпълнява. На 11 август Calif демонстрира, че два критични дефекта под милиони уебсайтове позволяват на външен нападател да подава директни инструкции към сървъра при недостиг на оперативна памет. Скоро след това екипът на Wiz показа, че пробивът може да се извърши през платформи като Drupal и WordPress, а OpenAI идентифицира допълнителни начини за задействане на грешката. Проблемът не произтича от некачествен код в самите платформи за управление на съдържание. Вместо това самият PHP освобождава паметта неправилно при неуспешни заявки, оставяйки вътрешни данни, които следваща заявка може да използва неправомерно. Това натрупване означава, че сървър, обработващ паралелни задачи, може случайно да разкрие данни от предишни сесии, включително потребителски пароли и данни за трансакции.
Опитите за атака изпреварват указанията за защита
Графикът за координирано оповестяване беше нарушен, след като първите опити за атака се появиха в мрежата преди публикуването на официалните защити. На 17 октомври Amazon Web Services засича опити за сканиране на своята мрежа от примамки MadPot, изградена за изследване на зловреден трафик. Три дни по-късно, на 20 октомври, непотвърдени твърдения и реалните служебни идентификатори на уязвимостите се разпространяват в Hacker News, придружени от кратко изтекъл демонстрационен видеоклип от Calif. Изтичането на информацията принуждава PHP Foundation да промени първоначалния си план, като изтегля официалното публикуване с един ден напред и предупреждава операторите на критична инфраструктура да подготвят системите си.
Поправка за PHP, а не за WordPress
Официалните софтуерни корекции бяха пуснати на 21 октомври за няколко поддържани клона на PHP, като разработчиците изрично подчертаха, че обновяването на самите уеб приложения не решава проблема. Проектът PHP публикува поправени версии с номера 8.2.35, 8.3.36, 8.4.27 и 8.5.12, за да изолира два конкретни дефекта: неизчистена памет при препълване на капацитета за обработка и остатъчни данни от завършена заявка, които преминават в следващата. Конфигурациите, които вграждат PHP директно в уеб сървъра Apache, са изложени на най-пряка опасност още преди стартирането на кода на сайта, макар че системите с отделни работни процеси също остават уязвими. От екипа на WordPress излязоха с официално становище, че платформата не може да бъде защитена чрез собствен ъпдейт, което означава, че дори напълно обновена инсталация остава уязвима, ако версията на PHP на сървъра не бъде променена.
Крайното отстраняване зависи от собствеността върху хардуера
Доставянето на защитните поправки до работещите сайтове срещна трудности заради фрагментираната структура на собственост върху сървърите и използваните софтуерни инструменти. При стандартния споделен уеб хостинг доставчиците контролират базовия софтуер чрез пакети от компании като cPanel и CloudLinux, а притежателите на сайтове могат само да сменят наличните опции в клиентския панел. Администраторите на самостоятелни виртуални сървъри трябваше да инсталират пакетите ръчно и да рестартират уеб услугите, докато екипите, използващи софтуерни контейнери, се наложи да компилират и разгърнат приложенията си наново. През целия ден на 22 октомври CloudLinux отстраняваше неясноти около дистрибуцията на пакетите, като уточни, че по-стари номера на версии също могат да бъдат защитени, ако кръпките за сигурност са били пренесени обратно в тях. До късната вечер коригираните пакети достигнаха до стабилните хранилища за всички засегнати версии на операционната система.
Докъде стигна историята
Техническите дефекти в PHP са доказани, официалните поправки са налични, а дистрибуторските мрежи предоставят коригираните пакети на потребителите. Защитените официални версии включват PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12, като паралелно са създадени съвместими кръпки и за по-стари системни издания. Администраторите трябва да се уверят, че работещите уеб услуги са рестартирани с новите файлове, вместо да разчитат единствено на приставки или на визуално изписания номер на версията.
Точният брой на уязвимите уебсайтове остава неизвестен. Според данни на W3Techs към 22 октомври PHP управлява 69,3% от всички сайтове с разпознаваемо сървърно програмиране, но това число показва общата популярност на езика, а не потвърдени инциденти. Amazon и Cloudflare вече регистрираха нерегламентирани опити за сканиране, но от Amazon отбелязват, че реалният ефект върху работещи платформи остава неясен, а PHP Foundation не съобщава за потвърдени пробиви към 22 октомври.
PHP2Shell: кризата със сигурността на PHP
Спешната поправка за сигурност на PHP предизвика недоказани опасения за пробив
21 октомври 2026 г.Публикации в интернет твърдяха, че новата актуализация за програмния език, задвижващ милиони уебсайтове, е неефективна, но техническите проверки не откриха компрометиран защитен код.
Спешни корекции в PHP след изтичане на експлойти и ранни атаки срещу уеб сървъри
21 октомври 2026 г.Милиони сървъри са изложени на риск от отдалечен контрол, след като критични уязвимости изтекоха публично преди официалните поправки.