PHP2Shell (CVE-2026-109618 и CVE-2026-109619): какво трябва да направят сега компаниите, които използват PHP

Техник с лаптоп, който работи по сървърен шкаф

На 21 октомври 2026 г. проектът PHP пусна PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35, за да поправи две уязвимости, които „могат да позволят отдалечено изпълнение на код без удостоверяване“. Казано просто: всеки, който може да изпрати HTTP заявка до уебсайта ви, може да успее да изпълни собствения си код на сървъра ви. Не му трябва парола, а при някои конфигурации атаката сработва, преди приложението ви да е изпълнило дори един ред. Двете уязвимости получиха общото име PHP2Shell, а PHP оценява и двете с 9,2 (CVSS 4.0, по скала до 10).

Това ръководство е за хората, които трябва да предприемат действия: собствениците на уебсайтове и онлайн магазини на PHP, ИТ мениджърите и всеки, за когото доставчик поддържа PHP. Написано е на 22 октомври 2026 г., ден след пускането на версиите, въз основа на бюлетините за сигурност на самия проект PHP, указанията на националните агенции за киберсигурност и данните, публикувани от доставчиците. Там, където източниците се разминават, го казваме.

Накратко

Обновете самия PHP, след това го рестартирайте. Обновяването на WordPress, Drupal, Laravel или на плъгин не решава проблема. Уязвимостта е в PHP, под вашето приложение.
В обхвата попада всяка инсталация на PHP, която обслужва уеб заявки, според PHP: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Според оценката на PHP най-висок е рискът при Apache с mod_php.
Почти половината уебсайтове на PHP работят на клон, за който проектът PHP вече не пуска версии (по наш прочит на данните на W3Techs, вижте по-долу). За тях няма официален пакет, който да инсталирате.
Настройките и защитните стени печелят време, но не дават сигурност. PHP изброява временни мерки и казва, че те „не правят инсталацията безопасна“.
Ако не можете да приложите корекциите днес, агенциите в САЩ, Обединеното кралство и ЕС дават един и същ съвет: изключете системата от интернет, докато това не стане възможно.

Какво се случи, по ред

19 август 2026 г. Изследователи от Wiz откриват първата от уязвимостите и на 24 август докладват за тях на екипа по сигурността на PHP, според собствената им публикация. В бюлетините на PHP са признати заслугите и на изследователи от няколко други компании.
20 октомври. Номерата CVE изтичат в интернет два дни преди планираното оповестяване. PHP изтегля пускането на версиите с един ден по-рано, за 21 октомври в 14:00 UTC, и призовава всички да се подготвят.
21 октомври, 03:02 UTC. Cloudflare включва правила на защитната стена за всички клиенти, които ползват нейния WAF (защитна стена за уеб приложения), включително тези на безплатния план. По-късно компанията съобщава, че е „наблюдавала трафик от атаки, насочени към нашите клиенти“, и е видяла как нападателите „променят полезния товар (payload) на атаката, за да се опитат да заобиколят защитите ни“.
21 октомври, около 14:00 UTC. PHP публикува корекциите и бюлетина си за сигурност. Същия ден CISA в САЩ, NCSC на Обединеното кралство, CERT-EU и съвместно изявление на Европейската комисия, ENISA, CERT-EU, Европол и националните екипи CSIRT на държавите от ЕС призовават организациите незабавно да приложат корекциите.

Колко сериозно е това?

Три неща отличават случая от обичайните месечни корекции.

На нападателя не му трябва нищо освен една заявка. Без влизане в системата и без някой да трябва да кликне на връзка. Бюлетинът на PHP описва демонстриран експлойт срещу Apache с mod_php, „при който заявка без удостоверяване може да задейства атаката, преди да се изпълни какъвто и да е код на приложението“. Wiz демонстрира атаки срещу актуалните версии на WordPress, Drupal и Joomla и отбелязва, че „дори просто приложение Hello World, работещо на засегната версия на PHP, може да е уязвимо“. Кодът, изпълнен по този начин, има правата на акаунта, с който работи уеб сървърът, а на повечето сайтове той може да чете конфигурацията на приложението: паролата за базата данни, API ключовете, данните за достъп до пощата и до плащанията. За втората уязвимост, CVE-2026-109619, PHP потвърждава и разкриване на памет: данни от паметта на сървъра изтичат навън дори без пълно изпълнение на код.

