PHP2Shell CVE-2026-109618 и 109619: как закрыть Zabbix, GLPI, FreePBX и другие PHP-панели

Если у вас есть Zabbix, GLPI, FreePBX, phpMyAdmin или веб-почта, внутри каждой работает PHP, и уязвимости CVE-2026-109618 и CVE-2026-109619 касаются его, а не самого приложения. Сначала найдите панели, открытые из интернета, и закройте их по IP или VPN. Затем обновите PHP средствами дистрибутива (исправления: 8.5.12, 8.4.27, 8.3.36, 8.2.35) и перезапустите сервисы. На 21 октября 2026 заявления вендоров Zabbix, GLPI и FreePBX не подтверждены, проверьте их заново.

PHP2Shell на 21 октября 2026: почему страдают именно внутренние панели

На 21 октября 2026 картина такая. В ядре PHP опубликованы две критические уязвимости, CVE-2026-109618 и CVE-2026-109619, обе с оценкой CVSS v4.0 9.2. Исправления вышли в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Для PHP 8.1 и старше официального исправления нет. Атака идёт без аутентификации, по сети, обычно через запрос multipart/form-data, а конфигурация по умолчанию уязвима. Подробный обзор и план на первый час мы разобрали в статье PHP2Shell: что делать за первый час. Здесь только одна тема: служебные веб-интерфейсы, про которые обычно забывают.

Почему они в зоне риска? Ошибка сидит в интерпретаторе, а не в коде приложения. Sansec подтвердил удалённое выполнение кода без логина на Roundcube 1.7.4, phpMyAdmin 5.2.3 и Nextcloud 35.0.1, а также на WordPress, Magento, Joomla и других. Чистый код и свежие плагины тут не спасают: обновлять нужно сам PHP. Для Zabbix, GLPI, FreePBX, Snipe-IT, Cacti, LibreNMS и osTicket заявлений вендоров о проверке на 21 октября мы не нашли. Это не значит, что они безопасны. Это значит, что решение «подождать, пока вендор скажет» оставляет окно открытым, и мы его не используем.

Вторая причина в организации. Сайт компании у всех на виду: за ним следит владелец и подрядчик. А мониторинг на отдельной виртуалке, заявки техподдержки, АТС, веб-почта и панель базы данных ставили когда-то «на пару недель». Их PHP обновлялся вместе с системой раз в несколько лет, а админ, который их поднимал, давно ушёл. NCSC прямо рекомендует провести инвентаризацию всех экземпляров PHP, включая встроенные в продукты и аппаратные решения. Мы начинаем именно с этого списка.

Порядок работы простой. Сначала всё, что открыто из интернета: это закрываем от внешнего доступа или обновляем в первую очередь. Затем всё, что доступно только изнутри: обновляем по плану, но в тот же день проверяем, кто из внутренней сети вообще имеет к панелям доступ. Третьим идёт то, что обновить нельзя: старые АТС и устройства, для них остаются доступ по VPN и ограничение по IP. Дальше в статье идут те же шаги, что мы делаем у клиентов.

Сначала то, что видно из интернета: находим свои панели снаружи

Первый вопрос не про версии PHP, а про адреса. Какие из ваших служебных панелей отвечают на запросы из интернета? Ответ почти всегда неприятный: открытый порт 8080 для Zabbix, поддомен helpdesk для GLPI, веб-интерфейс АТС, проброшенный на роутере «временно для удалённого сотрудника», phpMyAdmin по адресу /phpmyadmin на том же сервере, что и сайт. Самый надёжный способ узнать — смотреть снаружи, а не вспоминать. Для этого берём любой хост вне вашей сети (арендованный VPS или мобильный интернет) и проверяем внешний адрес офиса или сервера.

