Критическая уязвимость PHP: в безопасности ли ваш сайт и что спросить у хостера

Что произошло 20–21 октября 2026 года

20 октября 2026 года команда PHP заранее предупредила, что на следующий день выйдет внеочередной выпуск безопасности, закрывающий две критические уязвимости. 21 октября вышли версии PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. В официальном анонсе на php.net сказано прямо: эти версии исправляют две критические уязвимости, которые могут позволить удаленное выполнение кода без аутентификации, и всем пользователям PHP настоятельно рекомендуют обновиться немедленно.

В англоязычных источниках эта пара уязвимостей получила неофициальное название PHP2Shell. Обе имеют оценку 9.2 по шкале CVSS v4.0, то есть относятся к самой опасной категории.

Две уязвимости простыми словами

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

Для владельца сайта технические подробности не так важны. Важно другое: атаке не нужны ни логин, ни пароль, ни уязвимый плагин. Достаточно, чтобы на сервере работала неисправленная версия PHP.

Дополнительная рекомендация от 23 октября

23 октября на php.net появилось еще одно сообщение: до следующего планового выпуска рекомендуется отключить настройку session.upload_progress. Оно касается связанной проблемы CVE-2026-115560, которая проявляется только в особых случаях. Это настройка сервера, поэтому ее тоже стоит упомянуть в письме хостеру.

Почему это не уязвимость WordPress и почему обновление плагинов не поможет

Большинство новостей о безопасности сайтов касается конкретной CMS или плагина: «обновите плагин X до версии Y». Привычка нажать «Обновить все» в админке действительно защищает от многих угроз. Но в этот раз проблема уровнем ниже. PHP — это язык, на котором написаны WordPress, OpenCart, Drupal, Joomla, CodeIgniter, Laravel и тысячи самописных сайтов. Он установлен на сервере хостинга, а не внутри вашего сайта.

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

Отсюда практический вывод: ответственность за исправление лежит на том, кто управляет сервером. На обычном хостинге это хостер. На VPS или собственном сервере — вы или ваш администратор. Если вы не знаете, кто именно, это уже сигнал, что за техническим состоянием сайта никто не следит. Для таких случаев существует регулярное техническое обслуживание сайта, когда обновлениями сервера и CMS занимается ответственный человек.

Какие сайты под угрозой

По данным php.net, под угрозой каждая инсталляция PHP, которая обслуживает веб-запросы. Речь о всех распространенных способах запуска PHP на сервере: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP, LiteSpeed. Самый высокий риск команда PHP видит именно для mod_php. PHP-FPM, который часто используют на современных хостингах, менее уязвим, но тоже не безопасен.

Ситуация по версиям PHP

• PHP 8.2, 8.3, 8.4, 8.5 — есть официальные исправления: 8.2.35, 8.3.36, 8.4.27, 8.5.12 или более новые в той же ветке. Нужно только, чтобы хостер их установил.
• PHP 7.4, 8.0, 8.1 — официальных выпусков не будет, потому что эти ветки уже не поддерживаются. Команда PHP опубликовала только минимальные исправления в виде исходного кода для тех, кто сам собирает PHP. Часть дистрибутивов Linux и поставщиков платной долгосрочной поддержки выпускают собственные патчи, так что все зависит от хостера.
• PHP 7.3 и более старые, включая 5.6 — исправлений нет вообще. Такой сайт можно защитить только переходом на более новую версию PHP.

Отдельно стоит помнить о дате 31 декабря 2026 года: тогда заканчивается поддержка PHP 8.2. Если ваш сайт сейчас на 8.2, после обновления до 8.2.35 он в безопасности, но уже до конца года стоит планировать переход на 8.3 или новее.

Атакуют ли сайты уже сейчас

