NexTool Solutions

Две критические уязвимости в самом PHP, получившие название PHP2Shell (CVE-2026-109618 и CVE-2026-109619), позволяют выполнять код на сервере с помощью запросов без входа в систему, ещё до того, как запустится какой-либо код приложения. Они затрагивают любую установку PHP, обслуживающую веб-запросы, а GLPI работает на PHP. Исправление содержится в версиях 8.5.12, 8.4.27, 8.3.36 и 8.2.35, выпущенных 21 октября 2026 г. В этом руководстве объясняется, что это за уязвимости, почему GLPI находится на линии огня, как выяснить, где у вас установлен PHP, как исправить его в каждом сценарии, как понять, не проник ли уже кто-то, и что делать после этого.

В этом руководстве использована публичная информация, доступная на 22 октября 2026 г. Бюллетени безопасности быстро меняются: перед тем как действовать, сверьтесь также с бюллетенем вашего поставщика или дистрибутива.

Обновление: 23 октября 2026 г. PHP раскрыл третью уязвимость, CVE-2026-115560, пока без исправления. Смотрите, что меняется и какая настройка защищает.

Кратко — для тех, у кого пять минут

Обновление от 23.10: третья уязвимость, CVE-2026-115560

23 октября проект PHP опубликовал бюллетень о третьей уязвимости удалённого выполнения кода, CVE-2026-115560, связанной с функцией отслеживания прогресса загрузки в сессиях (session upload progress). Она отличается от двух уязвимостей PHP2Shell, и версии от 21 и 22 октября её не исправляют. Исправление выйдет в следующей регулярной версии PHP, дата которой пока не объявлена, и полный бюллетень будет опубликован вместе с ней.

Путь атаки гораздо уже, чем у PHP2Shell. Он существует только при одновременном выполнении трёх условий:

1. в php.ini параметр session.serialize_handler задан как php_binary или php_serialize;
2. приложение меняет это значение на php во время выполнения с помощью ini_set() до открытия сессии;
3. отслеживание прогресса загрузки в сессии включено, что является значением по умолчанию в PHP.

GLPI такую замену не выполняет. Мы проверили код GLPI 10, 11 и 12: он не меняет serialize_handler и не использует отслеживание прогресса загрузки в сессии. Сервер, на котором работает только GLPI со стандартной конфигурацией PHP, этим путём не уязвим. Риск появляется, когда тот же PHP обслуживает другие приложения — сайт, магазин или унаследованную систему, — которые вы не можете проверить.

Тем не менее рекомендуется отключить эту функцию сейчас. Сам PHP уже предлагал это 21 октября как меру сдерживания для CVE-2026-109619, и GLPI ничего не теряет:

session.upload_progress.enabled = Off

Добавьте строку в php.ini того PHP, который обслуживает веб, или в пул PHP-FPM (php_admin_flag[session.upload_progress.enabled] = off) и перезапустите PHP-FPM или Apache. Настройка из кода через ini_set() или в файле .user.ini не защищает. Где находится файл в каждом сценарии:

Для проверки на сервере используйте PHP-FPM, а не PHP командной строки, который читает другой файл:

sudo php-fpm8.3 -i | grep session.upload_progress.enabled
grep -rn upload_progress /etc/php/8.3/fpm/

Ожидаемый результат — Off. Если в каком-либо пуле есть строка со значением on, она имеет приоритет над php.ini.

Совет: эта настройка не заменяет обновление для уязвимостей от 21 октября. Она лишь закрывает новую уязвимость до выхода исправления. Когда PHP опубликует следующую версию, обновитесь снова.

Что произошло

Проект PHP опубликовал исправления безопасности для двух уязвимостей удалённого выполнения кода в ядре языка. В официальном changelog исправления значатся как «Avoid state corruption via bailout» (GHSA-w8hw-w9fx-j79w и GHSA-6wmf-4rv5-p3rp). Источники по безопасности называют оценку 9,2 по шкале CVSS 4.0, что относит их к критическому уровню. Некоторые источники называют 9,8 по шкале CVSS 3.1 в NVD.

Простыми словами:

• CVE-2026-109618: нехватка памяти может прервать PHP посреди запроса, когда внутренние данные инициализированы лишь частично. При очистке запроса PHP начинает считать эти недействительные данные действительными.
• CVE-2026-109619: внутреннее состояние одного запроса может сохраниться после освобождения его памяти. Следующий запрос, обслуживаемый тем же процессом, может использовать это состояние до его повторной инициализации.

