Уязвимость PHP: что нужно знать владельцу сайта
PHP2Shell — повод проверить, кто отвечает за обновление PHP на вашем сайте и как подтверждается результат. Установить исправление важно, но владельцу бизнеса также нужно понимать, сохранены ли данные, работают ли заявки и можно ли восстановить проект при сбое.
В этой статье разберём подтверждённые сведения об уязвимостях PHP, а затем предложим практический регламент обновления и обслуживания сайта. Технические сведения актуальны на 23 октября 2026 года. Порядок работ ниже — рекомендуемый чек-лист для обсуждения с вашей командой, а не отчёт о проверке конкретного сервера.
Если заниматься окружением некому, начните с технической поддержки сайта: задача должна включать диагностику, согласованный объём изменений и проверку результата.
Что такое PHP2Shell и почему уязвимость PHP требует внимания
PHP2Shell — общее название двух уязвимостей в ядре PHP: CVE-2026-109618 и CVE-2026-109619. Docker сообщает о риске удалённого выполнения кода и затронутых выпусках начиная с PHP 5.4, включая устаревшие ветки и уязвимые версии веток 8.2–8.5. Источник: Docker Security.
По данным PHP Foundation, первая проблема связана с повреждением памяти при исчерпании memory_limit. Для Apache с mod_php исследователи продемонстрировали выполнение кода до запуска приложения; для PHP-FPM подтверждены пути через код приложения. Вторая проблема связана с состоянием, которое сохраняет ссылку на освобождённую память между запросами одного worker. Подробности PHP Foundation.
Это основание проверить серверное окружение. Наличие уязвимой версии само по себе не доказывает, что конкретный сайт уже взломан.
Какие версии PHP содержат исправления
PHP Foundation сообщила о выпуске исправлений 21 октября 2026 года. Для поддерживаемых на дату сообщения веток опубликованы следующие версии:
| Ветка PHP | Выпуск с исправлениями |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
Источник: сообщение PHP Foundation о релизе безопасности.
Docker рекомендует установить указанные либо более новые выпуски соответствующих веток и сообщает об обновлении Docker Official Images и Docker Hardened Images. По позиции Docker, обновление является единственным полным способом устранения этих уязвимостей. Рекомендации Docker.
Не переносите эту таблицу в бессрочный регламент: при выполнении работ повторно сверяйте актуальный advisory и сведения поставщика пакета. Для старого проекта отдельно согласуйте путь перехода и проверку совместимости.
Как проверить, относится ли проблема к вашему сайту
Начните с описи окружения. Передайте администратору таблицу ниже и попросите заполнить её фактическими данными. Ответ «у нас свежий сервер» не заменяет сведения о сборке PHP и установленном исправлении.
| Что выяснить | Что попросить в ответ |
|---|---|
| Где исполняется PHP | Серверы, контейнеры и окружения |
| Как обслуживаются веб-запросы | Способ запуска и используемая сборка |
| Откуда устанавливается PHP | Поставщик пакета или базового образа |
| Установлено ли исправление | Версия пакета и ссылка на бюллетень поставщика |
| Кто выполняет обновление | Ответственный и согласованный план |
| Как проверят результат | Сценарии, критерии успеха и отчёт |
Для виртуального хостинга отправьте вопрос провайдеру: «Какая сборка PHP обслуживает мой домен и содержит ли она исправления CVE-2026-109618 и CVE-2026-109619? Пришлите подтверждение и укажите, нужны ли действия с моей стороны».
Если проект размещён на собственном VPS, поручите проверку ответственному за сервер. Если серверов несколько, попросите отдельную строку для каждого: общий ответ затрудняет приёмку работы.
План обновления PHP: от подготовки до приёмки
Предлагаемый порядок нужен, чтобы команда заранее договорилась о действиях и доказательствах результата. Его следует адаптировать к архитектуре сайта. OWASP рекомендует сначала проверять исправленную зависимость в тестовой среде и переносить обновление после успешных тестов. OWASP: управление уязвимыми зависимостями.
Зафиксируйте объём работ
Составьте список затронутых окружений. Запишите текущую сборку, целевую версию или пакет с исправлением и ответственного за каждый этап. Согласуйте, кто разрешает перенос на рабочий сайт и кому сообщают о проблеме.
Подготовьте восстановление
До изменений согласуйте состав копии: база данных, загруженные файлы, конфигурация и остальные необходимые проекту данные. Попросите показать результат пробного восстановления. Для этой части можно отдельно заказать резервное копирование и перенос проектов.
Проверьте обновление в тестовой среде
Составьте список пользовательских действий, повторите их до изменения и после него. Запишите исходный результат, чтобы сравнение не зависело от памяти исполнителя. Если проверка не проходит, зафиксируйте конкретный сбой и решение до переноса в рабочую среду.
Согласуйте перенос
Укажите время работ, ожидаемые ограничения для пользователей, порядок связи и условия остановки. Не объединяйте срочное исправление с необязательным редизайном или новой интеграцией: каждую дополнительную задачу лучше оценивать отдельно.
Примите результат по фактам
Запросите подтверждение установленной сборки на каждом затронутом окружении и результаты согласованных сценариев. В отчёте должны быть выполненные действия, оставшиеся ограничения и ответственные за дальнейшие работы.
Что проверить на сайте после обновления
Главная страница — только один пункт приёмки. Для интернет-магазина, корпоративного сайта и личного кабинета списки будут различаться. Возьмите за основу следующие сценарии и оставьте только применимые:
- отправка формы с подтверждением получения заявки;
- вход пользователя и восстановление доступа;
- поиск, фильтры, карточки и переходы по каталогу;
- создание тестового заказа;
- проверка платёжной интеграции в согласованном тестовом режиме;
- загрузка файлов разрешённых типов;
- обмен данными с CRM или другими подключёнными системами;
- выполнение фоновых задач;
- просмотр ошибок, появившихся во время проверок.
Для каждого сценария запишите ожидаемый результат, фактический результат и подтверждение. Например: «заявка создана в CRM, уведомление пришло ответственному, дубля нет». Такой формат помогает принять работу без расплывчатой формулировки «всё вроде открывается».
Если PHP работает в Docker
Сообщение об исправленных образах у поставщика — начало проверки вашей инфраструктуры. Попросите исполнителя зафиксировать используемый образ и подтвердить, что рабочее приложение переведено на сборку с исправлением.
Для приёмки Docker-окружения удобно запросить отдельный перечень: исходный образ, новая сборка, результат развёртывания и проверенные сценарии сайта. Не ограничивайтесь скриншотом из реестра образов: в отчёте нужна связь с конкретным рабочим окружением.
Если порядок развёртывания не описан, вынесите его настройку в отдельную задачу по деплою и инфраструктуре. До начала согласуйте, какие действия будут автоматизированы, как подтверждается успешный запуск и кто принимает решение при ошибке.
Что делать, если старый сайт не удаётся обновить
Попросите команду описать препятствие предметно: какая проверка не проходит, какой компонент несовместим и что нужно изменить. Фраза «старый сайт нельзя трогать» не помогает выбрать дальнейший шаг.
OWASP предлагает сначала подтвердить блокирующую несовместимость в тестовом окружении, документировать её и отдельно оценить поддерживаемые исправления для используемой ветки. Перенос исправления в старую версию требует проверки; изменение строки версии или скрытие предупреждения сканера не является устранением проблемы. Раздел о backport в рекомендациях OWASP.
Для обсуждения с подрядчиком разделите работу на два результата: меры на период устранения препятствия и постоянное решение. У каждого результата должны быть срок, ограничения и способ проверки. Не принимайте неопределённое обещание «закроем защитой» без описания применимости к конкретной уязвимости.
Что включить в регулярное обслуживание сайта
После срочного обновления предложите команде согласовать постоянный регламент. Для услуги поддержки и обслуживания сайтов полезно заранее определить не только число часов, но и состав проверяемого результата.
| Направление | Что предложить включить в регламент |
|---|---|
| Обновления | Проверка уведомлений поставщиков и список требующих действий компонентов |
| Резервные копии | Расписание, контроль выполнения и пробное восстановление |
| Работоспособность | Проверки важных пользовательских сценариев |
| Изменения | Тестовая среда, согласование переноса и журнал работ |
| Ответственность | Контакты, приоритеты обращений и порядок эскалации |
| Отчётность | Сделанное, подтверждения и открытые проблемы |
Это предлагаемый состав задания, а не обещание включить все работы в любой тариф. Объём сопровождения, время реакции и порядок аварийных обращений нужно согласовать отдельно.
Для владельца сайта полезен короткий ежемесячный отчёт: что обновили, что проверили, какие копии восстановили и какие решения требуются от бизнеса. Просите отмечать невыполненные пункты явно.
Как поставить задачу на обновление и поддержку сайта
В заявку можно включить следующий текст:
Нужно проверить применимость CVE-2026-109618 и CVE-2026-109619 к нашему PHP-окружению. Просим описать используемые сборки и источник пакетов, предложить план установки исправлений, подготовить восстановление, проверить согласованные сценарии и передать отчёт после работ. Отдельно укажите несовместимости, ограничения и задачи, которые требуют нашего решения.
Дополните заявку доменом, описанием размещения и списком критичных действий посетителя. Пароли и ключи передавайте через согласованный защищённый канал.
Для первичного обращения выберите техническую поддержку сайта. Если нужен постоянный контроль обновлений и работоспособности, обсудите регулярное сопровождение. В запросе сразу уточните, нужен ли разовый результат или дальнейшее обслуживание.
Частые вопросы об уязвимостях PHP и обслуживании сайта
Если сайт открывается, обновление можно отложить?
Доступность страницы не подтверждает наличие исправления. Основанием для решения должны быть сведения о сборке и применимости advisory. PHP Foundation призывает пользователей PHP обновиться в связи с этими уязвимостями. Сообщение PHP Foundation.
PHP2Shell означает, что сайт уже взломан?
Нет, из самого сообщения об уязвимости такой вывод не следует. Проверку версии и расследование возможного инцидента оформляйте как отдельные задачи с разными критериями результата.
Достаточно ли резервной копии?
В предлагаемом плане копия нужна для восстановления. Наличие исправления подтверждайте отдельно по установленной сборке. Не закрывайте задачу обновления только фактом создания архива.
Можно ли назвать стоимость до диагностики?
Попросите сначала определить объём: количество окружений, состояние копий, совместимость и перечень проверок. После этого согласуйте оценку конкретных работ. В этой статье универсальная стоимость не устанавливается.
Как понять, что работа завершена?
Примите отчёт по заранее согласованным критериям: исправленная сборка на нужных окружениях, результаты пользовательских сценариев, проверенное восстановление и перечень открытых ограничений. Если пункт не выполнен, он должен остаться в списке задач.
Источники и дата проверки
Материал подготовлен на основе записи с проверкой первоисточников 23 октября 2026 года:
- Docker Security: Security Update on PHP2Shell — затронутые ветки, исправленные версии и обновление образов.
- PHP Foundation: выпуск безопасности от 21 октября 2026 года — природа ошибок и подтверждённые условия эксплуатации.
- PHP: архив официальных объявлений за 2026 год — сообщения проекта.
- OWASP: Vulnerable Dependency Management — проверка обновлений и работа с несовместимостями.