Здесь источники расходятся, и об этом честно стоит сказать. По данным хостинг-провайдера MassiveGrid, уже днем 21 октября Cloudflare сообщил о первых попытках атак и включил экстренные правила своего файрвола для всех тарифов. Исследовательские компании watchTowr и Huntress воспроизвели одну из уязвимостей. В сети распространяются коды эксплойтов, часть из них — из непроверенных источников.

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

Как узнать версию PHP своего сайта

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

Способ 1. В админке WordPress

Откройте Инструменты → Здоровье сайта → Информация → Сервер. В строке «Версия PHP» увидите номер, например 8.3.36. Если WordPress показывает предупреждение об устаревшей версии PHP на вкладке «Состояние», это уже повод действовать.

Способ 2. В панели хостинга

В cPanel версию видно в разделах «Select PHP Version» или «MultiPHP Manager», в других панелях — в настройках домена. Там же часто можно переключить сайт на более новую ветку PHP. Но делайте это только после проверки совместимости сайта, об этом ниже.

Способ 3. Спросить хостера или администратора

Самый надежный вариант, потому что номер версии не всегда рассказывает всю историю. На серверах с пакетами дистрибутивов Linux патчи часто вносят без изменения номера: например, исправленный PHP в Ubuntu 24.04 может показывать 8.3.6. Поэтому ответ «у вас 8.3» еще не означает «вы защищены». Защищенность подтверждает только тот, кто устанавливал обновления.

Что спросить у хостера: готовое письмо

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

Вопросы, которые стоит задать

• Установлены ли на сервере, где работает мой сайт, исправления уязвимостей PHP CVE-2026-109618 и CVE-2026-109619?
• Какая версия PHP используется для моего сайта и это ли исправленная сборка (8.2.35, 8.3.36, 8.4.27, 8.5.12 или патч дистрибутива)?
• Обновлены ли все версии PHP, доступные на сервере, а не только основная? На одном сервере часто стоит несколько сборок PHP.
• Перезапущены ли процессы PHP после обновления?
• Отключена ли session.upload_progress, как рекомендует php.net от 23 октября?
• Если мой сайт на PHP 7.4, 8.0 или 8.1 — есть ли для этой версии патч и кто его поддерживает?
• Используется ли файрвол (WAF), который блокирует известные шаблоны этой атаки?

Если хостер отвечает размыто («у нас все безопасно») или не понимает, о чем речь, — это весомый повод подумать о переезде на другой хостинг. Ответ «ваш сайт на PHP 5.6, обновлений нет» означает, что проблема уже не в хостинге, а в самом сайте.

Если у вас VPS или собственный сервер

На VPS никто не обновит PHP за вас. Порядок действий, который рекомендуют php.net и хостинг-провайдеры, выглядит так.

• Найдите все инсталляции PHP. Пакет дистрибутива, сборки панелей управления, альтернативные версии PHP, тестовые и забытые сайты — каждую нужно обновить.
• Начните с mod_php, потом PHP-FPM, FrankenPHP и LiteSpeed.
• Перезапустите процессы. Для mod_php нужен полный перезапуск Apache, а не мягкая перезагрузка конфигурации. Для PHP-FPM — перезапуск всех пулов.
• Для пакетов дистрибутива проверяйте не номер версии, а журнал изменений пакета: в нем должны быть номера CVE.
• Если обновиться прямо сейчас невозможно, php.net советует временные меры: отключить session.upload_progress.enabled в php.ini или конфигурации пула (не через ini_set() и не через .user.ini) и уменьшить post_max_size, если большие загрузки не нужны. Но команда PHP отдельно подчеркивает: эти меры лишь сужают пути атаки и не делают сервер безопасным. Полное решение одно — обновление.

Старый сайт на PHP 5.6 или 7.x: что делать

Самая сложная ситуация у владельцев сайтов, которые сделали 6–10 лет назад и с тех пор почти не трогали. Такие сайты часто работают на PHP 5.6 или 7.x просто потому, что на более новой версии «все ломается». И в этот раз исправлений для них нет совсем.

