php2shell: две критични уязвимости в PHP налагат спешно обновяване

Публикувано на 22 октомври 2026 г. · Explorer Soft

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

Какъв е проблемът

Корекциите за CVE-2026-109618 и CVE-2026-109619 бяха публикувани на 21 октомври 2026 г. Уязвимостите са в самия PHP, затова обновяването само на WordPress, неговите разширения или зависимостите, управлявани с Composer, не ги отстранява. [1]

При CVE-2026-109618 недостигът на памет може да прекъсне обработката, докато част от вътрешните данни все още не са напълно подготвени. При приключването на заявката PHP може да използва тези данни неправилно. За Apache с mod_php е демонстрирана атака, която се задейства още преди изпълнението на приложението. PHP-FPM прекратява обслужващия процес при такъв ранен отказ, но според анализа на екипа на PHP уязвимостта остава достижима и по други начини, вече в хода на изпълнение на приложението. [2]

При CVE-2026-109619 процесът може да запази препратка към памет, която е била използвана от предишна заявка и вече е освободена. Ако следваща заявка използва тази препратка, нападател може да постигне изпълнение на код. Условията за атака зависят от конфигурацията и от операциите, които приложението допуска. Скриването на съобщенията за грешки не отстранява уязвимостта. [3]

В предупреждението си от 21 октомври Канадският център за киберсигурност посочва публични сведения за демонстрационен код за атака (PoC). Към момента на издаване на предупреждението центърът не е установил активно използване на уязвимостите. Това обаче не е основание актуализацията да се отлага. [9]

Кои версии съдържат корекциите

Екипът на PHP публикува следните коригирани издания за поддържаните клонове: [1]

Клон на PHP	Първа версия с корекциите
8.2.x	8.2.35
8.3.x	8.3.36
8.4.x	8.4.27
8.5.x	8.5.12

При пакетите на Linux дистрибуциите проверката изисква повече внимание. Доставчикът може да е пренесъл поправките към по-стара версия на PHP — практика, известна като backport. Затова сравнявайте пълната версия на пакета с официалния бюлетин за вашата операционна система. Само основният номер на PHP не е достатъчен, за да се определи дали инсталацията е уязвима. [8]

Например Ubuntu посочва пакетите 8.3.6-0ubuntu0.24.04.13 за 24.04 LTS и 8.1.2-1ubuntu2.28 за 22.04 LTS като коригирани и за двете уязвимости. Това не означава, че всяка инсталация на PHP 8.3.6 или 8.1.2 е защитена — поправките са включени в конкретните пакети на Ubuntu. [4] [5]

За PHP 8.1 и по-старите клонове проектът PHP вече не публикува редовни актуализации за сигурност. Ако все още ги използвате, проверете дали доставчикът ви предлага удължена поддръжка и корекции за двете уязвимости. При липса на такава поддръжка е необходим преход към поддържан клон.

Първо установете коя инсталация на PHP обслужва сайта

На един сървър може да има няколко инсталации на PHP. Всяка от тях трябва да се провери отделно: PHP-FPM, Apache с mod_php, CGI/LSAPI, FrankenPHP, контейнерите и продуктите с вграден PHP. Започнете от публично достъпните сайтове. Екипът на PHP определя риска при mod_php като най-висок. [1]

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

Командата php -v показва версията за командния ред. Тя може да се различава от тази, с която работи сайтът. Проверете настройките на виртуалния хост и връзката му с PHP. При необходимост направете кратка проверка през уеб заявка, която връща само PHP_VERSION и PHP_SAPI. Ограничете достъпа до нея и я премахнете веднага след проверката. Не оставяйте публично достъпна страница с phpinfo().

Обновяване според използваната среда

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

Ubuntu и Debian с PHP-FPM или mod_php

Проверете от кое хранилище идват пакетите на PHP. За Ubuntu корекциите са описани в USN-8948-1. При Debian използвайте неговите бюлетини и регистър за сигурност — номерата на пакетите на Ubuntu не са приложими. Обновете основните пакети на PHP заедно с използвания модул на Apache или PHP-FPM и необходимите разширения. [6]

# Пример за Ubuntu 24.04 с PHP 8.3 FPM от хранилищата на Ubuntu
sudo apt update
apt-cache policy php8.3-common php8.3-fpm php8.3-cli
sudo apt install --only-upgrade php8.3-common php8.3-fpm php8.3-cli
sudo systemctl restart php8.3-fpm
systemctl is-active php8.3-fpm

Прегледайте предложените промени, преди да потвърдите инсталирането им. При Apache с mod_php обновете и libapache2-mod-php8.3, изпълнете apache2ctl configtest и рестартирайте Apache. Ако работят няколко версии на PHP, повторете проверката за всяка от тях. Рестартирането само на Nginx не подменя процесите на PHP-FPM.

RHEL, AlmaLinux и Rocky Linux

Проверете версията на операционната система, избрания поток от пакети (stream) и доставчика на хранилището. Потърсете неговите бюлетини за всяка от двете уязвимости. Наличието на корекция за RHEL не означава автоматично, че тя е достъпна и за останалите дистрибуции.

Red Hat оценява CVE-2026-109618 като Important и обяснява защо атаката е по-трудно осъществима при стандартна конфигурация с PHP-FPM. Това не отменя необходимостта от актуализация. [7]