Оба случая — проблемы управления памятью внутри интерпретатора, и именно это делает их серьёзными. Согласно опубликованным анализам, один-единственный запрос без аутентификации может запустить атаку ещё до того, как выполнится какой-либо код приложения. То есть экран входа GLPI, права профилей и правила приложения даже не проверяются.

Какие установки уязвимы

В бюллетенях упоминаются все способы запуска PHP для веба: PHP-FPM (самый распространённый вариант с Nginx и современным Apache), Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Анализы указывают на mod_php как на сценарий с наибольшим риском.

PHP командной строки (CLI), который выполняет автоматические задачи GLPI через cron, не обслуживает веб-запросы. Обычно он имеет ту же версию и обновляется вместе с остальными пакетами.

Дело не только в GLPI

Уязвимость находится в PHP, а не в каком-то приложении. Поэтому уязвима любая система на PHP, обслуживающая веб, и исправление для всех одно: обновить PHP и перезапустить службу. Обновление WordPress, GLPI или плагина проблему не решает.

Предупреждение вышло далеко за пределы ИТ: например, Mercado Pago предупредил продавцов, использующих WooCommerce, PrestaShop и Adobe Commerce (Magento), чтобы они проверили PHP своих магазинов.

На практике тот, кто отвечает за GLPI, почти всегда отвечает и за другие серверы с PHP: сайт компании, интранет, мониторинг, унаследованную систему, которую никто не выключил. Исправив только GLPI, вы оставляете дверь открытой на соседнем сервере. В шаге 1 мы покажем, как использовать инвентаризацию самого GLPI, чтобы найти их все.

Уязвимости уже эксплуатируются?

Источники расходятся, но рекомендацию это не меняет:

• Amazon: по данным Help Net Security, команда Amazon по анализу угроз зафиксировала попытку эксплуатации в своей сети honeypot-ловушек (MadPot) 17 октября, за четыре дня до публичного раскрытия.
• watchTowr: в своих ответах на частые вопросы о PHP2Shell 21 октября сообщила, что наблюдала эксплуатацию уязвимостей в своей сети honeypot-ловушек.
• CISA (агентство кибербезопасности США): в предупреждении от 21 октября заявило, что к тому моменту не наблюдало эксплуатации, но призвало к немедленному обновлению. Тем, кто не может обновиться, рекомендовано отключить системы на PHP до исправления. Британский NCSC дал такую же рекомендацию.

Когда попытки уже зафиксированы, в том числе до раскрытия, а правительственное предупреждение призывает отключить то, что нельзя исправить, путь от «возможно» до «происходит» обычно занимает дни. Относитесь к этому как к чрезвычайной ситуации.

Почему GLPI на линии огня

GLPI — классическое PHP-приложение: веб-сервер, PHP и база данных. Каждый запрос к GLPI проходит через PHP, включая те, что приходят до входа в систему. И у GLPI обычно больше дверей, открытых в интернет, чем кажется:

Поскольку атака происходит до запуска кода GLPI, любой из этих URL может служить дверью. Неважно, требует ли API токен или портал — вход в систему: вредоносный запрос даже не проходит проверку.

А за этой дверью — чувствительные данные. Сервер GLPI хранит доступ к базе со всеми заявками, вложениями, данными пользователей и инвентаризацией компании. В папке config находятся пароль базы данных и ключ, защищающий пароли, сохранённые в GLPI (сборщик почты, LDAP, SMTP). Тот, кто выполняет код на сервере, получает доступ ко всему этому.

Три распространённые ловушки

• Обновление GLPI не обновляет PHP. Тот, кто только что перешёл на GLPI 12, не защищён автоматически: GLPI 12 требует PHP 8.3, но работает и с версией 8.3, вышедшей до исправления.
• Номер версии может вводить в заблуждение. Ubuntu обычно применяет исправление в пакете и сохраняет номер (24.04 показывает 8.3.6 даже после обновления). Debian иногда поступает так же, а иногда повышает версию. «Старый» номер не доказывает, что сервер уязвим, а новый пакет не доказывает, что служба была перезапущена. В этот раз Debian повысил номер (8.4.27 в Debian 13 и 8.2.35 в Debian 12): там старый номер означает пакет без исправления.
• PHP 8.1 с GLPI 10 — самое рискованное сочетание: PHP без официальной исправленной версии и GLPI без поддержки. Смотрите раздел о PHP 8.1 ниже.

