Уязвимость в PHP 2026: как проверить и исправить уязвимые веб-сервисы

Правильно оценить сигнал тревоги

Утверждение о том, что уязвимость в PHP может затронуть „половину Интернета“, является преувеличенным рекламным ходом, но не подтвержденным фактом. Нет никаких доказательств того, что половина всех интернет-сервисов уязвима или уже скомпрометирована. Тем не менее, реальный риск остаётся значительным, поскольку PHP используется в качестве среды выполнения на многих веб-сайтах, в интернет-магазинах, API и административных интерфейсах.

Решающим фактором является не то, использует ли веб-сайт PHP, а то, какая версия PHP обрабатывает его веб-запросы. Обновления безопасности от 21 октября 2026 года в принципе затрагивают незапатченные установки поддерживаемых ветвей, если они обрабатывают запросы через веб-сервис. Поэтому локальную версию PHP, используемую для задач разработки, следует оценивать иначе, чем доступный извне клиентский портал.

Die Присутствие в Интернете в значительной степени определяет степень срочности. Общедоступный интернет-магазин с формами и возможностью загрузки файлов предоставляет больше потенциальных точек взаимодействия, чем закрытый внутренний сервис. Однако даже внутренний сервис не является автоматически безопасным: доступ через VPN, взломанные учетные записи или другие системы в сети могут сделать его доступным. Поэтому охват сам по себе не заменяет техническую оценку рисков.

Не менее важны режим работы и Стойка для ремонта велосипедов. PHP может работать, например, через PHP-FPM, в качестве модуля Apache, через php-cgi или встроенным в какой-либо продукт. При этом несколько доменов на одном сервере могут иметь разные версии и способы обновления. Давать общее заверение в безопасности всех сайтов на PHP было бы столь же неправильно, как и предполагать, что каждая установка сразу же подвергается риску атаки.

Что технически позволяют сделать уязвимости PHP

A Удаленное выполнение кода (RCE) означает, что при определённых условиях злоумышленник может выполнить код на удалённой системе. Согласно сообщению о безопасности, для этих уязвимостей PHP не требуется предварительная авторизация. Код сначала будет выполняться с правами веб-процесса, а не автоматически с неограниченными правами администратора. Поэтому возможные последствия в значительной степени зависят от прав доступа к файлам, учетных данных и архитектуры сервера.

CVE-2026-109618 касается путей возникновения ошибок при Нехватка памяти. Если PHP прерывает запрос из-за нехватки памяти, внутренние структуры данных могут остаться неполными. Если такие структуры будут использоваться при очистке запроса, это может привести к повреждению памяти. В официальном описании в качестве значимых технических контекстов в частности упоминаются многочастные запросы, загрузка файлов и потребление памяти при разборе вложенных вводных данных.

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

• Под угрозой могут оказаться веб-запросы, обрабатываемые через PHP-FPM, Apache с модулем mod_php, php-cgi, FrankenPHP и LiteSpeed.
• Ошибки возникают в среде выполнения PHP, а не в первую очередь в WordPress, Joomla, Shopware, шаблонах или отдельных плагинах.
• CMS и фреймворки влияют на доступные функции, такие как загрузка файлов, но не заменяют обновление интерпретатора.

Почему не каждая установка подвергается одинаковой опасности

Существует ряд факторов, определяющих, подвергается ли сервис реальной угрозе. Приоритетными являются незапатченная среда выполнения PHP и доступный веб-сервис. Затем следуют режим работы, повторно используемые процессы, функции для загрузки файлов или сложные формы, а также права учетной записи веб-процесса. Сервис с широкими правами на запись в веб-файлы или доступом к другим сервисам может иметь более серьёзные последствия, чем строго изолированный проект.

В Apache с mod_php В рамках проекта PHP особое внимание уделяется рискам: задокументированная атака может быть запущена ещё до выполнения собственно кода приложения. Даже тщательно поддерживаемая CMS не защищает от этой уязвимости во время выполнения. Это не означает, что PHP-FPM, php-cgi, FrankenPHP или LiteSpeed считаются безопасными; в случае отсутствия исправлений их также необходимо проверить в первоочередном порядке.

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

Брандмауэр, брандмауэр веб-приложений или жесткие ограничения на загрузку могут затруднить отдельные запросы и сузить поверхность атаки. Однако они не заменяют исправления, поскольку не устраняют ошибки в управлении памятью и состоянием в интерпретаторе. Даже безошибочная CMS зависит от безопасной среды выполнения. Поэтому крайне важно проверять и обновлять версию патчей PHP, который фактически обрабатывает веб-запросы.

Сравнить надежность выпусков исправлений и статус поддержки