Почему сайт нельзя просто переключить на PHP 8.3 в панели хостинга? Между ветками PHP менялись функции и правила языка. Старые темы, плагины и самописный код могут выдать ошибку, белый экран или тихо сломать корзину, формы или оплату. Поэтому переход на новую версию PHP — это техническая работа: обновить CMS и модули, заменить заброшенные плагины, исправить несовместимый код, протестировать на копии сайта и только потом переключить основной.

Три сценария для старого сайта

• Сайт в целом устраивает, проблема только в коде. Тогда оптимальное решение — доработка сайта под современную версию PHP: обновление ядра, модулей и исправление несовместимых мест.
• Сайт устарел и внешне, и внутри. Если дизайн не адаптирован под телефоны, CMS давно не обновляется, а исправления будут стоить как половина нового сайта, разумнее сделать редизайн старого сайта на актуальной платформе.
• Сайт давно не приносит пользы. Бывает, что старый сайт никто не посещает, а он висит на хостинге и только создает риски. Тогда его стоит либо отключить, либо заменить простым новым сайтом.

В любом случае оставлять сайт на PHP 5.6 или 7.3 после этой новости — значит сознательно держать открытой дверь. Взломанный сайт может рассылать спам, показывать посетителям вредоносный код, попасть в черные списки браузеров и потерять позиции в Google.

Как проверить, не взломали ли сайт

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

• Новые или измененные PHP-файлы. Файлы, измененные после 20 октября, которые вы не трогали, особенно в папках загрузок.
• Новые пользователи. Неизвестные администраторы или редакторы в CMS.
• Задания по расписанию (cron). Незнакомые задания на сервере или в планировщике CMS.
• Странное поведение сайта. Перенаправление посетителей на сторонние сайты, особенно только с мобильных или только из Google.
• Google Search Console. Раздел «Проблемы безопасности» и внезапные новые страницы в индексе, которых вы не создавали.
• Почта хостинга. Жалобы на спам или сообщения хостера о повышенной нагрузке.

Если нашли хотя бы один признак, не ограничивайтесь удалением подозрительного файла. Надежнее всего — восстановить сайт из чистой резервной копии, сделанной до 20 октября, обновить PHP и CMS, сменить все пароли (админка, FTP, база данных, хостинг) и только потом возвращать свежий контент.

Типичные ошибки после новостей об уязвимости PHP

Во время таких инцидентов владельцы сайтов часто совершают одни и те же ошибки. Вот самые распространенные из них.

• Считать, что обновление WordPress и плагинов закрывает уязвимость PHP.
• Установить еще один плагин безопасности и на этом успокоиться.
• Доверять номеру версии и не проверять, установлена ли именно исправленная сборка.
• Обновить основную версию PHP на VPS и забыть о других сборках и тестовых сайтах.
• Обновить PHP и не перезапустить процессы, из-за чего старый код продолжает работать в памяти.
• Считать временные настройки полноценной защитой.
• Переключить старый сайт на PHP 8.3 в панели хостинга без тестирования и получить белый экран.
• Отложить обновление старого сайта, потому что «нас никто не будет атаковать, мы маленькие».
• Не знать, кто отвечает за сервер, и ждать, что «кто-то обновит».
• Не иметь свежей резервной копии сайта и базы данных.
• Удалить один подозрительный файл и считать сайт очищенным.
• Не сменить пароли после подозрения на взлом.
• Забыть о старых поддоменах и копиях сайта, которые тоже работают на PHP.
• Скачивать «проверочные» скрипты из непроверенных источников — под видом эксплойтов тоже распространяют вредоносный код.

Чек-лист: защищен ли ваш сайт от PHP2Shell

Пройдитесь по этому списку сегодня. Если на какой-то пункт вы не можете ответить «да», именно с него стоит начать.

