21 октября 2026 года проект PHP выпустил исправления двух критических уязвимостей, которые могут привести к удалённому выполнению кода без аутентификации. Исправленные версии: PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Официальная рекомендация однозначна: пользователям PHP следует немедленно обновить среду.
Если компания использует старое приложение на PHP, это не означает, что его необходимо сразу полностью переписать. Сначала нужно установить исправление среды. Затем тест совместимости покажет, может ли приложение работать без изменений, требуется ли обновление зависимостей, поэтапная модернизация или контролируемая переработка.
Переписывание кода приложения не устраняет уязвимость интерпретатора PHP. В то же время обновление PHP само по себе не гарантирует совместимость старого приложения с новой средой. Это две отдельные проблемы и два отдельных решения.
Источники проверены 23.10.2026. Перед изменениями проверьте актуальное сообщение проекта PHP и информацию поставщика операционной системы, хостинга или контейнерного образа.
Что именно сообщил проект PHP?
Сообщение от 21 октября касается CVE-2026-109618 и CVE-2026-109619. Проект PHP указывает, что риску подвержены установки, обслуживающие веб-запросы, в том числе PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Самый высокий риск описан для mod_php, где неаутентифицированный запрос может запустить атаку ещё до выполнения кода приложения.
Исправления входят в версии:
- PHP 8.5.12;
- PHP 8.4.27;
- PHP 8.3.36;
- PHP 8.2.35.
Это не четыре взаимозаменяемые целевые версии. Обновляйтесь внутри ветки, используемой средой, или следуйте пути, который поддерживает поставщик операционной системы, хостинга либо контейнерного образа. Если поставщик выпускает собственный пакет с перенесённым исправлением, подтвердите его статус в сообщении поставщика о безопасности. Одной строки версии в таком случае недостаточно.
PHP 8.1 и более старые ветки уже не получают обновлений от проекта PHP. PHP 8.2 сейчас получает только исправления критических проблем безопасности, и эта поддержка закончится 31 декабря 2026 года. Поэтому переход на более новую ветку может стать отдельным проектом совместимости даже после установки срочного исправления.
Дополнительная информация от 23 октября 2026 года
23 октября проект PHP описал маловероятный путь удалённого выполнения кода, связанный с session.upload_progress. До следующего планового выпуска с исправлениями было рекомендовано установить session.upload_progress.enabled=0. Проблема возникает только при необычном сочетании конфигурации и поведения приложения. Согласно сообщению, приложения, которые никогда не меняют обработчик сериализации сессии во время выполнения, могут оставить эту функцию включённой.
Это временная рекомендация, зависящая от конфигурации. Она не заменяет обновление PHP, а изменение настройки без проверки может повлиять на функции, использующие отображение прогресса загрузки файлов. Сначала нужно определить, относится ли настройка к приложению, и проверить последствия изменения.
Первый шаг: проверьте среду, обслуживающую сайт
Результат php -v в терминале может описывать версию командной строки, а не PHP, который обрабатывает веб-запросы. Один сервер может использовать разные версии или конфигурации для сайта, заданий по расписанию и очередей.
До выбора объёма работ установите:
- какая версия PHP действительно обслуживает публичное приложение;
- какой SAPI или способ подключения к серверу используется, например FPM, mod_php или CGI;
- откуда поступает конфигурация и кто отвечает за её изменение;
- содержит ли пакет операционной системы или контейнерный образ перенесённое исправление;
- какую версию PHP используют задания по расписанию, очереди, импорты и служебные скрипты;
- есть ли восстанавливаемая резервная копия и путь возврата;
- какие бизнес-процессы необходимо проверить сразу после изменения.
Если приложение уже могло быть скомпрометировано, обновление не заменяет расследование инцидента. Сохраните относящиеся к нему данные и согласуйте следующие шаги с ответственным за инфраструктуру или реагирование на инциденты. Эта статья не заменяет такую работу.
Срочное обновление и модернизация приложения являются разными задачами
Срочная цель состоит в переходе на выпуск PHP с исправлением или на пакет, который ответственный поставщик подтвердил как исправленный. Модернизация приложения начинается тогда, когда код, фреймворк, библиотеки или процесс развёртывания блокируют обновление либо делают его результат непредсказуемым.
Безопасная последовательность обычно выглядит так:
- определить среду, которая действительно обслуживает веб-запросы;
- применить или запланировать исправление поставщика, не ожидая полной переработки;
- подготовить резервную копию и проверить возможность восстановления;
- запустить приложение в тестовой среде на исправленной версии PHP;
- проверить критические сценарии, интеграции, очереди, задания по расписанию и операции с файлами;
- зафиксировать несовместимости и отделить срочные ошибки от последующих улучшений;
- выбрать минимальный обоснованный этап и определить критерии его приёмки;
- выполнить контролируемое развёртывание, перезапустить необходимые процессы и проверить фактическую версию и основные сценарии.
Не оставляйте уязвимый публичный экземпляр доступным только для проверки работы старого приложения. Если обеспечение совместимости занимает больше времени, риск нужно отдельно ограничить на уровне инфраструктуры и эксплуатации.
Четыре возможных направления после защиты среды
| Направление | Когда его может быть достаточно | Что нужно проверить |
|---|---|---|
| Обновление среды и тест совместимости | Приложение и его зависимости поддерживают исправленную и сопровождаемую версию PHP. | Резервную копию, тестовую среду, критические сценарии, фоновые задания, интеграции и возврат. |
| Обновление фреймворка и зависимостей | Бизнес-правила сохраняют ценность, но старые пакеты блокируют новую среду. | Поддерживаемый путь обновления, заброшенные пакеты, изменения между версиями, миграции данных и собственные модули. |
| Поэтапная модернизация | Часть приложения можно сохранить, а проблемы сосредоточены в отдельных модулях или слоях. | Границы модулей, потоки данных, порядок замены и период совместной работы старой и новой частей. |
| Контролируемая переработка | Систему нельзя безопасно запустить в поддерживаемой среде или её архитектура не позволяет предсказуемо развивать продукт. | Бизнес-правила, данные, интеграции, объём первой версии, переключение и путь возврата. |
Одной версии PHP недостаточно для выбора направления. Одна и та же старая версия может означать простое обновление в одном приложении и большой проект совместимости в другом.
Когда достаточно обновить только среду?
Самый простой вариант возможен, если приложение использует поддерживаемые версии фреймворка и библиотек, развёртывание воспроизводимо, а основные процессы можно проверить до изменения. Тогда объём может ограничиться подготовкой копии, тестом на исправленной версии, обновлением среды и контролем после развёртывания.
Даже в этом варианте нельзя забывать о фоновых заданиях. Расписание, очереди, импорты и скрипты могут использовать конфигурацию, отличную от веб-приложения.
Когда нужно обновлять фреймворк или библиотеки?
Старое приложение может содержать синтаксис, удалённый из новых версий PHP, неподдерживаемый фреймворк или пакеты, от которых отказались авторы. Проблемой также бывают собственные модули и расширения, которые нельзя просто заменить.
Сначала нужно определить минимальный безопасный объём работ по совместимости. Иногда достаточно обновить несколько зависимостей и ограниченный участок кода. В других случаях последовательные версии фреймворка требуют поэтапной миграции. По одному сообщению об ошибке нельзя дать надёжный ответ.
Когда модернизировать поэтапно?
Поэтапная модернизация оправдана, если приложение всё ещё поддерживает важные процессы, содержит нужные данные и имеет части, способные продолжать работу. Вместо одновременного воссоздания всей системы можно сначала защитить критическое поведение тестами, стабилизировать развёртывание и последовательно заменить самые проблемные элементы.
У каждого этапа должны быть собственный результат, критерии приёмки и путь возврата. Тогда дальнейшие решения опираются на работающую систему, а не только на предположения.
Более широкие критерии описаны в статье Модернизация существующей системы или разработка с нуля.
Когда переработка может быть обоснована?
Переработку стоит рассмотреть, если ключевые зависимости не поддерживаются, приложение нельзя воспроизвести в контролируемой среде, небольшие изменения вызывают непредсказуемые ошибки или архитектура не позволяет отделить нужные компании процессы.
Это по-прежнему не означает одного большого переключения. Сначала можно воссоздать один процесс, сравнить данные и только затем расширить объём. Разработка с нуля без изучения бизнес-правил часто переносит старые проблемы в новый код или удаляет поведение, о котором никто не вспомнил при подготовке требований.
Два примера, два разных пути
В проекте OBIBOOK мы сначала исправили неработающий импорт CSV и работу на мобильных устройствах. Только после изучения процесса был полностью переработан каталог книг. Исправление и переработка были отдельными этапами.
В случае Sprawdzeni.pl предыдущим приложением было сложно пользоваться, и оно регулярно выдавало ошибки. Его состояние говорило в пользу разработки новой системы с сохранением и развитием визуальной концепции владельца.
Ни один из этих проектов не начинался из-за уязвимостей, описанных в этой статье. Они лишь показывают, что после оценки существующей системы правильным решением могут быть ремонт, поэтапная работа или переработка. Единого ответа для всех старых приложений нет.
Что подготовить для первой оценки?
Необязательно знать все технические подробности. Полезны будут:
- адрес и краткое описание роли приложения в компании;
- сообщение хостинга или администратора без данных доступа;
- версия PHP и способ его запуска, если они известны;
- название и версия фреймворка или CMS, если они известны;
- источник кода и информация о том, соответствует ли он рабочей версии;
- сведения о резервных копиях, тестовой среде и способе развёртывания;
- список процессов, которые нужно проверить после обновления;
- список интеграций и фоновых заданий;
- ожидаемый результат первого этапа.
Не отправляйте через форму пароли, API-ключи, копии базы данных или данные клиентов. Безопасный способ передачи материалов мы согласуем после определения объёма.
Сначала можно воспользоваться чек-листом передачи приложения. Он помогает упорядочить доступные сведения, но не заменяет техническую оценку.
Что нельзя обещать до проверки приложения?
До анализа конкретной системы нельзя ответственно гарантировать, что:
- обновление PHP не потребует изменений в коде;
- у всех зависимостей есть безопасная и совместимая замена;
- резервная копия позволит восстановить систему за необходимое время;
- все части приложения следует сохранить;
- переработка будет дешевле модернизации;
- одно исправление PHP решит все проблемы безопасности приложения.
Если требуется более широкая оценка рисков, ознакомьтесь с аудитом безопасности веб-приложения. Если после стабилизации системе нужна постоянная поддержка, можно отдельно согласовать сопровождение приложения или магазина.
Определим, что требуется вашему приложению
Напишите, для чего компания использует систему, какое сообщение стало причиной изменений и что нельзя потерять при обновлении. Если известны версия PHP, фреймворк, способ запуска и состояние доступа к коду и хостингу, укажите их. Отсутствие этих сведений не мешает первому разговору.
Не отправляйте секреты или данные клиентов. На первом этапе нам нужны описание ситуации и ожидаемый результат.
Определим, что требуется вашему приложению или сначала упорядочьте материалы с помощью чек-листа.
Источники
Источники проверены 23.10.2026:
- PHP: Security advisory - Critical remote code execution vulnerabilities, update now
- PHP: Informational advisory - Session upload progress
- PHP: Supported Versions
- PHP security advisory: CVE-2026-109618, RCE via OOM corruption
- PHP security advisory: CVE-2026-109619, RCE via stale global state
- PHP Manual: php_sapi_name
- PHP Manual: phpversion