Инсталираната база е огромна. Според W3Techs PHP задвижва 69,3% от уебсайтовете, чийто сървърен език е известен (данни към 22 октомври 2026 г.). Unit 42 на Palo Alto Networks отчита над 22,6 милиона публично достъпни инстанции, които са потенциално уязвими, по данни от собственото си сканиране на интернет, и съобщава, че поне едно европейско правителство е изключило уебсайта си като предпазна мярка.

Работата по експлойтите напредва бързо. CERT-EU съобщава, че първите доказателства за концепция (proof of concept) „са започнали да се разпространяват“. Компанията за сигурност watchTowr казва, че нейните honeypot системи регистрират експлоатиране от 21 октомври насам. Cloudflare съобщава за трафик от атаки. А Wiz казва, че изследователите ѝ са използвали ИИ модели през цялото време, така че един изследовател е свършил за седмица това, което „би отнело месеци на екип от световна класа“. Нападателите, които приспособяват експлойт към вашата версия на PHP, разполагат със същите инструменти.

За да бъдем честни, ето и другата страна: когато CISA публикува предупреждението си на 21 октомври, агенцията не беше наблюдавала експлоатиране и нито една от двете уязвимости все още не беше в нейния каталог Known Exploited Vulnerabilities (известни експлоатирани уязвимости). Red Hat оценява проблема като „важен“ (Important), а не като критичен, защото стандартният сървър с Red Hat Enterprise Linux използва PHP-FPM, при който експлоатирането е по-трудно. По-трудно не означава невъзможно: PHP потвърждава, че един от пътищата за атака по втората уязвимост работи и при PHP-FPM. Нищо от това не променя какво трябва да направите. Променя само колко рано ще бъдете предупредени.

Коя версия използвате? Числата

W3Techs публикува и кои версии на PHP използват уебсайтовете, като брои сайтовете, които показват версията си. Ако съберем двете му таблици от 22 октомври 2026 г.:

Клон на PHP	Дял от уебсайтовете на PHP	Корекция от проекта PHP
8.3, 8.4, 8.5	около 34%	Да: 8.3.36, 8.4.27, 8.5.12
8.2	около 18%	Да: 8.2.35. Но самият 8.2 достига края на жизнения си цикъл на 31 декември 2026 г.
8.0, 8.1	около 14%	Няма нова версия. 8.0 и 8.1: само backport в изходния код
7.x	26,9%	Няма нова версия. 7.4: само backport в изходния код; 7.3 и по-стари: нищо
5.x и по-стари	7,8%	Нищо

Така около 48% от уебсайтовете на PHP работят на клон, за който проектът PHP не публикува версия с корекцията, а други 18% получават корекцията си сега и губят поддръжка след десет седмици.

Две уговорки. W3Techs вижда само сайтовете, които показват версията си. А една Linux дистрибуция може сама да е поправила стар клон: Ubuntu го е направила, както ще видите по-долу. Самият номер на версията не ви казва дали сте защитени. Това ви казва версията на пакета от вашия доставчик.

Стъпка 1: открийте всички инсталации на PHP

Не можете да коригирате това, което не сте описали, а PHP се крие добре. NCSC на Обединеното кралство иска от организациите да открият всяка система с PHP, като започнат с достъпните от интернет, и добавя: „не ограничавайте търсенето до остарелите версии на PHP“. Съвместното изявление на ЕС предупреждава, че някои продукти „може да са засегнати от тези уязвимости, дори ако не изглежда да използват PHP пряко“.

Къде да търсите:

Уебсайтове и магазини: WordPress и WooCommerce, Drupal, Joomla, Magento и Adobe Commerce, Shopware, PrestaShop, TYPO3 и всичко, изградено на Laravel или Symfony.
Забравените системи: микросайтове за кампании, стара езикова версия, предпродукционни и тестови сървъри, достъпни от интернет, уеб пощата или хелпдеск системата, която някой е инсталирал преди години.
Контейнери: всеки образ, изграден от базов образ php, носи собствен PHP. Обновяването на хоста не го засяга.
Контролни панели за хостинг: cPanel, Plesk и подобните им панели доставят собствени компилации на PHP успоредно с тази на системата. Всяка версия, разрешена в панела, трябва да се обнови отделно.
Продукти с PHP в себе си: готови устройства (appliances), инструменти за мониторинг, CRM системи, хелпдеск системи и административни интерфейси на доставчици. Нидерландският NCSC поддържа публичен списък на такива продукти с техния статус, доставчик по доставчик.
Доставчици: вашата хостинг компания, вашата агенция, всяка услуга, за която знаете, че под нея работи PHP. Попитайте ги писмено кои версии на PHP работят на системите ви и кога ще бъдат приложени корекциите.