• Я знаю, какая версия PHP работает на моем сайте.
• Я знаю, кто отвечает за обновление сервера: хостер, администратор или подрядчик.
• Хостер письменно подтвердил, что исправления CVE-2026-109618 и CVE-2026-109619 установлены.
• Мой сайт работает на PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 или более новой исправленной сборке.
• Если сайт на PHP 7.4–8.1, у меня есть подтверждение, что для него установлен патч поставщика.
• Сайт не работает на PHP 7.3 или более старой версии.
• Настройка session.upload_progress отключена или хостер подтвердил, что это сделано.
• На VPS обновлены все сборки PHP, а процессы перезапущены.
• Ядро CMS, тема и плагины обновлены до актуальных версий.
• Заброшенные плагины, которые давно не обновляются, заменены или удалены.
• Есть свежая резервная копия файлов и базы данных, сохраненная отдельно от хостинга.
• Есть резервная копия, сделанная до 20 октября 2026 года.
• Список администраторов сайта проверен, лишних нет.
• В Google Search Console нет сообщений о проблемах безопасности.
• Нет непонятных PHP-файлов, измененных после 20 октября.
• Старые копии и поддомены сайта отключены или тоже обновлены.
• Пароли от админки, FTP, базы данных и хостинга надежные и разные.
• Запланирован переход с PHP 8.2 до 31 декабря 2026 года, если сайт сейчас на этой версии.

Частые вопросы

Касается ли уязвимость PHP моего сайта на WordPress?

Да, если сервер, на котором работает сайт, использует неисправленную версию PHP. WordPress написан на PHP, поэтому зависит от него так же, как OpenCart, Drupal или самописные сайты. Защищенность определяет версия PHP на сервере, а не версия WordPress.

Поможет ли плагин безопасности, например Wordfence?

Нет, как основная защита — не поможет. По данным команды PHP, атака может сработать еще до того, как начнет выполняться код WordPress и его плагинов. Плагины безопасности полезны против других угроз, но здесь нужно обновление PHP на сервере.

Как быстро нужно обновиться?

Как можно скорее. Команда PHP рекомендует обновиться немедленно, а по сообщениям провайдеров, первые попытки атак появились уже в день выхода исправлений. Каждый день на неисправленной версии — дополнительный риск.

Мой сайт на PHP 7.4. Можно ли защитить его без переделки?

Только если хостер или поставщик долгосрочной поддержки установил для PHP 7.4 отдельный патч — официального выпуска не будет. Это временное решение: ветка 7.4 давно не поддерживается, так что переход на актуальную версию PHP и обновление сайта все равно нужны.

Можно ли самому переключить версию PHP в панели хостинга?

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

Как понять, что мой сайт уже взломали?

Тревожные признаки — неизвестные администраторы, новые PHP-файлы, перенаправление посетителей на сторонние сайты, сообщения в Google Search Console о проблемах безопасности, жалобы на спам. Если что-то из этого есть, восстановите сайт из чистой резервной копии, обновите PHP и смените все пароли.

Кто должен обновлять PHP: я или хостер?

На обычном виртуальном хостинге — хостер. На VPS или собственном сервере — владелец сервера или его администратор. Если сайт обслуживает подрядчик, это должно быть прописано в договоренностях.

Безопасность сайта — это процесс, а не разовое действие

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

Если ваш сайт работает на актуальном PHP и хостер подтвердил обновление, достаточно пройти чек-лист выше и проверить резервные копии. Если же сайт старый, на PHP 7.x или 5.6, или вы вообще не знаете, кто за ним следит, самое время это изменить. Можно передать сайт на постоянное ведение сайта с контролем обновлений или обновить его так, чтобы он работал на современной платформе.

Webatom разрабатывает и поддерживает сайты на WordPress, Drupal, CodeIgniter и Yii с 2010 года. Если нужна помощь с проверкой, обновлением или переходом на новую версию PHP, обращайтесь — а если старый сайт проще заменить, мы предлагаем создание сайтов под ключ на актуальных технологиях.