21 октября 2026 года проект PHP сообщил о двух критических уязвимостях — CVE-2026-109618 и CVE-2026-109619. Обе получили оценку 9,2 по шкале CVSS 4.0. Ошибки связаны с обработкой внутреннего состояния PHP при нехватке памяти и завершении запроса; при успешной эксплуатации атакующий может добиться удалённого выполнения кода без входа в учётную запись. Подробности и рекомендации разработчиков опубликованы в официальном архиве сообщений PHP.
Проблема относится не к отдельной CMS, а к самому интерпретатору PHP. Поэтому потенциально затронуты сайты на Joomla, WordPress, OpenCart и других системах, если они используют уязвимую сборку PHP. Обновление CMS, шаблона или плагина само по себе не исправляет уязвимость интерпретатора.
Если PHP установлен непосредственно на сервере, обновляйте его через системный пакетный менеджер и проверяйте, что репозиторий уже содержит исправление. Например, на Debian или Ubuntu можно обновить пакеты установленной ветки PHP командами sudo apt update и sudo apt install --only-upgrade 'php8.3*' (в примере используется PHP 8.3; замените ветку на фактически установленную и повторите для каждой используемой версии). На RHEL, AlmaLinux или Rocky Linux пример команды для пакетов с именами, начинающимися на php, — sudo dnf upgrade 'php*'. Перед подтверждением проверьте список пакетов, которые планируется изменить, и не переключайте проект на другую основную версию PHP без проверки совместимости.
# Посмотреть активные службы PHP-FPM
systemctl list-units --type=service 'php*-fpm*'
# Пример перезапуска PHP-FPM; замените имя на службу вашего сервера
sudo systemctl restart php8.3-fpmПосле установки исправлений нужно перезапустить соответствующие процессы PHP-FPM, чтобы старые воркеры не продолжали обслуживать запросы. Команда php -v показывает версию PHP CLI, но сайт может работать через другой исполняемый файл, отдельный пул PHP-FPM или PHP, поставляемый панелью управления. Поэтому проверьте версию, указанную для каждого сайта в панели, конфигурации веб-сервера и службе, обслуживающей запросы. На сервере с несколькими версиями PHP нужно проверить каждую из них, а также отдельный PHP, если он используется самой панелью. В панелях управления обновляйте встроенные компоненты штатным менеджером или по инструкции поставщика: ручная замена файлов PHP в каталоге панели может нарушить её работу.
Если сайт привязан к PHP 5.6, 7.4, 8.0 или 8.1 и его нельзя быстро перевести на поддерживаемую ветку, не считайте случайный конфигурационный параметр полноценным исправлением. Согласуйте backport с поставщиком операционной системы или хостером и подготовьте миграцию. Пока исправление не применено, наиболее надёжная временная мера — ограничить доступ к уязвимому сервису из интернета. Фильтрация запросов на внешнем прокси или WAF может снизить риск, но не заменяет патч PHP. Настройка memory_limit = -1, которую можно встретить в рекомендациях, может уменьшить вероятность одного из сценариев эксплуатации, но не устраняет уязвимость полностью. Не применяйте её вслепую: изменение лимита памяти влияет на риск исчерпания ресурсов и не заменяет обновление PHP.
Отдельное исправление выпущено для YOOtheme Pro 5. В версии 5.0.53 от 21 октября закрыта уязвимость CVE-2026-102785 — удалённое выполнение кода без авторизации через обработчик изображений. Уязвимы версии YOOtheme Pro 5.0.0–5.0.52; обновите все сайты на ветке 5 до версии 5.0.53 или новее через Joomla и механизм обновления YOOtheme. По опубликованному уведомлению разработчика, ветки 4.x и ниже этой уязвимостью не затронуты. После обновления проверьте фактическую установленную версию расширения.
Есть и отдельный инцидент, связанный с VMmanager 6. ISPsystem подтвердила уязвимость в одной из сборок и сообщила о выпуске исправлений. Разработчик рекомендует ограничить входящие и исходящие соединения панели и узлов виртуализации доверенными адресами, разрешить SSH только с доверенных IP и сменить пароли. Если VMmanager используется вашим хостером, запросите подтверждение, что исправления установлены и инфраструктура проверена. Если вы администрируете такую платформу самостоятельно, следуйте актуальным рекомендациям НКЦКИ и официальным уведомлениям ISPsystem.
Если есть признаки взлома — неизвестные PHP-файлы, подозрительные задания cron, новые административные учётные записи, несанкционированные SSH-ключи или необычные исходящие соединения, — ограничьте доступ к серверу и сохраните логи для расследования. Не следует просто разворачивать резервную копию поверх работающего сайта, не выяснив причину инцидента. После локализации восстановите сайт из заведомо чистой копии, установите исправления, проверьте права доступа и смените пароли и ключи, которые могли быть раскрыты. При возможной компрометации VMmanager отдельно оцените риск утечки секретов, хранившихся на узлах и в конфигурациях.
Сейчас приоритет — инвентаризировать все используемые версии PHP, обновить поддерживаемые сборки, проверить YOOtheme Pro 5 и убедиться, что обновление действительно применилось к рабочим процессам сайта. Для устаревших PHP и инфраструктуры VMmanager нельзя полагаться только на отсутствие ошибок на главной странице: необходимы проверка конфигурации, журналов и статуса исправлений у поставщика.