За всяка инсталация запишете версията на PHP, как работи PHP (mod_php, PHP-FPM, LiteSpeed, FrankenPHP, контейнер), дали е достъпна от интернет и кой може да приложи корекцията.

Стъпка 2: приложете корекциите в правилния ред

Започнете с всичко, което е достъпно от интернет, а сред него с конфигурациите с Apache mod_php.

На поддържан клон (от 8.2 до 8.5). Обновете до 8.5.12, 8.4.27, 8.3.36 или 8.2.35 или до пакета на вашата дистрибуция, който съдържа корекцията. PHP казва, че Linux дистрибуциите са получили корекциите предварително. Потвърдено досега:

Ubuntu: пакети с корекцията за всяка версия от 14.04 до 26.10. За 22.04 и по-новите те идват с обичайните обновления; за 20.04 и по-старите е нужен абонамент за Ubuntu Pro, който е безплатен за до пет машини (известието на Canonical).
Debian: php8.4 8.4.27 за Debian 13 (DSA-6574-1) и php8.2 8.2.35 за Debian 12 (DLA-4848-1).
Red Hat Enterprise Linux: бюлетинът за сигурност на Red Hat RHSB-2026-013 изброява пакетите за всяка версия.
Хранилището Remi, широко използвано за по-нови версии на PHP на системи от семейството на Red Hat: на 21 октомври CERT-EU отбеляза, че в деня на пускането то няма пакети, и посъветва да се премине към пакетите на дистрибуцията или към компилиране от изходния код. Проверете дали е наваксало, преди да разчитате на него.

На PHP 7.4, 8.0 или 8.1. Проектът PHP не публикува версия за тях. Екипът му по сигурността е направил минимални backport корекции в изходния код за трите клона, които помагат, ако компилирате PHP сами. Иначе корекцията трябва да дойде от вашия доставчик (Ubuntu Pro например покрива PHP 7.4 на Ubuntu 20.04) или от преминаване към по-нова версия на PHP. Съветът на CISA за всеки на 8.1 или по-стара версия, който не може да обнови, е категоричен: изключете системата от мрежата, докато не получи корекцията или не премине към по-нова версия.

На PHP 7.3 или по-стар. От проекта PHP не идва нищо. Освен ако някой доставчик все още издава корекции за вашата компилация, изборът е между преминаване към по-нова версия и изключване на системата от мрежата.

Рестартирайте след обновяването. Инсталирането на пакет не заменя PHP, който вече работи. Известието на Ubuntu го казва направо: приложението „вероятно ще трябва да бъде рестартирано“. Рестартирайте PHP-FPM, Apache, LiteSpeed или контейнера на всеки сървър. След това проверете версията, която уеб сървърът действително използва, а не само php -v в командния ред, защото там може да е друга компилация.

Контейнери: изградете образите си наново от базов образ с корекцията и ги внедрете отново. Хост с корекцията, на който работи стар образ, остава уязвим.

Управляван хостинг: попитайте доставчика си за датата и версията, след което проверете сами.

Стъпка 3: ако не можете да приложите корекциите днес

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

За CVE-2026-109618: задайте memory_limit=-1 така, че приложението да не може да го промени (например с php_admin_value в пула на PHP-FPM или в конфигурацията на Apache); задайте ниска стойност на post_max_size (PHP предлага 8M без качване на файлове, 32M с качване); ограничете размера на заявките, броя на полетата и частите на multipart заявките на уеб сървъра или проксито; и използвайте ограничение на паметта на ниво контейнер или cgroup, никога RLIMIT_AS или RLIMIT_DATA.
За CVE-2026-109619: задайте session.upload_progress.enabled=0 в php.ini или в конфигурацията на сървъра (не с ini_set() или с файл .user.ini) и рестартирайте всеки worker процес. На PHP 8.5 задайте и fatal_error_backtraces=0.