# с хоста ВНЕ вашей сети; EXTERNAL_IP — внешний адрес офиса или сервера
nmap -Pn -p 80,443,8000,8080,8081,8443,9000,10050,10051 --open EXTERNAL_IP
# на самом сервере: что слушает сеть, а не только 127.0.0.1
sudo ss -tlnp | grep -E ':(80|443|8000|8080|8443)\b'

Параллельно открываем таблицу проброса портов (NAT) на роутере или шлюзе: именно там чаще всего находятся «забытые» правила. Каждое правило на порты 80, 443, 8080, 8443 сверяем с реальной службой за ним. Отдельно проверяем облачные панели хостинга: правила фаервола у провайдера, группы безопасности. Если у вас есть Cloudflare, помните предупреждение из разборов: его аварийные правила работают, только когда исходный сервер принимает трафик исключительно от Cloudflare. Если сервер доступен напрямую по IP, правила обходятся.

Найденное сортируем по тому, чем рискуем. Ниже наша рабочая таблица приоритетов, по ней мы идём сверху вниз.

Отдельное замечание про «внутреннюю сеть». На 21 октября эксплойт, патч и разборы уже публично доступны, Sansec ожидает массовую эксплуатацию. Внутренняя сеть в маленькой компании включает гостевой Wi-Fi, подключённые по VPN ноутбуки подрядчиков и принтеры. Если с любого из них можно открыть панель, то для злоумышленника она не такая уж «внутренняя». Поэтому уровень риска мы считаем по тому, кто может дойти до порта, а не по тому, как звучит название сети.

Как узнать версию PHP и где она живёт: у каждой панели свой путь

Самая частая ошибка — выполнить на сервере php -v и успокоиться. Эта команда показывает версию PHP для командной строки. Веб-запросы может обслуживать совсем другой PHP: пакет php-fpm другой версии, модуль mod_php в Apache или контейнер. На одном сервере часто стоят две-три версии. Поэтому мы сначала выясняем, кто именно отвечает на запросы, а потом смотрим его версию.