Шаг 1: выясните, где у вас установлен PHP

CISA начинает свои рекомендации именно с этого: провести инвентаризацию всех систем с PHP. GLPI — лишь одна из них. Обычно обнаруживаются также сайт компании, интранет, Zabbix, phpMyAdmin, Moodle, старая система заявок, которую никто не выключил.

Используйте для этого сам GLPI

Если вы используете GLPI Agent, инвентаризация ПО уже знает, где установлен PHP:

1. Перейдите в Активы > Программное обеспечение (в некоторых переводах — Программы) и выполните поиск по php.
2. Откройте такие элементы, как php8.3-fpm, php8.3-common, libapache2-mod-php8.3 или php-fpm, в зависимости от дистрибутива.
3. На вкладке установок посмотрите, на каких компьютерах установлена каждая версия.

Версия, которую показывает агент, — это версия пакета с суффиксом дистрибутива (например, 8.3.6-0ubuntu0.24.04.x). Именно её нужно сравнивать с бюллетенем безопасности дистрибутива. Инвентаризация не видит PHP внутри контейнеров Docker и PHP, распакованный в Windows или XAMPP.

Проверьте PHP, который обслуживает GLPI

PHP командной строки может отличаться от того, что обслуживает сайт. Чтобы увидеть то, что важно:

• В GLPI: в разделе Настройки > Общие > Система блок сервера показывает версию PHP, которую использует GLPI.
• На сервере: посмотрите, какая служба запущена и какую версию она использует.

php -v
systemctl list-units --type=service | grep -Ei 'php|apache|httpd'
sudo php-fpm8.3 -v

Замените 8.3 на версию, которая появится в списке служб. В Red Hat и производных используйте sudo php-fpm -v.

Шаг 2: обновитесь в соответствии с вашим сценарием

Ubuntu и Debian с PHP из самого дистрибутива

Дистрибутивы получают исправления до публичного раскрытия и публикуют пакеты в своих бюллетенях безопасности (в Ubuntu — USN-8948-1 от 21.10; в Debian — DSA-6574-1 и DLA-4848-1). В Ubuntu основной номер не меняется; проверяйте по пакету:

sudo apt-get update
apt-cache policy php8.3-fpm
sudo apt-get install --only-upgrade 'php8.3*'
zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | grep -E 'CVE-2026-10961[89]'

Последняя команда читает changelog установленного пакета и должна показать CVE-2026-109618 и CVE-2026-109619. Если включены автоматические обновления безопасности, пакет, возможно, уже установлен; тем не менее служба начнёт использовать новый код только после перезапуска.

Ориентировочные версии по дистрибутивам:

PHP из стороннего репозитория (ondrej/php, sury.org) или панели хостинга

Эти пакеты несут номер официальной версии (например, 8.3.36-1+ubuntu24.04.1+deb.sury.org+1 в Ubuntu), поэтому проверка простая. Автоматические обновления дистрибутива обычно не охватывают эти репозитории; то же касается панелей, которые устанавливают PHP из sury, например CloudPanel:

sudo apt update && sudo apt upgrade
php -v

В панелях вроде cPanel, Plesk или aaPanel используйте обновление PHP средствами самой панели и проверьте версию для каждого сайта.

Red Hat, Rocky, AlmaLinux и Oracle Linux

sudo dnf check-update 'php*'
sudo dnf update 'php*'
rpm -q --changelog php-common | grep -E 'CVE-2026-10961[89]'

В PHP из самого Red Hat (модули AppStream) номер также не меняется: ориентируйтесь на changelog. Если PHP установлен из репозитория Remi, обновление приходит с номером официальной версии (8.2–8.5 для RHEL 8, 9 и 10): проверяйте через php -v. В день раскрытия у Remi ещё не было пакетов, а зеркала были перегружены: если dnf не предлагает обновление, выполните sudo dnf upgrade --refresh 'php*', что игнорирует кэш, и повторите попытку через несколько минут. В Remi в режиме SCL служба называется, например, php83-php-fpm.

Docker

Контейнер не обновляется сам, а перезапуск старого контейнера не меняет PHP. Нужно скачать новый образ и пересоздать контейнер. Предварительно сделайте резервную копию базы данных и убедитесь, что папка файлов, папка config и база данных находятся в томах (docker inspect <container> --format '{{json .Mounts}}'); иначе пересоздание контейнера удалит данные. Если образ использует тег latest, pull может принести другую версию GLPI: зафиксируйте тег. В docker compose указывайте имя службы GLPI (в командах ниже — glpi): без имени pull скачает и образ базы данных, а с mariadb:latest это может принести более новую мажорную версию СУБД.