В отношении этих двух уязвимостей в первую очередь учитывается уровень исправлений в используемой ветке PHP. Проект PHP указывает конкретные исправленные версии для поддерживаемых серий. Более ранние версии той же серии считаются уязвимыми; полным решением проблемы является обновление до указанной или более поздней версии этой ветки.

A Обновление патча остаётся в пределах одной ветки разработки, например, с версии 8.3.35 до 8.3.36. Он предназначен для установки исправлений безопасности и имеет более узкие рамки совместимости, чем переход с версии 8.2 на 8.4. Последний представляет собой миграцию: для этого необходимо отдельно проверить зависимости, расширения, код приложения и, при необходимости, процесс развертывания.

PHP 8.2 по-прежнему можно использовать для устранения неотложных проблем, при условии, что установлена версия не ниже 8.2.35. Однако поддержка этой ветки заканчивается 31 декабря 2026 года. Поэтому не следует останавливаться на этом промежуточном обновлении: запланируйте переход на ветку с более длительным сроком поддержки после проверки совместимости приложения в подходящей среде.

При использовании PHP 8.1 и более ранних версий следует проявлять особую осторожность. Проект PHP не предоставляет для этого регулярных актуальных выпусков; минимальные бэкпорты исходного кода не равнозначны общедоступному и поддерживаемому пакету. Бэкпорт безопасности, задокументированный поставщиком операционной системы, может быть приемлемым, но требует подтверждения в уведомлении о безопасности или журнале изменений пакета. В случае его отсутствия необходим переход на новую версию, а не просто косметическое обновление версии.

Проверить фактическое время работы веб-сайта

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

php -v
php --ini

В выводе описывается только та команда, которая была запущена с помощью этой команды оболочки Среда выполнения CLI. В свою очередь, веб-сайт может работать на базе PHP-FPM, Apache с модулем mod_php, php-cgi или в контейнере. Эта среда выполнения веб-приложений может использовать другую версию PHP и другие файлы конфигурации, чем команда php -v на хосте. Для оценки безопасности определяющим является процесс, обрабатывающий реальные HTTP-запросы.

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

На серверах с PHP-FPM конфигурация службы, состав пакетов и документация по развертыванию составляют единое целое. В контейнерных средах необходимо дополнительно проверять фактически развернутый образ, а не только локальный манифест сборки. Решающим фактором является то, какая ревизия в запущенном под или контейнере принимает веб-запросы; обновлённый базовый образ не защищает уже запущенный экземпляр более старой версии.

Планирование маршрутов обновления в зависимости от режима работы

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

В случае виртуального хостинга провайдер должен предоставить безопасную версию с исправлениями для выбранной версии PHP; после этого оператор проверяет работу приложения. При использовании PHP-FPM или mod_php администрация, как правило, обновляет пакеты, а затем контролируемым образом перезапускает соответствующую службу. Простая перезагрузка без установки исправления не заменяет обновление.

Дистрибутивы Linux часто предоставляют исправления безопасности в виде Бэкпорт. В таком случае видимый номер версии пакета может отличаться от версий, указанных на сайте php.net, несмотря на то, что исправление в него включено. Поэтому не стоит сравнивать только строки типа „8.4.26“, а следует ознакомиться с уведомлением о безопасности и журналом изменений дистрибьютора. Проект PHP обращает внимание на то, что дистрибутивы и поставщики LTS могут получать исправления.

Контейнеры требуют отдельного процесса: необходимо собрать исправленный образ или получить его от поставщика, развернуть его и заменить старые экземпляры. В случае интерфейсов NAS, сетевых устройств или готовых веб-приложений исправление, напротив, входит в компетенцию производителя. Патч операционной системы хоста не всегда доходит до встроенного интерпретатора; поэтому инвентаризация и рекомендации производителя остаются незаменимыми.

Неотложные меры без ложного чувства безопасности

В день выпуска патча сначала составь полный перечень ресурсов: домены, API, интерфейсы администрирования, контейнеры и продукты, в которых может быть встроенный PHP. Для каждого сервиса запиши режим работы веб-сервера, соответствующий канал обновлений и фактически используемую среду выполнения PHP. После этого приоритет будет отдаваться каждому общедоступному или критически важному для бизнеса сервису, а не только тому серверу, у которого номер версии бросается в глаза.

Затем установите обновление безопасности, выпущенное хостинг-провайдером, дистрибьютором Linux, разработчиком образа или производителем продукта. Для поддерживаемых ветвей PHP обновление до версии с исправленным патчем является полным решением проблемы; WAF, правила загрузки или перезапуск веб-сервера не заменяют его. Спланируйте процесс таким образом, чтобы обновление пакетов, образов или продуктов было четко задокументировано и в случае проблем можно было отследить его историю.

