Действительно, новость от 21 октября 2026 года вызвала серьёзный резонанс. Я коротко объясню, в чём суть и почему владельцам сайтов стоит насторожиться. Речь идёт о двух критических уязвимостях в PHP — их объединили под названием PHP2Shell (идентификаторы CVE-2026-109618 и CVE-2026-109619). Разработчики PHP выпустили экстренные исправления в тот же день.
Почему это важно?
Главная причина в том, что PHP — один из самых распространённых языков для серверной части сайтов. На нём работают WordPress, «1С-Битрикс», Drupal, Joomla и множество других систем. Поэтому потенциально под угрозой оказались десятки, а то и сотни тысяч ресурсов.
Но дело не только в масштабе. Суть проблемы в том, где именно кроется уязвимость. Ошибки находятся не в конкретной CMS или плагине, а в самом интерпретаторе PHP. Это значит: даже если у вас идеально написанный код, обновлённая CMS и все плагины в порядке — сайт всё равно уязвим, пока на сервере стоит старая версия PHP. Обновление самой системы управления сайтом проблему не решит.
Чем опасны эти уязвимости?
Злоумышленник может отправить на сервер специально сформированный запрос — и добиться удалённого выполнения кода без какой-либо аутентификации. С такими правами атакующий получает серьёзные возможности:
- Кража конфиденциальных данных. Из памяти сервера можно извлечь пароли, токены сессий, ключи доступа, сертификаты.
- Изменение содержимого сайта. Подмена страниц, форм (например, формы оплаты), внедрение фишинговых ссылок или вредоносных файлов.
- Проникновение в инфраструктуру. Через скомпрометированный сервер атакующий может получить доступ к другим системам организации, внутренней сети, а в дальнейшем — развернуть программы-вымогатели.
Что ещё усугубило ситуацию?
- Скорость распространения угрозы. Как только информация об уязвимостях стала публичной, специалисты (например, из Cloudflare) зафиксировали первые попытки эксплуатации.
- Особенности некоторых конфигураций. Особенно рискованной считалась настройка с модулем
mod_phpдля Apache: для неё показали эксплойт, который срабатывает ещё до запуска самого кода приложения.
Что делать?
Основная и самая надёжная мера — обновить PHP до версии, где эти дыры закрыты. Разработчики выпустили исправления для нескольких веток: 8.5.12, 8.4.27, 8.3.36, 8.2.35.
При этом есть нюанс: иногда обновление на новом сервере может выявить проблемы совместимости с кодом сайта или сторонними компонентами. Поэтому перед обновлением имеет смысл провести тестирование.
Если оперативно обновить сервер не получается, в качестве временной меры можно рассмотреть ограничение внешнего доступа к сайту вплоть до полного отключения. Также разработчики PHP давали рекомендации по дополнительным настройкам (например, отключить session.upload_progress, ограничить размер запросов), но важно понимать: эти меры лишь снижают риск отдельных сценариев, но не закрывают уязвимости полностью.
После установки исправлений советую проверить журналы запросов и логи — это поможет убедиться, что злоумышленники не успели внедрить вредоносный код.
В общем, ситуация серьёзная, но решаемая. Главное — не игнорировать обновление PHP. Если при проверке версии или в процессе обновления возникнут сложности, имеет смысл обратиться к системному администратору или специалисту по безопасности.