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

На 21 октомври 2026 г. екипът на PHP публикува поправки за две критични уязвимости в самия език, известни като PHP2Shell. Те позволяват на външен човек, без потребителско име и парола, да изпълни код на сървъра, на който работи сайтът. Засегнати са практически всички версии на PHP от 5.4 насам, а с тях и сайтовете на WordPress, Joomla, Drupal, Magento, PrestaShop, OpenCart и всяко друго приложение, написано на PHP.

Накратко

• CVE-2026-109618: повреда на паметта при изчерпване на лимита за памет (out-of-memory).
• CVE-2026-109619: използване на освободена памет (use-after-free) чрез вътрешно състояние, останало от предишна заявка.
• Оценка по CVSS 4.0: 9,2 от 10 и за двете.
• Поправени версии: 8.5.12, 8.4.27, 8.3.36 и 8.2.35.
• PHP 8.1 и по-старите версии не получават официални поправки.
• Опити за атаки срещу двете уязвимости вече се наблюдават в интернет.

Кои сайтове и сървъри са засегнати

Според официалното съобщение на PHP рискът засяга всички инсталации, които обслужват уеб заявки: PHP-FPM, Apache с модула mod_php, php-cgi, FrankenPHP и LiteSpeed. Най-висок е рискът при mod_php, където атаката може да бъде задействана с една заявка още преди да се изпълни кодът на сайта. Изследователите от Wiz, сред откривателите на уязвимостите, са демонстрирали изпълнение на код без вход в системата срещу WordPress, Drupal и Joomla. Уязвимостите са в PHP, затова грешка в кода на сайта не е необходима.

Ако сайтът ви работи с PHP 7.4, 8.0 или 8.1, единственото надеждно решение е преминаване към поддържана версия.

Как работят уязвимостите

PHP обработва всяка заявка в работен процес (worker), който след това обслужва следващите заявки. И двете уязвимости използват моменти, в които PHP прекъсва работата си аварийно и не почиства паметта докрай.

CVE-2026-109618: изчерпване на паметта

Когато заявката надхвърли лимита за памет (memory_limit), PHP спира обработката ѝ незабавно. Ако това стане, докато вътрешните данни на заявката са подготвени само наполовина, кодът за почистване ги приема за валидни и работи с непопълнена памет. Нападателят предизвиква изчерпването на паметта с нарочно съставена заявка с прикачени файлове (multipart): например с много заглавки в една част или с много празни полета за файлове. Тази заявка може да остане под лимита post_max_size, но в паметта на PHP заема многократно повече място.

CVE-2026-109619: остатъчно състояние след предишна заявка

След фатална грешка или изчерпване на паметта някои глобални указатели продължават да сочат към памет, която вече е освободена. Следващата заявка към същия работен процес може да прочете тази памет, преди PHP да я нулира. Изследователите са показали, че по този начин съдържанието на паметта изтича в бисквитката PHPSESSID на отговора, а при PHP 8.5 и в комбинация с други техники атаката води до изпълнение на код. Самостоятелно уязвимостта позволява изтичане на данни от други заявки: пароли, ключове за API и сесии.

Оценката и на двете уязвимости отчита висока сложност на атаката: нападателят трябва да контролира разпределението на паметта, а резултатът зависи от версията и настройките. Веднъж написан, такъв експлойт обаче може да се използва масово срещу хиляди сайтове.

Колко сериозна е заплахата

• Номерата на уязвимостите изтекоха публично на 20 октомври. Затова PHP публикува поправките ден по-рано от планираното.
• Cloudflare съобщава, че наблюдава първи атаки, а watchTowr и Patchstack съобщават за опити за използване на двете уязвимости.
• Palo Alto Networks отчита над 22 милиона публично достъпни PHP инсталации, които потенциално са засегнати.
• В интернет се разпространяват програми, представяни като готови експлойти. Екипът на PHP не е установил работещ сред тях към момента на публикуването на поправките. Част от тях може да съдържат зловреден код, затова не ги стартирайте.

Какво да направите сега

1. Установете коя версия на PHP използва сайтът

Командата php -v показва версията на командния ред, която често се различава от версията, обслужваща сайта. Проверете версията на самия сайт:

• в WordPress: Инструменти → Здраве на сайта → Информация → Сървър;
• в контролния панел на хостинга: „Select PHP Version“ или „MultiPHP Manager“ в cPanel, съответният раздел в Plesk или DirectAdmin;
• на собствен сървър: временен файл с <?php phpinfo(); в директорията на сайта, който изтривате веднага след проверката.