После обновления необходимо все старые работники будут завершены и заменены процессами, которые, как подтверждено, загрузили исправленную среду выполнения. Используйте перезагрузку только в том случае, если конкретная система управления службами гарантирует эту полную замену; в противном случае требуется контролируемый перезапуск. Затем проверьте время запуска процессов, статус служб или внутренне определённую среду выполнения веб-приложения, а не просто полагайтесь на то, что замена произошла. В случае контейнеров разверните исправленный образ и удалите все старые экземпляры.

Затем проверьте основные пути взаимодействия с приложением, такие как вход в систему, формы, загрузка файлов, оформление заказа и API. Тесты показывают, работают ли приложение и расширения с установленными обновлениями; однако сами по себе они не подтверждают ни полную замену рабочих процессов, ни отсутствие предыдущего взлома. Эти моменты необходимо оценивать отдельно в ходе эксплуатационных и bezpečnostных проверок.

Если установка патча в краткосрочной перспективе невозможна, отдельные настройки могут ограничить известные пути атак, но не обеспечить полную безопасность. Отключение индикатора прогресса загрузки должно вступить в силу до начала анализа запроса. Заранее проверьте, нужен ли этот индикатор прогресса приложениям или интерфейсам, а затем перезапустите каждый соответствующий PHP-рабочий процесс. После этого убедитесь, что ни один старый процесс не продолжает работать с прежними настройками.

session.upload_progress.enabled = 0

Консервативные ограничения для данных POST и другие параметры, указанные в уведомлении о безопасности, также могут лишь частично уменьшить уязвимость. Поздно считываемые .user.ini-файлы или один ini_set() Внутри приложения этих мер недостаточно для данной настройки. Рассматривайте такие меры как временное снижение риска и продолжайте стремиться к обновлению безопасности.

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

После установки патча проверьте работу и наличие отклонений

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

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

Перезапуск необходим для обеспечения устойчивых процессов и Рабочий загрузить с обновленным кодом, но само по себе это не приводит к устранению уязвимости. Без установленного обновления уязвимость сохраняется. При высокой нагрузке окно технического обслуживания следует выбирать таким образом, чтобы запросы могли обрабатываться упорядоченно, а последствия перезапуска рабочего процесса оставались заметными.

То, насколько контролируемый перезапуск влияет на пропускную способность, зависит от количества и загрузки процессов PHP. При планировании полезно учитывать очереди, выполняемые задания и критические транзакции, а не завершать процессы бессистемно. Руководство Понимание PHP-рабочих процессов объясняет роль этих процессов при параллельных динамических запросах.

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

Уделять приоритетное внимание старым и скрытым установкам PHP

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

В случае старых веток следует чётко различать три случая. Релиз PHP, для которого предоставляется регулярная поддержка, получает обновления безопасности, публикуемые проектом PHP. Бэкпорт от дистрибьютора или поставщика может содержать исправление, несмотря на отличающийся видимый номер версии, но это должно быть подтверждено уведомлением о безопасности или журналом изменений данного поставщика. В то же время самостоятельное обслуживание исходного кода требует нести ответственность за сборку, тестирование и эксплуатацию; оно не является полноценной заменой официального канала обновлений.

PHP 8.1 и более старые ветки больше не получают регулярных релизов от разработчиков. Для PHP 8.2 доступен исправленный патч, однако поддержка этой ветки закончится в конце 2026 года. Воспользуйтесь доступным исправлением для решения неотложной проблемы, но при работе со старыми или заканчивающимися версиями дополнительно запланируйте переход на протестированную Миграция в ветвь с более длительным сроком поддержки.

1. В первую очередь обновите общедоступные сервисы с незапатченной средой выполнения PHP, особенно если они поддерживают загрузку файлов или административные функции.
2. Не следует сразу же после этого использовать Apache с mod_php для работы с критически важными для бизнеса интернет-магазинами, API или клиентскими порталами; в официальном уведомлении о безопасности особое внимание уделяется крайне серьезному риску, связанному с mod_php.
3. Регистрировать контейнеры, устройства и сторонние продукты на основе образов, инвентаризации и статуса производителя; отсутствие видимых пакетов PHP не является сигналом об отсутствии угроз.
4. Изолировать неподдерживаемые или не поддающиеся оперативному исправлению службы и ограничить доступ к ним, параллельно с этим обязательно запланировав их замену, обновление или миграцию.

Сегментация сети, обязательное использование VPN или ограничительные правила доступа могут дать дополнительное время в случаях, когда интерфейсы администрирования невозможно немедленно обновить. Однако они являются лишь Переходные меры, поскольку внутренние учетные записи пользователей, взломанные устройства и неправильно настроенные общие ресурсы по-прежнему могут создавать уязвимости для атак. Если для продукта не предлагается исправление или ветка PHP окончательно вышла из поддержки, надежным решением станет замена или миграция.