Критическая уязвимость в PHP, из-за которой 22 октября 2026 года НКЦКИ разослал объектам критической инфраструктуры требование срочно обновляться или временно отключать серверы, касается далеко не только госсектора: на этом языке работают девять из десяти русскоязычных сайтов. Малый бизнес никакими письмами не предупреждают — но взломанный или отключённый сайт одинаково тихо выпадает из поиска, и теряет он не серверную память, а позиции, трафик и годами наработанное доверие поисковика. Ниже — что именно случилось, почему для коммерческого сайта это вопрос не «безопасности вообще», а видимости в выдаче, и что сделать владельцу за ближайшие сутки, не вызывая дорогого безопасника.
Что произошло: письмо НКЦКИ и две уязвимости в PHP
21 октября 2026 года разработчики PHP выпустили экстренное обновление безопасности. Оно закрывает две критические уязвимости, которым по шкале CVSS v4.0 присвоена оценка 9,2 из 10 — это верхняя граница опасности, когда у защищающейся стороны практически нет права на паузу. Обе уязвимости нашли с помощью искусственного интеллекта, а предварительное предупреждение вышло ещё 20 октября — релиз ускорили на день, потому что часть деталей утекла раньше срока.
Опасность в том, что эксплуатация не требует ни пароля, ни учётной записи. Атакующий обращается к сайту как обычный посетитель и при удачной цепочке получает выполнение произвольного кода на сервере с правами веб-процесса. Дальше — полный контроль над сайтом и возможность вытащить из памяти сервера пароли, ключи и другие секреты, которые приложение держит в оперативной памяти во время работы. Под ударом все конфигурации, обрабатывающие веб-запросы: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP, LiteSpeed. Наиболее показанный на практике сценарий — mod_php, для него уже демонстрировали рабочий эксплойт.
Уязвимостям присвоены идентификаторы CVE-2026-109618 и CVE-2026-109619, в публикациях их объединяют под названием PHP2Shell. Первая — удалённое выполнение кода через повреждение памяти при нехватке ресурсов; вторая — обращение к уже освобождённой памяти с раскрытием её содержимого и тем же выполнением кода. Для владельца сайта важны не внутренности, а вывод: сервер на непропатченной версии можно захватить снаружи и без следов в привычных формах входа.
Письмо НКЦКИ (центр действует при ФСБ) ушло через систему ГосСОПКА владельцам критической инфраструктуры — сетей связи, информационных систем госорганов, финансовых, энергетических, транспортных и медицинских компаний. Рекомендации в нём прямые: обновить PHP до исправленной версии, после обновления проверить серверы антивирусом и изучить журналы на признаки взлома, а если обновиться быстро нельзя — «рассмотреть временное ограничение внешнего доступа к уязвимым веб-серверам вплоть до их отключения». О подозрительной активности предписано сообщать в дежурный центр ГосСОПКА.
Почему это касается обычного коммерческого сайта, а не только госсектора
Письмо адресовано крупным структурам, но уязвимость одна на всех. По данным W3Techs, PHP используют 90,8% сайтов с русскоязычным контентом и 69,3% сайтов в мире. Практически любой сайт на WordPress, «Битрикс», Joomla, OpenCart, MODX или на самописном движке — это PHP. Если вы не знаете, на чём стоит ваш сайт, с вероятностью девять к одному это именно он.
Разница между госкомпанией и интернет-магазином здесь только в том, что первую обязали письмом, а вторую — нет. Злоумышленнику же всё равно, чей сервер захватывать: массовые атаки идут не по списку важных целей, а по всему диапазону адресов подряд, автоматическими сканерами. Чем проще и типовее сайт, тем раньше до него доберётся автоматика, потому что такие серверы годами не обновляют. Отсутствие письма — не защита, а всего лишь отсутствие предупреждения.
И ещё одно отличие не в пользу малого бизнеса. У крупной организации есть кому среди ночи обновить PHP и прочитать журналы. У владельца небольшого сайта обычно нет ни того, ни другого — поэтому взлом он замечает не по журналам, а по падению трафика через пару недель, когда поисковик уже всё понял и отреагировал.
Взлом и позиции в поиске — это одно и то же
Привычка делить задачи на «SEO» и «безопасность» для коммерческого сайта вредна: с точки зрения выдачи это одна задача. Поисковая система оценивает не только тексты и ссылки, но и безопасность ресурса для посетителя. Как только сайт начинает вести себя опасно, позиции идут вниз — независимо от того, насколько хорошо он был оптимизирован до этого.
Взломанный сайт редко «ломается» заметно. Чаще он продолжает работать, а в фоне делает чужую работу: раздаёт скрытые ссылки на чужие ресурсы, подставляет редиректы для посетителей из поиска, грузит вредоносный код в браузер клиента, рассылает спам с вашего домена. Для владельца внешне всё как обычно, а для поисковика картина другая.
- Пометка «опасный сайт». Браузеры и поиск показывают предупреждение на красном фоне. Переходы по такому сайту обрушиваются: мало кто кликает «всё равно перейти».
- Понижение и выпадение из выдачи. Зараженные страницы теряют позиции, часть выпадает из индекса. Возврат после снятия заражения занимает недели и месяцы — доверие восстанавливается медленнее, чем теряется.
- Подмена сниплетов. В выдаче вместо вашего заголовка и описания появляются чужие — на другом языке, с рекламой азартных игр или аптек. Кликабельность падает до нуля.
- Отключение сервера. Если по рекомендации НКЦКИ или по решению хостинга уязвимый сервер отключат, сайт отдаёт ошибку. Длительная недоступность — тоже сигнал к понижению: поисковик не станет держать в топе то, что не открывается.
Итог простой: деньги, вложенные в продвижение, защищает в том числе своевременное обновление PHP. Сайт, который годами поднимали в выдаче, теряет позиции за несколько дней заражения, а восстановление обходится дороже профилактики и всегда дольше.
Какие версии PHP безопасны
Экстренное обновление вышло для всех поддерживаемых веток. Проверьте, какая версия стоит у вас, и сверьте со статусом ниже. Версию видно в панели хостинга или в сервисах проверки заголовков сервера; в WordPress — в разделе «Инструменты → Здоровье сайта».
| Ветка PHP | Исправленная версия | Статус |
|---|---|---|
| 8.5 | 8.5.12 | Поддерживается, обновиться до указанной |
| 8.4 | 8.4.27 | Поддерживается, обновиться до указанной |
| 8.3 | 8.3.36 | Поддерживается, обновиться до указанной |
| 8.2 | 8.2.35 | Поддерживается; конец поддержки — 31 декабря 2026 |
| 8.1 и старше | Патч от поставщика | Проектом PHP не обновляется; нужен бэкпорт от хостинга или переход на 8.2+ |
| 7.4, 8.0 | Переход на 8.2+ | Устарели; выпущены минимальные патчи, но будущего у веток нет |
Если у вас PHP 8.2, 8.3, 8.4 или 8.5 — задача сводится к обновлению последнего числа в номере версии, это делается за минуты. Если ветка 8.1 или старше — это повод не только закрыть уязвимость, но и запланировать переход на поддерживаемую версию: старый PHP медленнее, хуже совместим с новыми плагинами и будет ловить подобные истории снова.
Что сделать владельцу сайта прямо сейчас
Для обычного коммерческого сайта не нужен безопасник и не нужно «защищать сервер» — почти всё закрывается силами хостинга и получасовой самостоятельной проверкой. Порядок действий такой.
- Попросить хостинг обновить PHP. На виртуальном хостинге переключение версии обычно есть в панели в один клик; если ветка старая — написать в поддержку с просьбой поставить исправленный релиз. Это бесплатно и быстро. На своём сервере (VPS/выделенный) обновление ставит тот, кто его администрирует.
- Проверить, открывается ли сайт и нет ли пометки «опасно». Откройте сайт в режиме инкогнито и с телефона, посмотрите, не показывает ли браузер красный экран предупреждения. Полезно прогнать домен через бесплатный экспресс-аудит сайта — он за полминуты покажет доступность, ответы сервера и явные технические проблемы без регистрации.
- Поискать чужие файлы и незнакомые входы в админку. В корне и папках загрузок не должно быть свежих .php-файлов со странными именами. В списке пользователей CMS — только те, кого вы знаете; лишние администраторы удаляются, пароли меняются.
- Проверить, как сайт выглядит в выдаче. Вбейте в поиск
site:ваш-домени посмотрите заголовки и описания страниц. Чужой язык, аптеки, казино в сниплетах — признак взлома, даже если на самом сайте внешне всё в порядке. - Навести базовую гигиену. Свежие версии CMS и плагинов, регулярные резервные копии в стороннем хранилище, двухфакторная аутентификация в админке, удаление неиспользуемых тем и плагинов. Это не разовая акция под конкретную новость, а постоянная норма.
Если часть пунктов звучит незнакомо, начать стоит с технической стороны: технический аудит сайта показывает не только уязвимые места, но и ошибки, которые тихо режут позиции независимо от этой истории с PHP. Таблица ниже сводит проверку к трём колонкам: что смотреть, как смотреть и чем пренебрежение грозит именно для поиска.
| Что проверить | Как | Чем грозит для SEO |
|---|---|---|
| Версия PHP | Панель хостинга, «Здоровье сайта» в WordPress | Захват сервера, заражение страниц, понижение в выдаче |
| Пометка «опасный сайт» | Открыть сайт в инкогнито и с телефона | Обвал переходов, предупреждение браузера на входе |
| Чужие файлы и пользователи | Файловый менеджер, список админов CMS | Скрытые ссылки и редиректы, за которые понижают |
| Сниплеты в поиске | Запрос site:домен |
Подмена заголовков и описаний, нулевая кликабельность |
| Доступность сайта | Экспресс-аудит, проверка кодов ответа | Долгая недоступность = сигнал к понижению |
Как понять, что сайт уже взломан
Самое опасное в таких заражениях — их незаметность для владельца. Сайт работает, заказы идут, а в фоне он уже помечен поисковиком. Насторожить должны следующие признаки, даже по отдельности.
- В поиске у ваших страниц в заголовке или описании появился текст, которого вы не писали, особенно на другом языке.
- Посетители из поиска жалуются, что их перебрасывает на посторонний сайт, хотя по прямому адресу всё открывается нормально.
- Антивирус или браузер показывает предупреждение при заходе; в консоли разработчика видны запросы к незнакомым доменам.
- В панели хостинга резко вырос исходящий трафик или нагрузка, хотя посещаемость прежняя — сервер используют для чужих задач.
- В аналитике без причины обвалился трафик из поиска за несколько дней — частый первый симптом, который замечают позже остальных.
Если хоть один пункт совпал, сначала снимают заражение и закрывают дыру, потом восстанавливают из чистой резервной копии, и только затем через инструменты вебмастера просят поисковик пересмотреть сайт. Порядок именно такой: пока дыра открыта, повторное заражение произойдёт в тот же день, и пересмотр ничего не даст.
Частые вопросы
У меня небольшой сайт-визитка, кому он нужен? Массовые атаки не выбирают по важности — автоматические сканеры проходят по всем адресам подряд. Маленький сайт ценен не содержимым, а самим сервером: его используют для рассылки спама, раздачи чужих ссылок и редиректов. И именно за это поисковик понижает домен.
Обновление PHP не сломает сайт? Переход на соседнее число внутри той же ветки (например, с 8.3.30 на 8.3.36) совместимость не меняет и почти всегда проходит незаметно. Риск есть при скачке через версии (с 7.4 на 8.3) — там нужна проверка на копии сайта. Поэтому резервная копия перед обновлением обязательна в любом случае.
У меня стоит плагин безопасности, этого хватит? Плагин работает внутри CMS, а уязвимость — уровнем ниже, в самом PHP. Он может частично помочь, но не заменяет обновление: единственная полноценная защита — исправленная версия PHP. Временные ограничения лишь снижают риск по отдельным путям атаки.
Как быстро позиции вернутся после снятия заражения? Однозначного срока нет и быть не может. Пометку «опасный сайт» снимают быстро, а доверие в ранжировании восстанавливается медленно — тем дольше, чем дольше сайт раздавал вредоносное содержимое. Поэтому профилактика всегда дешевле лечения.
Можно ли проверить сайт бесплатно, не заказывая услугу? Да, доступность, коды ответов и явные технические ошибки показывает бесплатный экспресс-аудит на сайте — за полминуты и без регистрации. Платная работа начинается там, где нужен глубокий разбор причин и план действий под конкретный сайт.
Коротко
- 21 октября 2026 закрыты две критические уязвимости PHP (CVE-2026-109618 и CVE-2026-109619, оценка 9,2 из 10); они позволяют захватить сервер удалённо и без пароля.
- 22 октября НКЦКИ при ФСБ через ГосСОПКА потребовал от критической инфраструктуры срочно обновиться, а при невозможности — ограничить доступ к серверам вплоть до отключения.
- Уязвимость одна на всех: PHP стоит на 90,8% русскоязычных сайтов, и малый бизнес под теми же автоматическими атаками, только без предупреждения.
- Безопасность и позиции — одна задача: взломанный сайт тихо раздаёт чужие ссылки и редиректы, получает пометку «опасный», понижается и выпадает из выдачи.
- Действия владельца: обновить PHP через хостинг (8.2.35 / 8.3.36 / 8.4.27 / 8.5.12), проверить пометку «опасно», чужие файлы и входы, сниплеты в поиске, держать базовую гигиену.
- Восстановление дороже и дольше профилактики, поэтому обновление и резервные копии защищают в том числе вложения в продвижение.
Если по итогам проверки непонятно, чист ли сайт и не просели ли позиции из-за технических проблем, разберём это предметно на SEO-консультации: что происходит с вашим доменом в выдаче, где слабые места и с чего начинать. Веду проекты в SEO с 2005 года, результат можно проверить по 130+ кейсам с адресами сайтов. Связаться: +7 (921) 333-77-45.
Источники
- РБК, 22.10.2026 — «В России велели отключать сайты с уязвимостью в PHP».
- PHP.net, 21.10.2026 — официальная новость об экстренном релизе безопасности (версии 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35; CVE-2026-109618, CVE-2026-109619).
- W3Techs — статистика использования PHP (90,8% сайтов с русскоязычным контентом, 69,3% в мире).
- BleepingComputer, 21.10.2026 — «PHP ships emergency patches for critical PHP2Shell flaws».
- BleepingComputer, 20.10.2026 — предварительное предупреждение о двух критических уязвимостях.
Увеличьте позиции и продажи вашего сайта
Профессиональное SEO-продвижение с гарантией результата. Выберите подходящую услугу:
Остались вопросы по продвижению?
Меня зовут Анатолий Кузнецов, я SEO-оптимизатор с 20-летним стажем. Разберу ваш сайт, отвечу на вопросы и подскажу, что улучшить для роста позиций в Яндексе.
Связаться со мной →
Комментарии
Денис
Зашёл в панель хостинга, у меня стоит PHP 8.1. Поддержка пишет, что ветка уже снята с обновлений и предлагают перейти на 8.3. Переход на копии гоняли, вроде всё открывается. Стоит ли сразу прыгать на 8.3, или безопаснее остаться на 8.1 и попросить у них бэкпорт патча?
Анатолий Кузнецов автор
Раз копия на 8.3 открывается и ничего не разъехалось — переходите на 8.3, это правильное решение не только на сегодня. Бэкпорт патча на 8.1 закрывает конкретно эти две дыры, но ветка всё равно мёртвая: следующую историю она поймает так же, а новые плагины и темы всё чаще требуют 8.2+. Перед переключением снимите свежую резервную копию и проверьте на копии оплату и формы — именно они чаще всего ломаются при скачке версии. После перехода пройдитесь по сайту в режиме инкогнито и прогоните
site:домен, чтобы убедиться, что за время на 8.1 вас не успели заразить.Марина, интернет-магазин
А разве это не раздувание? Письмо же госам разослали, при чём тут мой магазин косметики на WordPress. У меня и данных-то секретных нет, кроме заказов.
Анатолий Кузнецов автор
Письмо госам — потому что их обязали по закону о критической инфраструктуре, а не потому что остальным ничего не грозит. Вашему магазину угроза ровно та же: WordPress — это PHP, а автоматические сканеры идут по адресам подряд, им неинтересно, косметика у вас или реестр. Злоумышленнику нужны не ваши заказы, а сам сервер — чтобы раздавать с вашего домена чужие ссылки и редиректы. И вот за это поисковик понизит именно магазин косметики: заражённую витрину он пометит как опасную, переходы просядут, а восстановление репутации домена займёт недели. Так что обновите PHP через хостинг и проверьте сниплеты в выдаче — это полчаса, а не повод для паники.
Сергей П.
У нас VPS, администрирую сам. Обновил до 8.3.36, антивирусом по инструкции прошёлся — чисто. Логи смотреть толком не умею, что там искать-то? Боюсь пропустить, что уже влезли до обновления.
Алексей
Поставил плагин безопасности с файрволом, он вроде такие запросы должен резать. Разве этого мало? Обновляться боязно, сайт старый, на функциях много кастома.
Анатолий Кузнецов автор
Файрвол на уровне плагина работает внутри CMS, а дыра сидит ниже — в самом PHP, который обрабатывает запрос ещё до того, как до него доберётся плагин. Поэтому полноценной защиты он не даёт, разработчики PHP прямо пишут, что единственное лекарство — обновлённая версия. Понимаю опасение с кастомом, но обновление внутри ветки (с 8.3.x на 8.3.36) совместимость не трогает, ломается обычно скачок через мажорные версии. Сделайте так: полная резервная копия, разверните её на тестовой копии сайта, обновите там, проверьте кастомные функции и оплату, и только потом повторите на боевом. Если копии развернуть негде — это само по себе сигнал, что инфраструктуру пора приводить в порядок.
Ольга, веб-мастер на фрилансе
Веду десяток клиентских сайтов на разных хостингах. Есть способ быстро проверить версию PHP сразу по всем, не заходя в каждую панель вручную? И правда ли, что заражение бьёт именно по позициям, а не только по безопасности?
Анатолий Кузнецов автор
Версию часто видно в заголовках ответа сервера, так что по списку доменов быстрее всего пройтись любым пакетным чекером заголовков или простым скриптом, который дёргает каждый сайт и вытаскивает строку сервера — заходить в каждую панель не обязательно. Где заголовок скрыт, останется ручная проверка через «Здоровье сайта» в WordPress. По позициям — да, это не теория: заражённый сайт получает пометку «опасный», часть страниц выпадает из индекса, в сниплетах появляется чужой текст, и переходы обрушиваются. Для клиента это выглядит как внезапное падение трафика без видимой причины, а причина — незакрытая дыра. Так что по каждому сайту после проверки версии прогоните ещё
site:домени загляните в консоль на посторонние запросы.Тимур
Хостинг ответил, что у них «общий сервер и PHP обновляется централизованно, всё под контролем». Верить на слово или всё равно перепроверять?
Наталья
Два месяца назад у нас как раз был провал по трафику из Яндекса, списали на сезон. Теперь читаю про редиректы для посетителей из поиска и думаю — а вдруг уже тогда взломали? Как отличить сезонное падение от заражения задним числом?
Анатолий Кузнецов автор
Отличить можно по характеру падения. Сезонный спад идёт плавно и равномерно по всем страницам, повторяется из года в год в те же месяцы и виден в многолетнем графике. Заражение роняет трафик резко, за несколько дней, часто бьёт по отдельным разделам и сопровождается другими следами: чужой текст в сниплетах, жалобы на переброс, рост исходящего трафика. Поднимите график за пару лет и сравните тот провал с тем же периодом прошлых сезонов — если раньше в эти месяцы такого обвала не было, версия сезона слабеет. Параллельно проверьте тогдашние резервные копии на посторонние файлы и посмотрите в вебмастере, не было ли в тот период предупреждений о заражении. Это как раз тот случай, где технический разбор причины окупается: списать на сезон легко, а потерянные позиции потом возвращать долго.
Виктор
А если вообще не обновляться, а по совету из письма просто временно закрыть сайт от внешнего доступа на пару недель, пока суета уляжется? Для поиска это чем-то грозит?
Евгения, студия на MODX
У нас часть проектов на MODX, часть на самописном PHP. По WordPress инструкций полно, а по этим что — те же действия или есть нюансы с проверкой чужих файлов?
Роман
Прогнал домен через экспресс-аудит, доступность зелёная, но вылезли ошибки по редиректам и кодам ответа, про которые я не знал. Они к этой уязвимости отношения не имеют или тоже могут быть следом взлома?
Павел К.
Смущает, что уязвимости нашли с помощью ИИ. Значит, и ломать теперь будут им же, массово и быстро? Получается, окно на обновление совсем маленькое?
Игорь, VPS на FrankenPHP
У меня нестандартная связка, сайт крутится под FrankenPHP. В списке затронутых окружений его называют, но обновлений под него по-человечески мало. Ставить исправленную версию PHP внутрь образа и пересобирать — этого достаточно, или там своя история?