# какие PHP-сервисы вообще запущены
systemctl list-units --type=service --state=running | grep -Ei 'php|apache|httpd|nginx'
# FPM: версия самого сервера (Debian/Ubuntu; подставьте свою минорную версию)
php-fpm8.2 -v
# FPM на RHEL-семействе
php-fpm -v
# Apache: подключён ли mod_php
apache2ctl -M | grep -i php
# какие пулы FPM настроены и кем
ls /etc/php/*/fpm/pool.d/
# пакеты PHP и их точные версии (Debian/Ubuntu)
apt list '?installed ?name(^php[0-9.]+$)'

Если в ответе есть пул FPM, значит, PHP живёт отдельным процессом, и достаточно обновить пакет и перезапустить сервис. Если видите модуль mod_php, PHP встроен в процессы Apache: здесь недостаточно reload, нужен именно systemctl restart apache2 (на RHEL — httpd). Эту разницу мы проверяем после каждого обновления: см. раздел про проверку ниже. Если процессы запущены внутри Docker, версию нужно смотреть в контейнере, а не на хосте, об этом отдельная статья про PHP-FPM в Docker, Nextcloud и mailcow.

Ниже сводка по продуктам: где обычно живёт PHP и от какого источника его обновлять. Это типовая раскладка, у конкретной установки она может отличаться, поэтому команды выше всё равно выполняем.

Для Zabbix официальная документация версии 7.0 называет минимальной версией PHP 8.0.0 и требует memory_limit не менее 128 МБ. Для GLPI документация указывает минимум 7.4 для линейки 10.0 и 8.2 для линейки 11.0. Для FreePBX 17 на вики Sangoma заявлена поддержка только Debian 12 с PHP 8.2. Эти цифры важны не потому, что мы их оспариваем, а потому что по ним понятно, куда можно обновляться. Если ваш Zabbix 6.0 работает на PHP 7.4, то самый короткий путь к исправленной версии не обновление PHP с «потолком» вендора, а переход на поддерживаемую связку: проверьте у вендора, какие версии PHP разрешены для вашей версии продукта.

Версию PHP в самом веб-интерфейсе показывает не любая панель. У Zabbix проверка требований встроена в мастер установки, но не в рабочие экраны, у GLPI данные о PHP есть на странице диагностики для администратора, у phpMyAdmin — на главной странице. Мы не полагаемся на эти экраны и смотрим версию на сервере: то, что показывает интерфейс, часто относится к тому, как был настроен сервер при установке.

Как обновляем Zabbix, GLPI и FreePBX: средствами дистрибутива и по документации вендора

Главный принцип: PHP обновляем через менеджер пакетов дистрибутива, а приложение не трогаем. Вендор приложения — не поставщик интерпретатора. Ни Zabbix, ни GLPI, ни Sangoma на 21 октября 2026 мы не нашли подтверждённых заявлений об этой уязвимости: не обещаем, что «вышел патч Zabbix» или «вышла сборка FreePBX». Ссылки на официальные страницы мы даём в источниках. Нужна проверка у вендора в день выкладки. Работать же с PHP можно уже сейчас: он обновляется из репозиториев ОС.

Zabbix frontend. Определяем, что стоит: Apache или nginx, и откуда пришёл PHP. Для Debian 12 исправленная версия по нашим данным — 8.2.35-1~deb12u1 (DLA-4848-1), для Debian 13 — 8.4.27-1~deb13u1 (DSA-6574-1). На Ubuntu исправленные пакеты вышли для 22.04 (php8.1 8.1.2-1ubuntu2.28), 24.04 (php8.3 8.3.6-0ubuntu0.24.04.13) и новее. Перед обновлением смотрим, что именно предлагает репозиторий. Был случай, когда в обзорах пакет для Debian 12 ещё значился как «пока недоступен», поэтому не верим названию, а сверяем версию.

# что предлагает репозиторий и откуда
apt-cache policy php8.2-fpm
sudo apt update
sudo apt install --only-upgrade '?name(^php[0-9.]+$)'
# перезапуск: FPM или mod_php — смотря что у вас
sudo systemctl restart php8.2-fpm
sudo systemctl restart apache2   # если PHP как модуль Apache
# Ubuntu 20.04 и старше: только Ubuntu Pro (ESM)
sudo pro fix CVE-2026-109618

После обновления открываем Zabbix, входим и смотрим, что пошёл сбор данных, потому что у вебной части свои расширения: php-mysql или php-pgsql, php-bcmath, php-gd, php-xml, php-mbstring, php-ldap. Если при смене минорной версии PHP (например, с 8.1 на 8.3) расширения не переехали, фронтенд покажет ошибку на странице. Это решается установкой тех же пакетов расширений под новую версию. Важно: у Zabbix 7.0 в документации разрешённый диапазон версий PHP есть, и сравнивать надо с ней, а не с чужими статьями.

GLPI. Это типичное приложение «Apache или nginx плюс php-fpm из дистрибутива». Версию PHP обновляем как выше; затем открываем GLPI и проходим страницу диагностики. Главная ловушка — ограничение минимальной и максимальной версии PHP у конкретной ветки GLPI. Линейка 10.0.x проверяется на новые PHP «вскоре после релиза», линейка 11.0 требует не менее PHP 8.2. Если компания сидит на 10.0 и PHP 7.4, а исправления для 7.4 в дистрибутиве нет, то задача шире, чем «обновить PHP»: нужно планировать миграцию на поддерживаемую связку. До этого момента доступ ограничиваем по VPN. По схеме работы с самим GLPI у нас есть отдельный материал: учёт техники и заявок в GLPI.

FreePBX и Asterisk. У FreePBX 17 свой стек: поддерживается только Debian 12, PHP 8.2 из системных пакетов, а веб-часть вместе с Asterisk управляется собственным набором репозиториев и скриптов Sangoma. Поэтому обновлять PHP «как у обычного сайта» на АТС нужно осторожно: сначала проверяем apt-cache policy php8.2-cli, чтобы увидеть, из какого репозитория он пришёл, и сверяем с версией, которую дал Debian (8.2.35-1~deb12u1). Модули FreePBX, зависящие от версии PHP, могут вести себя иначе. Мы не утверждаем, что Sangoma выпустила собственное обновление: смотрите вики и форум FreePBX.

Перед обновлением на АТС всегда делаем резервную копию настроек средствами FreePBX (модуль Backup) и снимок виртуальной машины, а работу планируем в нерабочее время, чтобы не оборвать звонки. Пакетное обновление PHP само по себе не останавливает Asterisk, но перезапуск веб-сервера и FPM кратко прерывает вход в панель. Звонки идут через Asterisk и от PHP не зависят. Если АТС старая (FreePBX 15 или 16 на PHP 7.x, образы на CentOS 7), официальных обновлений не будет: эти системы мы переводим в режим «только внутренняя сеть или VPN» и планируем замену, про ситуацию с EOL-системами подробно в статье про CentOS 7, Alma и Remi.

Остальные панели из списка: phpMyAdmin, Roundcube, osTicket, Snipe-IT, Cacti, LibreNMS, Nextcloud и «железо»

phpMyAdmin и Roundcube. Обе системы Sansec назвал среди подтверждённых целей: phpMyAdmin 5.2.3 и Roundcube 1.7.4. Практический вывод: это худшие кандидаты на публикацию в интернет. phpMyAdmin даёт доступ к базе, а в памяти воркера лежат пароли и токены сессий, которые утечка CVE-2026-109618 может раскрыть. У нас правило: phpMyAdmin только по VPN или с разрешённых IP, вход по адресу вида /phpmyadmin на публичном сайте убираем совсем. Roundcube чаще нужен снаружи, тогда он должен стоять на актуальном PHP из дистрибутива, а до обновления мы включаем меры из раздела про временные решения.

osTicket, Cacti, LibreNMS. Они работают как стандартное приложение под Apache или nginx с php-fpm. Версию PHP смотрим теми же командами. Один нюанс: Cacti и LibreNMS регулярно выполняют задания по расписанию (poller), которые запускаются через php-cli, поэтому после обновления проверяем не только веб-страницу, но и то, что опрос устройств не остановился. Пока мы не видели подтверждения вендора для этих продуктов, поэтому описываем только то, что делается на стороне системы.

Snipe-IT и Nextcloud в контейнерах. Версию PHP определяет образ, а не хост. Обновление хостового php-пакета контейнер не лечит. Здесь пересобираем или тянем свежий образ с исправленным PHP и пересоздаём контейнер. Образ docker-library/php обновлён в репозитории, но на Docker Hub он появляется после отдельного запроса и сборки, а теги RC исправления не содержат. Поэтому мы смотрим версию внутри работающего контейнера: docker exec ИМЯ php -v. Про установку и регламент эксплуатации Snipe-IT у нас есть материалы: установка Snipe-IT в Docker и регламент эксплуатации. Для Nextcloud в разных вариантах поставки (пакеты, образ, All-in-One, snap) заявления вендора на 21 октября не подтверждены, проверьте у вендора.

МФУ, NAS и сетевые устройства. NCSC рекомендует искать PHP внутри продуктов вендоров, и это сложная часть. Веб-панели некоторых устройств построены на PHP, но обновить его можно только прошивкой производителя. Что делаем мы: составляем список всех устройств с веб-интерфейсом (принтеры и МФУ, NAS, камеры, видеорегистраторы, контроллеры точек доступа, шлюзы телефонии). Для каждого смотрим страницу безопасности вендора и заголовки ответа. Строка X-Powered-By может выдать PHP, но её нередко отключают, поэтому её отсутствие ничего не доказывает. Если вендор молчит или устройство снято с поддержки, закрываем доступ: панель устройства должна открываться только из административной подсети.

Мини-кейс, без цифр и без реальных клиентов. Условная стоматология «Белый Клён», 35 рабочих мест: сайт на хостинге, внутри — Zabbix, GLPI для заявок, АТС на FreePBX, веб-почта и NAS с кабинетом. Админ ушёл несколько лет назад, список систем хранится в голове. Мы начинаем с проверки внешнего адреса и таблицы проброса портов. Затем составляем реестр: адрес, продукт, веб-сервер, PHP, источник PHP, кто пользуется. После этого обновляем то, что обновляется из репозитория, ограничиваем доступ к остальному и ставим мониторинг версии. Реестр потом остаётся клиенту: его можно вести по нашей методике в статье об инвентаризации ИТ-активов.

Закрываем доступ: IP и VPN как главная мера, временные меры как дополнение

Когда обновить PHP нельзя сегодня, главная мера — убрать панель из интернета. Это не «ещё один слой», а единственное, что исключает самого атакующего. Мы ограничиваем доступ по адресам администраторов или по подсети VPN, причём на уровне веб-сервера или фаервола, а не в приложении: PHP разбирает multipart-запрос раньше, чем код приложения успеет проверить логин. Поэтому режимы «обслуживание» и ограничения внутри панели не помогают. Для nginx достаточно блока на уровне сервера, для Apache — директивы Require.

# в блоке server { ... } панели: пускаем только офис и подсеть VPN
allow 192.168.10.0/24;
allow 10.8.0.0/24;
deny all;

# в конфигурации виртуального хоста панели
<Location "/">
    Require ip 192.168.10.0/24 10.8.0.0/24
</Location>

Адреса в примерах условные, подставьте свои. После правки проверяем: с разрешённого адреса панель открывается, с внешнего хоста получаем 403 или отсутствие ответа. Дополнительно закрываем порт на фаерволе и убираем проброс с роутера, потому что фильтр на веб-сервере защищает только один порт. Для FreePBX отдельно помним: правило ограничения относится к веб-интерфейсу, а не к SIP-портам. Если вы закроете 5060 для всех, телефония у внешних абонентов перестанет работать. Вопрос защиты SIP это отдельная задача, и решается она другим набором правил.

Если обновить PHP невозможно даже в ближайшие дни, добавляем частичные меры из рекомендаций Sansec и Patchstack. Они не заменяют обновление. Отключаем session.upload_progress.enabled в php.ini или в конфигурации пула (не через ini_set() и не через .user.ini) и перезапускаем все воркеры. Эксперт PHP Gina Peter Banyard отмечает, что одного этого мало, а надёжных обходных мер нет, единственное исправление — патч. Для PHP 8.5 дополнительно задаётся fatal_error_backtraces=0. Ещё одна мера: memory_limit = -1 через php_admin_value в каждом пуле, но это риск: один запрос способен съесть всю память сервера, поэтому следите за ней.

; пул php-fpm (например /etc/php/8.2/fpm/pool.d/www.conf), затем перезапуск
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1

Радикальная мера — блокировка запросов multipart/form-data на веб-сервере (nginx: if ($http_content_type ~* "multipart/form-data") { return 403; }). Она ломает загрузку файлов и часть форм, поэтому после включения мы проверяем рабочие сценарии: вложения в заявках GLPI, импорт в Zabbix, загрузку голосовых приветствий в FreePBX. Для панели, которая работает только на просмотр (например, дашборд Zabbix без загрузок), это приемлемо. Не ставьте «плагины-заплатки» и сниппеты с форумов: Patchstack прямо предостерегает от этого. Про следы взлома и логи мы написали отдельно в статье о признаках эксплуатации в логах nginx и Apache.

Если на панели замечены признаки (необычные multipart-запросы с последующей ошибкой memory_limit, повторяющиеся HTTP 500, аномальные куки PHPSESSID, необъяснимые перезапуски воркеров), то считаем сервер возможно скомпрометированным. Мы обновляем PHP, изучаем журналы, а владельцу передаём список ключей и паролей на ротацию. Сами пароли живых учётных записей мы не меняем: решение остаётся за владельцем системы. В случае, когда ни обновление, ни меры невозможны на долгий срок, NCSC допускает отключение системы, и для старой АТС или устройства без прошивки это честный вариант.

Проверяем результат и ставим мониторинг версии PHP в Zabbix

Обновление считается выполненным, когда старый код больше не работает в памяти. Пакет мог обновиться, а процессы FPM или Apache продолжают жить на старых библиотеках. Автоматические обновления тоже сами не перезапускают PHP-сервисы. Из проверенных способов мы используем два: поиск процессов, которые держат удалённые файлы, и утилиту needrestart. Пустой вывод первой команды означает, что старого PHP в памяти нет.

sudo grep -lE ' /(usr|lib|opt).*\(deleted\)$' /proc/[0-9]*/maps
sudo needrestart -b -r l
# версия пакета и запись в changelog (на Debian номера CVE в changelog бывают не указаны — сравнивайте версию)
zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.2-fpm/changelog.Debian.gz