При пакетите на Debian, Ubuntu, Red Hat и AlmaLinux номерът на версията не се променя, защото дистрибуцията добавя поправката към същата версия. Там проверете в бюлетина за сигурност на дистрибуцията дали пакетът вече съдържа поправката за CVE-2026-109618 и CVE-2026-109619.

2. Обновете

• Споделен хостинг: попитайте доставчика дали е обновил PHP и превключете сайта на 8.3 или 8.4, ако използвате по-стара версия. Преди смяната проверете дали темата и плъгините поддържат новата версия.
• Собствен сървър или VPS: инсталирайте обновените пакети и рестартирайте всички PHP процеси (systemctl restart php8.3-fpm или systemctl restart apache2). Докато старите работни процеси работят, поправката не действа.
• Контейнери: изградете образите наново с поправената версия и ги разположете отново. Проверете и базовите образи, които не се обновяват автоматично.
• PHP 8.1 и по-стари: планирайте незабавно преминаване към 8.3 или 8.4. Ако това изисква промени в кода, приложете временните мерки по-долу и ограничете достъпа до сайта, докато миграцията приключи.

3. Временни мерки, ако не можете да обновите веднага

Екипът на PHP изрично предупреждава, че тези настройки намаляват риска, но не правят инсталацията безопасна. Задайте ги в php.ini, в конфигурацията на FPM пула (php_admin_value) или на Apache, а не чрез ini_set() или .user.ini, и рестартирайте всички работни процеси:

; CVE-2026-109619: изключва проследяването на качването на файлове
session.upload_progress.enabled = 0

; само за PHP 8.5
fatal_error_backtraces = 0

; CVE-2026-109618: без лимит на паметта за отделната заявка
memory_limit = -1

; 8M, ако сайтът не приема файлове; 32M, ако приема
post_max_size = 8M

Настройката memory_limit = -1 премахва лимита на паметта за отделната заявка. Затова ограничете паметта на цялата услуга на ниво операционна система, например с MemoryMax= в systemd или с лимит на контейнера. Не използвайте ограниченията ulimit -v и ulimit -d (RLIMIT_AS и RLIMIT_DATA), защото точно те предизвикват уязвимото поведение.

Ако сайтът не приема файлове и формуляри от тип multipart/form-data, блокирайте такива заявки на ниво уеб сървър или защитна стена. Cloudflare е добавила правила срещу известните варианти на атаката във всички планове, включително безплатния. Те защитават само трафика, който минава през Cloudflare, и не заменят обновяването.

Как да проверите дали сървърът е бил атакуван

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

• съобщения Allowed memory size of … bytes exhausted, особено с in Unknown on line 0, т.е. преди да започне изпълнението на кода на сайта;
• аварийно спрени процеси: exit signal Segmentation fault (11) в лога на Apache или exited on signal 11 (SIGSEGV) в лога на PHP-FPM;
• серии от необичайни POST заявки от тип multipart/form-data към произволни адреси, последвани от отговори с код 500;
• необичайно дълги или повредени бисквитки PHPSESSID в отговорите.

Липсата на тези записи не доказва, че атака няма. Ако има признаци за атака, проверете и за последиците от нея:

• нови или променени PHP файлове, особено в директориите за качени файлове (find /var/www -name '*.php' -newermt 2026-10-20);
• нови задачи в cron на потребителя, с който работи уеб сървърът;
• нови администраторски профили в сайта;
• изходящи връзки от сървъра към непознати адреси.

Кодът, изпълнен чрез уязвимостта, има правата на уеб сървъра и може да прочете конфигурационните файлове. Ако има съмнение за атака, сменете паролата за базата данни, ключовете за API, данните за SMTP и ключовете на платежните услуги, които се намират в wp-config.php, .env и подобни файлове. Как да почистите сайт с WordPress след пробив, описваме в отделна статия.

Законови задължения

Ако нападателят е имал достъп до лични данни на клиенти или служители, това е нарушение на сигурността на личните данни. В повечето случаи то трябва да бъде съобщено на КЗЛД до 72 часа от узнаването. Фирмите в обхвата на Закона за киберсигурността подават и ранно предупреждение до секторния екип за реагиране при инциденти до 24 часа.