Критические уязвимости в PHP 2026: как обновить и защитить сайт

Что случилось

В PHP нашли две критические уязвимости удалённого выполнения кода — CVE-2026-109618 и CVE-2026-109619. Они затрагивают управление памятью и обработку ошибок, то есть части, которые участвуют практически в каждом запросе. Ошибки скрывались в кодовой базе больше десяти лет.

Патч вышел 21 октября. До его установки организации по всему миру — госорганы, больницы, вузы — временно отключали сайты: в Великобритании, Франции, Нидерландах и других странах. В России НКЦКИ при ФСБ рекомендовал объектам критической инфраструктуры ограничить доступ к сайтам, если обновиться быстро не получается.

Почему это масштабно

PHP — серверный язык, на котором работает около 70% сайтов мира. По данным W3Techs, в мире этот показатель — 69,3%, а среди русскоязычных сайтов — 90,8%. На PHP построены WordPress, «Википедия», Slack, значительная часть Facebook и, что важно для России, «1С-Битрикс».

Уязвимости затронули все версии PHP, начиная с 5.x. Это значит, что под угрозой оказались не только «старые» сайты, но и проекты, которые годами не обновляли runtime.

Главная ловушка: обновить CMS недостаточно

Многие владельцы сайтов на WordPress или «1С-Битрикс» решили, что достаточно обновить CMS. Это не так.

Проблема находится непосредственно в PHP, а не в конкретной CMS. Обновление WordPress, Drupal, Joomla или другой системы не исправляет уязвимость в самом языке. Пока сервер работает на уязвимой версии PHP, сайт остаётся под угрозой.

Именно поэтому эксперты рекомендовали обновлять именно PHP — до версий 8.5.12, 8.4.27, 8.3.36 или 8.2.35 — и только потом перезапускать веб-сервер и фоновые обработчики, чтобы в памяти не остался старый код.

Ещё одна деталь: уязвимости нашли с помощью ИИ

Обе уязвимости обнаружили с помощью ИИ-инструментов: модели OpenAI (GPT-5.6 Sol) и Google (Gemini 4 Argon, Wiz Atlas). Без ИИ найти их было бы крайне сложно — они требуют «исключительно сложной цепочки шагов».

Но есть и обратная сторона: как только патч вышел, ИИ-инструменты могут помочь злоумышленникам быстрее адаптировать эксплойты под разные версии PHP и конфигурации. Amazon зафиксировала попытку эксплуатации ещё 17 октября — за четыре дня до публичного раскрытия.

Чем отличается стек на React + FastAPI

Теперь к главному: почему мы в Webzella строим проекты на React + FastAPI, и как это связано с такими новостями.

1. Меньше «общей» инфраструктуры — меньше поверхностей атаки.

PHP-сайт обычно означает связку: веб-сервер (Apache/Nginx) + PHP-FPM + CMS + плагины. Уязвимость в любой части этой цепочки может затронуть весь сайт. В стеке React + FastAPI цепочка другая: React — это статика на CDN, FastAPI — Python-бэкенд. Нет PHP-интерпретатора, нет CMS с десятками плагинов, нет общей для миллионов сайтов кодовой базы, где одна ошибка может затронуть всех.

2. Обновления контролируются, а не «приходят от вендора».

Когда уязвимость в PHP, владелец WordPress-сайта зависит от цепочки: PHP Foundation выпустила патч → хостинг обновил PHP → вы обновили CMS. На каждом шаге возможна задержка. В кастомном стеке обновления зависимостей (Python-пакеты, Node-модули) — это часть вашего CI/CD. Вы видите, что и когда обновляется, и можете откатить, если что-то пошло не так.

3. Уязвимость в FastAPI или React — это не «уязвимость в 70% интернета».

FastAPI и React — популярные инструменты, но они не являются единой монолитной кодовой базой, на которой работают миллионы сайтов с одинаковой конфигурацией. Уязвимость в конкретной библиотеке затрагивает проекты, которые её используют. Это всё ещё серьёзно, но масштаб несравним с «багом в PHP, который затрагивает каждый запрос на каждом PHP-сайте».

4. Архитектура важнее языка.

Мы не утверждаем, что React + FastAPI «неуязвимы». Любой код можно взломать. Но безопасность — это не «выбрать язык, в котором нет багов». Это контроль над тем, что работает на сервере, как обновляются зависимости и кто отвечает за реакцию на инциденты. В кастомном стеке этот контроль у вас и вашей команды. В «коробке» — у вендора и хостинга.

Что делать, если у вас сайт на PHP

Если ваш сайт работает на PHP (особенно на старой версии или самописный), вот что стоит сделать сейчас:

• Обновите PHP до пропатченной версии. Это первое и главное.
• Перезапустите веб-сервер и PHP-FPM, чтобы в памяти не остался старый код.
• Проверьте сервер на признаки взлома, если он был доступен из интернета до выхода патча. Смените пароли, ключи и токены.
• Если обновиться нельзя — временно ограничьте доступ или используйте WAF.

Но если вы задумываетесь о новом проекте и хотите, чтобы безопасность была частью архитектуры, а не реакцией на новости — посмотрите в сторону кастомного стека.

Вывод

PHP2Shell — это не «PHP плохой». Это напоминание о том, что массовые технологии создают массовые риски. 70% сайтов мира работают на PHP, и когда в нём находят уязвимость, она затрагивает миллионы проектов одновременно.

Мы строим на React + FastAPI не потому, что это модно. А потому, что мы хотим контролировать, что работает на сервере, как обновляются зависимости и кто отвечает, когда что-то идёт не так. Если для вас это важно — напишите нам. Разберём вашу задачу и покажем, как это работает на практике.