Дальше нужен постоянный контроль, иначе через год всё вернётся. Ставим мониторинг версии PHP и в Zabbix, и в реестр. Идея простая: агент на каждом сервере с панелью отдаёт версию пакета PHP, а триггер сигналит, если версия ниже эталонной или данные перестали поступать. Для этого используем пользовательские параметры агента (UserParameter). Файл кладём в каталог дополнительных конфигураций агента (для Agent 2 это обычно /etc/zabbix/zabbix_agent2.d/, для классического агента — /etc/zabbix/zabbix_agentd.d/) и перезапускаем агент.

# /etc/zabbix/zabbix_agent2.d/php.conf  (Debian/Ubuntu)
UserParameter=php.pkg[*],dpkg-query -W -f='${Version}' $1
UserParameter=php.cli.version,php -r 'echo PHP_VERSION;'
UserParameter=php.fpm.version[*],/usr/sbin/php-fpm$1 -v | head -n 1

Элементы данных в Zabbix: php.pkg[php8.2-fpm] вернёт строку версии пакета, php.fpm.version[8.2] — версию самого FPM. На RHEL-семействе вместо dpkg-query используем rpm -q --qf '%{VERSION}-%{RELEASE}' php-fpm. Тип элемента — Zabbix agent, тип информации — текст, интервал — раз в час достаточно. Триггер строим на изменение и на сравнение с эталоном, например через макрос хоста {$PHP.MIN.PKG}. Точный синтаксис выражения зависит от версии Zabbix: ориентируйтесь на её официальную документацию и проверяйте триггер на тестовом хосте.

Две оговорки. Первая: агент работает от пользователя zabbix, и нужно убедиться, что у него есть право выполнять эти команды. Вторая: в Zabbix по умолчанию запрещены небезопасные символы в параметрах пользовательских ключей, поэтому гибкие параметры задаём только с проверяемым вводом, как в примере с именем пакета. Не включайте удалённые команды (system.run) ради такой задачи: это даёт то, чего мониторингу давать не надо. Отдельно в дашборде Zabbix делаем простую сводку: хост, версия PHP, дата последнего обновления. Её видит и владелец, и мы.

Типичные ошибки, которые мы встречаем. Обновили PHP, но не перезапустили Apache, где работает mod_php: reload недостаточно. Обновили php-cli, а FPM остался старым. Закрыли панель по IP на сервере, но оставили проброс на роутере и другой порт. Включили блок multipart и сломали загрузку вложений в заявках, не проверив их. Оставили phpMyAdmin на публичном сайте. И, наверное, самая дорогая: забыли про устройство со встроенным PHP, которое никто не обновляет. Если хотите, мы проведём такую инвентаризацию за вас: это входит в услуги по внедрению и сопровождению открытого ПО.

Частые вопросы