Накратко: CVE-2026-109619 е втората уязвимост зад PHP2Shell. Вътрешно състояние, принадлежащо на една заявка, може да остане след освобождаването на паметта; по-късна заявка в същия worker може да го използва, преди да бъде нулирано. Последицата е изпълнение на код без удостоверяване. Средство: актуализация до PHP 8.5.12, 8.4.27, 8.3.36 или 8.2.35 и рестартиране на всички worker процеси.
Какво е CVE-2026-109619?
CVE-2026-109619 (GitHub идентификация GHSA-6wmf-4rv5-p3rp) е оценена с CVSS v4.0 9,2. Заедно с CVE-2026-109618 образува PHP2Shell. И двете уязвимости са в самия PHP, а не в приложение.
Въздействието е същото като при сестринската уязвимост: атакуващият може отдалечено, без парола и без потребителски акаунт, да изпълнява код на сървъра. Причината обаче е друга.
Защо остарялото състояние в worker е опасно
Един PHP уеб сървър не стартира нов процес за всяка заявка. При PHP-FPM, Apache с mod_php, LiteSpeed или FrankenPHP един worker обработва последователно много заявки. Между две заявки PHP нулира вътрешното си състояние, за да не попадне нищо от заявка A в заявка B.
При CVE-2026-109619 това нулиране не успява напълно. Според php.net вътрешно състояние, принадлежащо на заявката, може да остане след освобождаването на паметта. По-късна заявка в същия worker може да използва това остаряло състояние, преди то да бъде нулирано. Казано опростено: нещо се използва повторно, което всъщност вече не е валидно.
От гледна точка на експлоатацията това е забележително. Повторното използване на worker процеси е желано, защото прави уеб сървърите бързи: един worker не трябва да се стартира наново за всяка заявка, да зарежда разширения и да заделя памет. Уязвимостта засяга следователно свойство, което има практически всяка производствена PHP инсталация. php.net не назовава конфигурация, която напълно избягва проблема; затова пътят минава през актуализацията.
Подробности за експлоатацията не публикуваме. За операторите е важно: всеки режим на работа, при който worker процесите обслужват няколко заявки, трябва да се държи под око, а точно тези режими са обичайните.
Двете уязвимости на PHP2Shell в сравнение
| Характеристика | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| GitHub идентификация | GHSA-w8hw-w9fx-j79w | GHSA-6wmf-4rv5-p3rp |
| Оценка | CVSS v4.0 9,2 | CVSS v4.0 9,2 |
| Причина | Out-of-Memory по време на инициализацията на данните от заявката | Вътрешно състояние остава след освобождаването |
| Въздействие | Изпълнение на код без удостоверяване | Изпълнение на код без удостоверяване |
| Поправена в | 8.5.12, 8.4.27, 8.3.36, 8.2.35 | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
Засегнати са PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Най-висок риск екипът на PHP вижда при mod_php; защо, обясняваме на страницата Защо mod_php носи най-висок риск.
Затваряне на CVE-2026-109619: актуализация, след това рестартиране на всички worker процеси
Именно при тази уязвимост рестартирането е решаващо. Докато стари worker процеси работят в паметта, сървърът продължава да работи с грешния код, дори новите файлове отдавна да лежат на диска.
Проверете версията и състоянието на пакета. Имената на пакетите се различават според дистрибуцията и интерфейса на хостинг доставчика:
php -v
php-fpm8.3 -v # FPM бинарният файл може да е друга версия от CLI
apt policy php8.3-fpm # Debian/Ubuntu
dnf info php-fpm # семейство RHEL
rpm -q --changelog php-fpm | grep -i "CVE-2026-109619"
След това рестартирайте всички засегнати услуги:
sudo systemctl restart php8.3-fpm # за всяка инсталирана версия на PHP
sudo systemctl restart apache2 # при mod_php; при RHEL услугата се казва httpd
Ако Вашата дистрибуция или Вашият хостинг доставчик внесе backport, показваният номер на версията може да остане същият. Тогава значение имат changelog-ът на пакета и писменото потвърждение на доставчика. Проверка стъпка по стъпка ще намерите на страницата Рестартиране на PHP-FPM и на всички worker процеси.
Запишете датата и часа на рестартирането. За по-късната оценка дали една атака е станала преди или след пача, този момент е най-важната опорна точка.
Какво остава да се направи след пача
Един пач не доказва, че преди това нищо не е станало. Според съобщения в медиите първият опит за атака е наблюдаван на 17 октомври, четири дни преди пачовете. Съхранявайте сървърните логове от 20 октомври нататък, както препоръчва специализираната преса, и проверете сървъра за аномалии. Бележки по темата дава страницата Вече компрометиран ли съм?.
Помислете при това за обхвата: при успешно изпълнение на код атакуващият има правата на PHP процеса. Той може да чете това, което приложението има право да чете, например конфигурационни файлове с достъп до бази данни или API ключове. Ако инцидентът се потвърди, тези данни за достъп трябва да се подновят след почистването.
Как помага PHP SOS конкретно?
Чрез услугата за пач на PHP внасяме поправката проследимо:
- Установяване: Какви PHP версии и режими на работа има на кой сървър и кой източник на пакети ги доставя?
- Пачване: Актуализация от правилния източник или временни мерки според php.net, където актуализацията още е блокирана.
- Контрол на рестартирането: Проверяваме процес по процес, че работи само поправената версия.
- Документиране: Версии, състояния на пакетите и моменти на рестартиране, за да можете да докажете състоянието.
Често задавани въпроси
С какво CVE-2026-109619 се различава от CVE-2026-109618?
CVE-2026-109618 възниква, когато състояние Out-of-Memory прекъсне заявката по средата на инициализацията. CVE-2026-109619 засяга състояние, което остава в worker след края на една заявка. И двете водят до изпълнение на код без удостоверяване и са поправени в същите PHP версии.
Помага ли по-честото рестартиране на PHP-FPM worker процесите?
Като заместител на актуализацията не е подходящо. php.net не назовава по-честите рестартирания на worker процеси като временна мярка. Трябва обаче да рестартирате worker процесите след актуализацията, за да работи изобщо поправената версия.
Защитен ли съм с актуализация на CMS срещу CVE-2026-109619?
Не. Уязвимостта е в PHP, а не във WordPress, Shopware, TYPO3 или друга система. Само актуализация на PHP или потвърден backport от доставчика я затваря.
Известни ли са следи от атака чрез CVE-2026-109619?
Потвърдени Indicators of Compromise досега не са публикувани. Откриването се основава на анализ на поведението, например нови PHP файлове, необичайни изходящи връзки или непознати cron задачи.