docker compose pull glpi
docker compose build --pull glpi
docker compose up -d glpi
docker exec <container-do-glpi> php -v

Если вы используете официальный образ glpi/glpi, он уже вышел с исправленным PHP: 22.10 все теги (latest, 12.0.0, 11.0.11, 10.0.28 и nightly) содержали PHP 8.5.12, так что достаточно выполнить pull. Он использует Apache с mod_php — сценарий с наибольшим риском, ещё одна причина не откладывать. Если ваш образ собирается на основе официального образа PHP (например, php:8.3-fpm или php:8.3-apache), исправленные теги выходили в течение 21.10, а теги FrankenPHP — в ночь на 22.10 (UTC); pull, выполненный раньше, принёс уязвимую версию. Две предосторожности: apt upgrade внутри Dockerfile не обновляет PHP в этих образах, так как он собирается отдельно; а плавающий тег может принести больше, чем PHP (веб-сервер образа тоже может сменить версию). Перед пересозданием сохраните текущий образ, чтобы иметь возможность откатиться: docker tag "$(docker inspect --format '{{.Image}}' <container-do-glpi>)" glpi-antes-do-patch.

Windows (IIS, XAMPP, WampServer)

Скачайте исправленную версию вашей ветки с официального сайта PHP для Windows и замените папку PHP, сохранив свой php.ini. Готовые сборки вроде XAMPP обычно публикуют новую версию с задержкой; не ждите их. Затем перезапустите IIS или Apache.

Шаг 3: перезапустите и проверьте

Обновить пакет недостаточно. Уже запущенные процессы продолжают работать со старым кодом, загруженным в память, до перезапуска:

sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2

В Red Hat и производных службы обычно называются php-fpm и httpd. После перезапуска:

1. Откройте Настройки > Общие > Система в GLPI и проверьте версию PHP.
2. Выполните php -v на сервере и проверьте также PHP-FPM (sudo php-fpm8.3 -v).
3. С PHP из sury, Remi, официального образа Docker или Windows GLPI должен показывать исправленную версию. Если он показывает старую, значит, ещё работает старый процесс или установлен второй PHP.
4. С PHP из самого дистрибутива номер может не измениться. Проверьте пакет (dpkg -l 'php8.3*' или rpm -q php-fpm) и то, была ли служба перезапущена после установки: systemctl status php8.3-fpm показывает время в строке «active since». В Ubuntu sudo needrestart -r l выводит список того, что ещё работает со старым кодом; в Red Hat — sudo dnf needs-restarting -s.

Протестируйте GLPI, прежде чем считать работу завершённой

Обновление PHP редко ломает GLPI, но действует правило для любого изменения в продуктиве: по возможности сначала примените его на тестовой копии и в любом случае заранее сделайте резервную копию. После обновления за несколько минут проверьте процессы, которые не должны останавливаться:

1. Вход в систему, в том числе через LDAP или единый вход (SSO), если вы их используете.
2. Создание заявки через портал самообслуживания и через форму.
3. Сборщик почты: отправьте тестовое письмо и проверьте, превращается ли оно в заявку.
4. Уведомления: проверьте, продолжает ли GLPI отправлять письма.
5. Автоматические действия: в разделе Настройки > Автоматические действия проверьте, что задачи продолжают выполняться.
6. API и интеграции: инвентаризация от агентов, чат-боты, ERP и автоматизации, обращающиеся к GLPI.
7. Плагины: откройте экраны плагинов, которыми команда пользуется чаще всего.

А если обновиться сейчас невозможно?