Две предупреждения. Настройката за сесиите, която се разпространи широко на 20 октомври, затваря само пътища за атака по втората уязвимост, както отбеляза член на екипа по сигурността на PHP; срещу първата тя не прави нищо. А memory_limit=-1 премахва собствения таван на паметта на PHP, така че една-единствена тежка заявка вече може да изчерпи сървъра. Комбинирайте я с ограничението на ниво контейнер или cgroup.

Защитната стена за уеб приложения помага, макар и малко. Правилата на Cloudflare са включени по подразбиране за всички планове с нейния WAF, включително безплатния, а Palo Alto Networks и други доставчици са публикували свои защити. Cloudflare все пак призовава клиентите си да обновят PHP „дори със защитите на WAF“, а компанията е видяла как нападателите променят полезния товар, за да минат покрай правилата ѝ. Освен това WAF защитава само трафика, който минава през него. Ако сървърът ви отговаря и на собствения си IP адрес, нападателят може да заобиколи защитната стена.

Ако нищо от това не може да стане бързо, CISA, CERT-EU, NCSC и съвместното изявление на ЕС сочат в една и съща посока: изключете системата от публичния интернет, докато не бъде поправена. Един ден със страница за техническа профилактика струва по-малко от изграден наново сървър.

Стъпка 4: проверете дали вече не сте били пробити

Прозорецът се отвори на 20 октомври, когато започна изтичането, а за трафик от атаки се съобщи на следващата сутрин. Ако дадена система е била достъпна и без корекция през този период, корекцията затваря вратата, но не ви казва дали някой не е влязъл преди това. NCSC иска от всеки, който не е могъл да приложи корекцията незабавно, да провери за признаци на компрометиране и за задни вратички (backdoors).

Какво да търсите според публикуваните указания и обичайната практика при инциденти:

Процеси на PHP, които правят неща, които PHP никога не прави, например стартират обвивка (shell) или изтеглят инструменти (CISA).
Необичайни multipart заявки, последвани от грешки за ограничението на паметта или от повтарящи се отговори HTTP 500, worker процеси на PHP, които се рестартират без ясна причина, и необичайно големи или деформирани бисквитки PHPSESSID в отговорите (Wiz).
Нови или променени PHP файлове в папките за качване, в кеш папките или в основната директория на сайта (web root), нови администраторски акаунти в CMS и планирани задачи, които никой не е създавал.

Чистите журнали не са доказателство. Бюлетинът на PHP за втората уязвимост предупреждава точно за това, а Wiz отбелязва, че журналите на приложението може да съдържат малко контекст.

Ако откриете нещо, третирайте го като инцидент, а не като задача по обновяване. Изолирайте сървъра, запазете доказателствата, привлечете доставчик на услуги по реагиране на инциденти и сменете всеки секрет, който уеб сървърът е можел да прочете: пароли за бази данни, API ключове, данни за достъп до плащания и поща, ключове за подписване. Тъй като втората уязвимост може да разкрие съдържание от паметта, обмислете смяна на най-чувствителните от тези секрети на всеки сървър, който е бил изложен и без корекция в продължение на дни, дори без признаци на проникване.

Стъпка 5: какво може да се наложи да докладвате

Сама по себе си уязвимостта не е инцидент, подлежащ на докладване. Експлоатираната уязвимост може да бъде.

NIS2: ако организацията ви е в обхвата и компрометирането е значителен инцидент, ранното предупреждение до националния ви екип CSIRT трябва да бъде подадено до 24 часа. Вижте нашето ръководство за NIS2.
ОРЗД: ако е имало достъп до лични данни, надзорният орган трябва да бъде уведомен до 72 часа, след като сте узнали за нарушението, освен ако не е вероятно то да породи риск за хората. Вижте нашето ръководство за ОРЗД.
Актът за киберустойчивост: ако продавате софтуер или устройство с PHP в него, вие сте негов производител по смисъла на CRA. От 11 септември 2026 г. производителите са длъжни да докладват активно експлоатирани уязвимости в продуктите си през единната платформа за докладване по CRA, както напомня съвместното изявление на ЕС. Вижте нашето ръководство за CRA.
Вашите клиенти: ако хоствате или поддържате PHP за клиенти, те ще попитат. Кратка писмена бележка (какво използвате, кога е приложена корекцията, какво сте проверили) отговаря на повечето им въпроси и е същата бележка, която одитор или застраховател срещу киберрискове ще поиска да види.

