CVE-2026-109618: RCE чрез Out-of-Memory състояние

Накратко: CVE-2026-109618 е една от двете уязвимости зад PHP2Shell. Състояние Out-of-Memory може да прекъсне PHP, докато данните от заявката са инициализирани само частично; при почистването невалидни данни могат тогава да бъдат счетени за валидни. Това позволява изпълнение на код без удостоверяване. Грешката е поправена в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35.

Какво е CVE-2026-109618?

CVE-2026-109618 (GitHub идентификация GHSA-w8hw-w9fx-j79w) е уязвимост от вида грешка в паметта в ядрото на PHP. Тя е оценена с CVSS v4.0 9,2. Заедно с CVE-2026-109619 образува това, което медиите наричат PHP2Shell.

Въздействието е т.нар. unauthenticated Remote Code Execution (отдалечено изпълнение на код без удостоверяване): атакуващият може отдалечено и без потребителски акаунт да изпълнява код на уеб сървъра. Така уязвимостта спада към най-опасния клас слабости, които един уеб сървър може да има.

Как възниква уязвимостта по принцип

Когато PHP обработва уеб заявка, той създава вътрешно структури от данни за нея, например за подадените данни от формуляри. Ако PHP при това стигне границата на паметта си, прекъсва със състояние Out-of-Memory. Според php.net това може да се случи, докато данните от заявката са инициализирани само частично.

В края на всяка заявка PHP почиства и освобождава паметта. Точно там е грешката: почистването може да третира невалидни, само наполовина създадени данни като валидни. От това поведение при определени условия може да се изведе изпълнение на код.

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

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

Засегнати версии и режими на работа

Засегнати са режимите на работа PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Екипът на PHP оценява риска при mod_php като най-висок. Дистрибуциите и хостинг доставчиците понякога внасят backport-ове, така че се показва по-стар номер на версията, въпреки че грешката е отстранена. Меродавни са състоянието на пакета и потвърждението на доставчика.

За мащаба: Palo Alto Networks (Unit 42) преброи над 22,6 милиона изложени на риск, потенциално уязвими инстанции. BSI обяви ниво на предупреждение 3 (оранжево) и очакваше бърза мащабна експлоатация.

Отстраняване на CVE-2026-109618: актуализация и рестартиране

Единственото пълно средство е актуализацията. Първо проверете версията и състоянието на пакета. Имената на пакетите се различават според дистрибуцията; примерите изхождат от PHP 8.3:

php -v
apt policy php8.3-fpm          # Debian/Ubuntu
dnf info php-fpm               # RHEL, AlmaLinux, Rocky, Fedora
rpm -q --changelog php-fpm | grep -i "CVE-2026-109618"

Ако changelog-ът на пакета назовава номера CVE, backport-ът е внесен. Ако липсва, това не означава автоматично, че пакетът е уязвим; тогава помага сверяването с таблицата на версиите или въпрос към доставчика.

След актуализацията всички PHP процеси трябва да се рестартират, например с systemctl restart php8.3-fpm или при mod_php с рестартиране на Apache. Как да се уверите, че не работи нито един стар worker, е описано на страницата Рестартиране на PHP-FPM и на всички worker процеси.

Временни мерки, когато актуализацията още не е възможна

php.net публикува временни мерки за PHP2Shell. Те важат за двете уязвимости заедно и изрично не са пълна защита. Това, че няколко от тях се отнасят до ограничения на паметта, пасва на причината Out-of-Memory при CVE-2026-109618; официално съотнасяне на отделни мерки към отделни CVE обаче няма.

; Пример за FPM пул, напр. /etc/php/8.3/fpm/pool.d/www.conf (пътят се различава според дистрибуцията)
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M          ; 32M, ако са нужни качвания
php_admin_value[upload_max_filesize] = 6M    ; immer unter post_max_size
php_admin_flag[session.upload_progress.enabled] = off

Стойностите трябва да са зададени така, че приложенията да не могат да ги презаписват, затова php_admin_value. При memory_limit=-1 услугата се нуждае от външно ограничение на паметта, чрез контейнер или cgroup, а не чрез RLIMIT_AS или RLIMIT_DATA. При PHP 8.5 се добавя fatal_error_backtraces=0. Всички подробности има на страницата Незабавни мерки, когато още не можете да пачнете.

Как помага PHP SOS конкретно?

Чрез нашата услуга за пач на PHP затваряме CVE-2026-109618 структурирано:

• Установяване на текущото състояние: PHP клон, режим на работа, източник на пакетите и състояние на backport-а за всеки сървър.
• Внасяне на актуализацията от подходящия източник на пакети или, където това не е възможно, чисто задаване на временните мерки в конфигурацията на пула или сървъра.
• Проверка на рестартирането: Контролираме, че не работят повече стари PHP процеси.
• Доказателство: Получавате документация с версиите и състоянията на пакетите преди и след намесата, например за управителите, застрахователя или защитата на данните.

Често задавани въпроси

Източници

• php.net: Съобщения за сигурност
• PHP 8 ChangeLog
• BSI: Федерална служба за информационна сигурност