# Проверка на пакетите и бюлетините, без промени по системата
rpm -qa 'php*'
dnf updateinfo info --cves CVE-2026-109618,CVE-2026-109619

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

Docker и Kubernetes

Изберете базов образ с потвърдена корекция, изградете отново образа на приложението и го тествайте. Docker препоръчва --pull, за да се изтегли актуален базов образ. Опцията --no-cache сама по себе си не го обновява. [11]

Запишете идентификатора на новия образ (digest), внедрете го и проверете всички работещи копия на приложението. Само изпълнението на docker pull не подменя вече стартираните контейнери. Рестартирането на pod със стария образ също не решава проблема. Проверете и периодичните задачи, обработката на опашки и резервните конфигурации за внедряване, включително тези за автоматично мащабиране. Иначе при следващо стартиране може отново да се използва уязвимият образ.

Windows с IIS/FastCGI

Проверете към кой php-cgi.exe сочи настройката на всеки сайт в IIS. Инсталирайте подходящото коригирано издание на PHP, като съобразите архитектурата, варианта TS/NTS и съвместимостта на разширенията. Следвайте указанията на PHP за IIS. [12]

Поставете новото издание в отделна директория и пренасочете съответния обработчик към него. След това рестартирайте съответната услуга или пул от приложения, така че старите FastCGI процеси да бъдат прекратени, и проверете версията през самия сайт. Подмяната само на директорията за PHP в PATH не гарантира, че IIS използва новото издание.

Хостинг панели и споделен хостинг

При CyberPanel/OpenLiteSpeed, Plesk и cPanel проверете настройката на всеки домейн. PHP на операционната система може да е различен от версиите, управлявани от панела, или от използвания LSAPI пакет. Обновявайте чрез поддържания от доставчика механизъм и проверявайте дали корекцията обхваща и двете уязвимости.

Към 22 октомври Plesk потвърждава налични корекции за PHP 8.2–8.5 под Linux и Windows. За PHP компонента на самия панел, sw-engine, са посочени Plesk Obsidian 18.0.81 Update 4 и 18.0.80 Update 11. При PHP 7.4, 8.0 и 8.1 под Linux проверете и датата на компилация: коригираните пакети от 21 октомври запазват същия номер на версията. [10]

При споделен хостинг поискайте от доставчика пълната версия на използвания пакет, потвърждение за двете корекции и информация дали обслужващите процеси са рестартирани. Изборът на „PHP 8.3“ от менюто на панела не е достатъчен. При FrankenPHP трябва да се провери и версията на PHP, вградена в новия изпълним файл или контейнерен образ.

Илюстрация на обновяване на сървър, контейнери и работна станция — Илюстрацията е създадена с изкуствен интелект и не представлява техническа схема.

Какво да направите, ако не можете да обновите веднага

Ограничете публичния достъп до уязвимото приложение, например през защитна стена или обратен прокси сървър. Правилата на защитната стена за уеб приложения (WAF) могат да намалят риска, но не гарантират защита срещу всички възможни варианти на атаката. Определете кой ще извърши актуализацията и в какъв срок.

Екипът на PHP описва и настройки, които блокират отделни начини за използване на уязвимостите. За някои атаки чрез недостиг на памет това е административно наложено memory_limit=-1. За определени случаи на използване на освободена памет се препоръчва изключване на session.upload_progress.enabled, а при PHP 8.5 — и на fatal_error_backtraces. Тези мерки не заменят актуализацията. Премахването на ограничението за паметта може да доведе до прекъсване на услугата. То изисква предварително зададени ограничения на ниво контейнер или cgroup и рестарт на обслужващите процеси. Не прилагайте тази настройка, без да сте оценили последствията за конкретния сървър. [2] [3]

Проверката след актуализацията

Уверете се, че сайтът действително използва обновената версия след рестарта. Запазете пълната версия на пакета или хеша на образа и съответния бюлетин за сигурност. Проверете входа в профил, качването на файлове, сесиите, API заявките и фоновите задачи. Следете за нови грешки, промени в потреблението на памет и забавяне на отговорите.

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

Как да намалите риска при следващ подобен случай

Поддържайте списък на използваните версии на PHP и следете съобщенията за сигурност на проекта и доставчиците си. Обновявайте редовно контейнерните образи и изпробвайте предварително как се извършват спешна актуализация и възстановяване от резервно копие. Разделяйте сайтовете по потребители и FPM пулове, ограничавайте правата за запис и ненужните изходящи връзки и съхранявайте копие на журналите извън уеб сървъра.

Канадският център за киберсигурност препоръчва проверка за необичайни процеси, файлове, профили и изходящи връзки, свързани с PHP или уеб сървъра. [9] Съпоставяйте тези данни със записите в журналите на PHP и уеб сървъра. Съобщенията за недостиг на памет и отговорите с код HTTP 500 сами по себе си не доказват атака. При съмнение за компрометиране запазете данните за разследване, изолирайте засегнатата система и започнете проверка на инцидента. Самото инсталиране на корекцията не премахва оставени от нападателя файлове, профили или други средства за достъп.

Нуждаете се от помощ с обновяването на PHP?

Опишете накратко сайта и използваната среда. Ще се свържем с вас, за да обсъдим как можем да помогнем.

.article-contact .article-contact-form{display:none}Можете да ни пишете директно на info@720explorer.space. За да използвате формата, включете JavaScript.