След извънредната ситуация: какво да промените

На повечето добре поддържани сървъри корекциите за PHP2Shell ще бъдат приложени в рамките на дни. Това, което случаят разкри за вашата среда, ще важи и след това.

Знайте колко време ви отнема една корекция. От бюлетина до рестартирането на всеки сървър: часове, дни или седмици? Ако честният отговор е „ще трябва да попитаме агенцията“, оправете това преди следващия път. Щом изследователите казват, че ИИ е съкратил работата им по експлойта от месеци на седмица, приемете, че и нападателите могат да се движат с това темпо.
Запазете описа, който току-що съставихте. Той беше най-трудната част от реакцията и остарява в момента, в който никой не отговаря за него.
Откажете се от версиите на PHP с изтекла поддръжка. Сайт на 7.4 или 8.1 този път се нуждаеше от доставчик или от backport в изходния код; следващия път може да няма нито едното, нито другото. PHP 8.2 достига края на жизнения си цикъл на 31 декември 2026 г., така че сайт, който напуска 8.1, трябва да премине направо на 8.3 или по-нова версия. Смяната на PHP често означава и обновяване на приложението: нашата статия за края на поддръжката на Drupal, Umbraco и Kentico показва какво включва това за една CMS.
Предпочитайте PHP-FPM пред mod_php, където е възможно. Този път това беше конфигурацията с по-нисък риск.
Оставете проследяването на напредъка при качване изключено, ако не го използвате. Бюлетинът на PHP предлага session.upload_progress.enabled да остане изключена и след прилагането на корекцията, когато приложението не се нуждае от нея.
Впишете сроковете за корекции в договорите си. Попитайте хостинг доставчика и агенцията си колко бързо прилагат критичните корекции за PHP и получете отговора писмено.

Контролен списък за тази седмица

Опишете всяка инсталация на PHP, включително контейнерите, контролните панели, продуктите на доставчици и предпродукционните сървъри.
Приложете корекциите първо на системите, достъпни от интернет, като започнете с Apache mod_php.
Рестартирайте всеки процес на PHP и проверете версията, която отчита уеб сървърът.
Изградете наново и внедрете отново образите на контейнерите.
Където не можете да приложите корекцията днес, задайте временните настройки на PHP, пренасочете трафика през WAF или изключете системата от мрежата.
Поискайте писмено от доставчиците и хостинг компаниите версията им на PHP и датата на корекцията.
Прегледайте журналите и промените във файловете на всичко, което е било изложено и без корекция от 20 октомври насам.
Решете дали е приложимо задължение за докладване (NIS2, ОРЗД, CRA).
Планирайте преминаването от PHP 8.1 и по-старите версии, както и от 8.2 преди 31 декември.

С какво можем да помогнем

На повечето компании не им липсва желание да приложат корекциите. Липсва им ясна картина на това, което използват, или хора, които да свършат работата тази седмица. Тази част поемаме ние:

Опис и корекции, за дни. Откриваме инсталациите ви на PHP по сървъри, контейнери, хостинг панели и доставчици, прилагаме корекциите, рестартираме и проверяваме и ви оставяме писмен запис какво е направено и кога. Този запис е и вашият отговор към клиентите и одиторите.
Преминаване от стар PHP. Приложения, заседнали на PHP 7.x, 8.0 или 8.1, защото кодът не работи на нищо по-ново: пренасяме ги на поддържана версия в рамките на нашата услуга за поддръжка на наследени системи.
Засилване на защитата и рутина за корекции, така че следващият бюлетин да бъде планирана задача, а не извънредна ситуация.

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

Пишете ни на office@c9group.dev какво използвате и ще ви отговорим с какво бихме започнали.

Източници

Проверени на 22 октомври 2026 г. Ситуацията продължава да се развива: особено статусът на експлоатирането и пакетите на доставчиците може да са се променили оттогава.

Проектът PHP

Агенции

Изследователи, доставчици и данни