# CVE-2026-109619: RCE чрез остаряло глобално състояние

> CVE-2026-109619 обяснена разбираемо: защо вътрешно състояние между заявките е опасно, кои PHP версии са поправени и как да осигурите сървъра.

Източник: https://phpsos.de/bg/php2shell/cve-2026-109619/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** 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](https://phpsos.de/bg/php2shell/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 носи най-висок риск](https://phpsos.de/bg/php2shell/mod-php-risiko/).

## Затваряне на CVE-2026-109619: актуализация, след това рестартиране на всички worker процеси

Именно при тази уязвимост рестартирането е решаващо. Докато стари worker процеси работят в паметта, сървърът продължава да работи с грешния код, дори новите файлове отдавна да лежат на диска.

Проверете версията и състоянието на пакета. Имената на пакетите се различават според дистрибуцията и интерфейса на хостинг доставчика:

```bash
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"
```

След това рестартирайте всички засегнати услуги:

```bash
sudo systemctl restart php8.3-fpm     # за всяка инсталирана версия на PHP
sudo systemctl restart apache2        # при mod_php; при RHEL услугата се казва httpd
```

Ако Вашата дистрибуция или Вашият хостинг доставчик внесе backport, показваният номер на версията може да остане същият. Тогава значение имат changelog-ът на пакета и писменото потвърждение на доставчика. Проверка стъпка по стъпка ще намерите на страницата [Рестартиране на PHP-FPM и на всички worker процеси](https://phpsos.de/bg/php2shell/php-fpm-neustart/).

> **Съвет:**
> Запишете датата и часа на рестартирането. За по-късната оценка дали една атака е станала преди или след пача, този момент е най-важната опорна точка.

## Какво остава да се направи след пача

Един пач не доказва, че преди това нищо не е станало. Според съобщения в медиите първият опит за атака е наблюдаван на 17 октомври, четири дни преди пачовете. Съхранявайте сървърните логове от 20 октомври нататък, както препоръчва специализираната преса, и проверете сървъра за аномалии. Бележки по темата дава страницата [Вече компрометиран ли съм?](https://phpsos.de/bg/php2shell/bin-ich-gehackt-anzeichen/).

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

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

Чрез [услугата за пач на PHP](https://phpsos.de/bg/leistungen/php-patch-service/) внасяме поправката проследимо:

- **Установяване:** Какви 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 задачи.

## Източници

- [php.net: Съобщения за сигурност](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI: Федерална служба за информационна сигурност](https://www.bsi.bund.de/)