• Уберите GLPI из интернета до исправления. Оставьте доступ только из внутренней сети или через VPN. Если портал самообслуживания должен оставаться открытым, это приоритет номер один для обновления, а не повод его откладывать.
• Ограничьте то, что должно оставаться открытым, до PHP. Делайте ограничение на файрволе или веб-сервере (allow/deny в Nginx, Require ip в Apache), но никогда в настройках самого GLPI, которые работают только после PHP. И помните: ограничение только инвентаризации и API мало что даёт, если экран входа остаётся открытым.
• Отключите отслеживание прогресса загрузки в сессии (session.upload_progress.enabled = Off), как рекомендовал PHP. Это закрывает CVE-2026-115560 и снижает уязвимость к CVE-2026-109619, но не заменяет обновление.
• Используйте межсетевой экран для веб-приложений (WAF) как временную меру. Cloudflare опубликовала первоначальные правила для известных векторов. Это помогает, но не исправляет: сама AWS предупредила, что никакое изменение конфигурации не является полной мерой защиты. Правила действуют даже на бесплатном тарифе Cloudflare.
• Усильте наблюдение. Следите за процессами PHP, которые открывают shell или скачивают файлы, — именно этот признак CISA просит отслеживать.

Шаг 4: проверьте, не проник ли уже кто-то

Прежде всего, хорошая новость: то, что вы работали на уязвимой версии, не доказывает, что произошло вторжение или утечка данных. Это лишь повод проверить. Самая ранняя зафиксированная попытка относится к 17 октября. Если ваш GLPI был открыт с уязвимым PHP в этот период, после исправления стоит провести быструю проверку. Ни одна из этих команд ничего не изменяет.

PHP-файлы там, где их быть не должно. Папка данных GLPI хранит вложения, изображения и временные файлы; там не должны появляться файлы .php, за исключением кэша (_cache) и классов, генерируемых такими плагинами, как Дополнительные поля (Fields) и GenericObject, в files/_plugins/fields и files/_plugins/genericobject. Они попадут в результат, и это ожидаемо, если даты совпадают с изменениями, которые вы вносили:

sudo find /var/lib/glpi/files /var/www/glpi/files -name '*.php' -not -path '*/_cache/*' 2>/dev/null
sudo find /var/www/glpi -type f -name '*.php' -newerct '2026-10-15' -not -path '*/files/_cache/*' 2>/dev/null

Второй поиск использует время изменения файла в системе (ctime), которое злоумышленник не может подделать с помощью touch. Скорректируйте пути под вашу установку. Файлы плагинов и GLPI, обновлённые вами в этот период, ожидаемы; тревогу вызывает то, что никто не помнит, как туда положил.

Процессы и подключения пользователя веб-сервера:

ps -eo user,pid,ppid,lstart,cmd | grep -E '^(www-data|apache|nginx)' | grep -Ev 'php-fpm|apache2|httpd|nginx'
sudo ss -tnp | grep -E 'php|apache|httpd|"(sh|bash|dash|nc|ncat|perl|python[0-9.]*)"'
sudo crontab -u www-data -l

В Red Hat пользователь — apache (crontab -u apache -l). Пользователь веб-сервера не должен запускать sh, bash, curl, wget или nc и не должен иметь запланированных задач, которые вы не создавали (задача cron.php GLPI легитимна). Насторожитесь при исходящих подключениях к IP-адресам, которые не являются базой данных, LDAP, SMTP или вашими интеграциями.

Новые учётные записи и плагины в GLPI. В разделе Администрирование > Пользователи добавьте столбец «Дата создания» (значок столбцов), отсортируйте по нему и проверьте, не появилась ли неизвестная учётная запись с 17 октября, особенно с профилем Super-Admin. Проверьте также Администрирование > Профили (изменения прав), Настройки > Плагины (нет ли плагина, который вы не устанавливали?) и клиентов API.

Журналы веб-сервера и PHP. Всплески странных запросов с неизвестных IP-адресов, за которыми следуют ошибки 500, заслуживают внимания, особенно на URL из таблицы выше. В журнале PHP-FPM также стоит обратить внимание на серии «Allowed memory size exhausted» и процессы, завершённые по сигналу (например, «exited on signal 11»).

Если вы обнаружили признаки вторжения

