Next Generation CMS - Управляйте контентом без границ!
21 октября 2026 года команда разработчиков PHP опубликовала важное предупреждение о двух критических уязвимостях, которые могут позволить злоумышленнику выполнить произвольный код на сервере без авторизации. Проблема затрагивает PHP, используемый для обработки веб-запросов, поэтому под угрозой могут оказаться сайты, интернет-магазины, CMS и другие веб-приложения.
Главная рекомендация — как можно скорее обновить PHP до исправленной версии. Временные настройки способны уменьшить риск отдельных сценариев атаки, но не заменяют установку обновления.
В рамках обновления безопасности опубликованы следующие версии:
Если ваш сервер использует одну из этих веток PHP, необходимо установить соответствующее исправление или более новую версию, в которой оно уже включено. Перед обновлением проверьте доступность пакетов у поставщика PHP или операционной системы.
Официальные источники:
Уязвимости представляют опасность для установок PHP, которые обрабатывают веб-запросы. Это касается различных способов запуска PHP, в том числе:
По данным команды PHP, особое внимание следует обратить на конфигурации Apache с mod_php: для этого варианта продемонстрирован сценарий атаки, при котором специально сформированный запрос может запустить эксплуатацию уязвимости ещё до выполнения кода самого приложения.
Это означает, что наличие авторизации в административной панели, сложный пароль или защита отдельных страниц сайта не устраняют проблему. Уязвимость находится на уровне обработки запросов самим PHP.
Первая проблема связана с обработкой ситуации, когда PHP не может выделить необходимую память. В определённых условиях выполнение запроса прерывается в момент, когда внутренние структуры запроса ещё не полностью инициализированы.
При последующей очистке этих структур PHP может ошибочно обработать некорректные данные как допустимые. В результате возникает опасная ситуация с повреждением памяти, которая при определённых условиях позволяет добиться удалённого выполнения кода.
Уязвимость обозначена как CVE-2026-109618. Её описание опубликовано в официальном предупреждении безопасности PHP на GitHub.
Особенность этой проблемы заключается в том, что речь идёт не об ошибке конкретной CMS или плагина. Уязвимым звеном становится механизм обработки запроса внутри PHP.
Вторая уязвимость связана с жизненным циклом внутренних данных PHP. Часть состояния, относящегося к одному запросу, в определённых условиях может сохраниться после освобождения памяти, в которой эти данные находились.
Если тот же рабочий процесс PHP обработает следующий запрос до того, как состояние будет корректно сброшено, он может обратиться к устаревшим данным. Это создаёт условия для нарушения целостности памяти и потенциального выполнения произвольного кода.
Уязвимость обозначена как CVE-2026-109619. Подробности доступны в официальном уведомлении PHP на GitHub.
Обе проблемы особенно опасны для публичных серверов, где обработчики PHP принимают запросы от любых посетителей. Злоумышленнику не обязательно иметь учётную запись на сайте.
Перед обновлением выясните, какая версия PHP используется вашим сайтом. Важно учитывать, что версия PHP в командной строке и версия, используемая веб-сервером, могут различаться.
В Linux выполните команду:
php -v
В Windows откройте командную строку и выполните:
php -v
Команда покажет версию PHP, доступную в текущем окружении командной строки. Если на сервере установлено несколько версий, результат не обязательно соответствует версии, обслуживающей сайт.
Версию веб-окружения можно определить через административную панель хостинга или штатные инструменты CMS. При необходимости администратор может временно создать файл с вызовом phpinfo(), но такой файл нельзя оставлять общедоступным: он раскрывает сведения о конфигурации сервера.
После проверки удалите диагностический файл. Не публикуйте полный вывод phpinfo() в открытом доступе.
Способ обновления зависит от операционной системы, панели управления и того, каким способом установлен PHP. Не следует просто заменять исполняемый файл PHP вручную: это может нарушить работу расширений, PHP-FPM и сайтов.
Если PHP установлен из репозитория операционной системы или репозитория поставщика, проверьте наличие обновлённых пакетов и установите исправление штатным менеджером пакетов.
Например, в системах на базе AlmaLinux, Rocky Linux или RHEL сначала можно проверить доступные обновления:
dnf check-update
Для Debian и Ubuntu используется другой пакетный менеджер:
apt update
apt list --upgradable
Это команды проверки, а не универсальная инструкция по обновлению PHP. Конкретный пакет и команда установки зависят от используемого репозитория и версии PHP. Если на сервере работает панель управления, например BrainyCP, сначала проверьте её штатные средства управления версиями PHP.
Для Windows используйте подходящую сборку PHP с официальной страницы загрузок либо обновите PHP средствами используемой среды разработки или панели управления.
Если вы используете Open Server Panel, перед заменой версии проверьте совместимость проекта с новой сборкой, расширениями PHP и настройками веб-сервера. Не удаляйте старую рабочую конфигурацию до проверки сайта на новой версии.
После обновления необходимо убедиться, что веб-сервер действительно использует исправленную версию PHP.
Если сервер обслуживает несколько сайтов, проверьте каждый сайт и каждый используемый пул PHP-FPM. Обновление системного PHP не всегда означает, что все виртуальные хосты автоматически перешли на исправленную версию.
Команда PHP описывает несколько временных мер, которые могут уменьшить вероятность эксплуатации отдельных путей атаки. Однако эти меры не обеспечивают полной защиты. Они не должны становиться причиной откладывания обновления.
Ограничьте размер входящих запросов. В уведомлении PHP предлагаются следующие ориентиры для параметра post_max_size:
Значения необходимо выбирать с учётом реальных потребностей приложения. Если сайт принимает большие изображения, архивы или документы, слишком низкий лимит может нарушить его работу.
Параметр upload_max_filesize рекомендуется держать ниже post_max_size. При этом нужно учитывать ограничения веб-сервера и прокси, если они используются.
Дополнительно рекомендуется ограничивать размер декодированного запроса, количество полей формы, частей multipart-запроса, заголовков и глубину вложенности. Такие ограничения должны работать и для запросов, в которых отсутствует корректный заголовок Content-Length.
В официальном уведомлении также предлагается установить memory_limit=-1 на уровне, который приложение не может переопределить, например через php_admin_value в конфигурации пула PHP-FPM или Apache. Это устраняет один из контролируемых сценариев исчерпания памяти, но не исключает сбой при реальной нехватке памяти.
Внимание: memory_limit=-1 отключает ограничение памяти PHP. Это не универсальная настройка безопасности: она может увеличить риск чрезмерного потребления ресурсов и отказа в обслуживании. Не применяйте её без оценки нагрузки, доступной памяти и последствий для всех сайтов на сервере. Предпочтительнее как можно скорее установить исправленную версию PHP.
Для ограничения последствий исчерпания памяти в уведомлении также упоминаются контейнеры и механизмы cgroup. Такая изоляция должна быть настроена специалистом с учётом особенностей системы.
Для уменьшения риска эксплуатации второго сценария PHP рекомендует отключить отслеживание прогресса загрузки файлов через сессии:
session.upload_progress.enabled = 0
Настройку следует применять на раннем этапе обработки запроса — например, в php.ini, конфигурации пула PHP-FPM или веб-сервера. После изменения необходимо перезапустить соответствующие рабочие процессы PHP.
В PHP 8.5 также рекомендуется отключить формирование обратных трассировок для фатальных ошибок:
fatal_error_backtraces = 0
Эта мера применима к PHP 8.5 и блокирует только описанный в уведомлении путь атаки, связанный с обратной трассировкой. Она не устраняет все возможные сценарии эксплуатации.
Также необходимо проверить устаревшие или некорректные настройки, которые применяются к каждому запросу и могут формировать диагностические сообщения до завершения инициализации. Простое отключение вывода ошибок через error_reporting, display_errors или оператор @ не устраняет соответствующую проблему.
Не рассчитывайте, что изменение параметров через ini_set() или файл .user.ini защитит от этого сценария: такие настройки могут применяться слишком поздно.
Если ваш сайт работает на NGCMS, необходимо проверить не только версию CMS, но и PHP, который обрабатывает запросы сайта. Исправление уязвимостей на уровне PHP не зависит от того, используется NGCMS, WordPress, другой движок или самописное приложение.
Если на одном сервере размещено несколько сайтов, важно проверить настройки каждого из них. Разные виртуальные хосты могут использовать различные версии PHP и независимые пулы PHP-FPM.
PHP 8.1 и более ранние ветки больше не получают обычные обновления безопасности непосредственно от проекта PHP. При этом некоторые дистрибутивы Linux и поставщики долгосрочной поддержки могут предоставлять исправления для старых версий в виде backport-патчей.
Если вы используете такую сборку, уточните у поставщика, включены ли исправления CVE-2026-109618 и CVE-2026-109619. Сам по себе старый номер версии не позволяет определить, установлен ли патч от поставщика.
Команда PHP также опубликовала минимальные изменения исходного кода для веток PHP 7.4, 8.0 и 8.1. Они предназначены прежде всего для тех, кто самостоятельно собирает PHP из исходников или не имеет доступа к поставщику долгосрочной поддержки.
Если ваш проект зависит от старой версии PHP, следует составить план перехода на поддерживаемую ветку. Перед миграцией проверьте совместимость кода, расширений, библиотек и CMS, а также подготовьте резервную копию и возможность отката.
Две критические уязвимости PHP — CVE-2026-109618 и CVE-2026-109619 — связаны с обработкой памяти и внутреннего состояния запросов. При определённых условиях они могут привести к удалённому выполнению кода без авторизации.
В первую очередь необходимо обновить PHP до исправленной версии: 8.5.12, 8.4.27, 8.3.36 или 8.2.35 либо до более новой версии с соответствующими исправлениями.
Если обновление временно невозможно, можно применить описанные ограничения и настройки, но они уменьшают риск лишь отдельных сценариев и не делают уязвимую установку безопасной. Не откладывайте обновление и обязательно проверьте, какая версия PHP обслуживает ваши сайты.