1. Изолируйте сервер от сети, не выключая его, чтобы сохранить улики.
2. Сохраните журналы и копию диска до какой-либо очистки.
3. Восстановите систему с чистой основы и верните данные из резервной копии, сделанной до вторжения, оценив, что нужно переделать после этой даты. Удаление только найденного файла не гарантирует, что не осталось другой двери.
4. Смените все секреты, которые хранил сервер, — но только после изоляции и восстановления. Если злоумышленник всё ещё в среде, новые пароли утекут вместе со старыми. Порядок такой: сдержать, очистить и только потом менять:
5. пароль базы данных, который находится в config/config_db.php (или в /etc/glpi/ при установке из пакета);
6. ключ glpicrypt.key, защищающий пароли, сохранённые в GLPI: сгенерируйте новый с помощью php bin/console glpi:security:change_key, который перешифровывает данные (замена файла вручную сделает секреты нечитаемыми), а затем смените сами пароли: сборщиков почты, учётной записи LDAP для чтения, SMTP и прокси;
7. пароли локальных администраторов GLPI, поскольку их хеши были в базе данных;
8. токены API (приложений и пользователей) и секреты OAuth;
9. учётные данные интеграций, к которым обращается GLPI (ERP, чат-бот, автоматизации).
10. Оцените необходимость уведомлений: если персональные данные могли быть доступны посторонним, привлеките ответственного за защиту данных (DPO) и юристов. LGPD (ст. 48) предусматривает уведомление ANPD и субъектов данных, когда инцидент может повлечь значительный риск или ущерб, а регламент ANPD устанавливает для этого короткий срок.

PHP 8.1 или старше: проблема серьёзнее

PHP 8.1 и более ранние версии больше не поддерживаются проектом PHP и поэтому не получают официальную исправленную версию. Команда PHP опубликовала минимальные исправления в исходном коде для 7.4, 8.0 и 8.1: те, кто сам компилирует PHP, могут их применить; остальные зависят от того, опубликует ли пакет поставщик или дистрибутив. Для PHP 5 и 7.0–7.3 исправлений нет вовсе (это касается тех, кто ещё работает на GLPI 9.5). В Ubuntu 22.04, например, PHP 8.1 сопровождает сама Canonical: USN-8948-1 от 21.10 уже содержит исправление. Sury и PPA ondrej/php также поддерживают пакеты версий 7.4–8.1; проверьте, есть ли в них уже исправление. Если GLPI размещён на управляемом хостинге, попросите у хостинга пакет с исправлением обеих уязвимостей или приоритетный план перехода на поддерживаемую версию с конкретной датой.

Те, кто ещё работает на PHP 8.1, обычно используют и GLPI 10, который лишился поддержки с выходом GLPI 12. GLPI 11 требует PHP 8.2 или новее, а GLPI 12 — 8.3. Если это ваш случай, исправление этой уязвимости и уход с GLPI 10 стали одним проектом: смотрите риски дальнейшей работы на GLPI 10 и план перехода.

После исправления: сделайте следующий испуг меньше

• Уберите из интернета то, чему там не место. Инвентаризация — только с IP-адресов агентов, API — только с серверов, которые его используют, административная часть — только через VPN, всегда с правилом на файрволе или веб-сервере.
• Скройте версию PHP. С expose_php = Off в php.ini сервер перестаёт сообщать версию в заголовке ответа. Это снижает автоматическое сканирование, но не защищает: атака не зависит от знания версии.
• Включите автоматические обновления безопасности дистрибутива и помните, что они не охватывают сторонние репозитории и образы Docker.
• Имейте проверенную резервную копию базы данных и папки файлов GLPI. Восстановление — план Б для любой критической уязвимости.
• Отслеживайте уязвимости вашей среды. CVE Scan бесплатен: он проверяет версию GLPI и PHP, заголовки безопасности и права доступа и показывает, что исправлять в первую очередь.

Хронология

Чек-лист на сегодня

1. Составить список всех серверов с PHP, а не только сервера GLPI (инвентаризация GLPI в этом поможет).
2. Проверить версию в разделе Настройки > Общие > Система и пакет на сервере.
3. Обновить, начиная с того, что открыто в интернет.
4. Перезапустить PHP-FPM или Apache и проверить ещё раз.
5. Если обновиться сегодня невозможно, закрыть внешний доступ.
6. Выполнить проверки на вторжение и сохранить результат.
7. Ограничить инвентаризацию, API и административную часть только необходимым.
8. Отключить session.upload_progress.enabled в php.ini или в пуле PHP-FPM, перезапустить и проверить.

Нужна помощь с обновлением сервера GLPI или с проверкой уязвимости вашей среды? Свяжитесь с нами.

Источники: бюллетени безопасности PHP от 21 и 23.10.2026, предупреждение CISA (21.10.2026), официальный changelog PHP (php.net), бюллетень безопасности AWS, материал Help Net Security о PHP2Shell, FAQ от watchTowr, бюллетень Ubuntu (USN-8948-1), трекер безопасности Debian и уведомление Mercado Pago для разработчиков (21.10.2026). GLPI — зарегистрированная торговая марка Teclib'. NexTool не аффилирована с Teclib'.