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

В октябре 2026 года появилась новость, на которую стоит обратить внимание владельцам огромного количества сайтов. Исследователи информационной безопасности с помощью современных ИИ-моделей обнаружили критические уязвимости непосредственно в PHP — одном из самых распространенных языков программирования для веб-разработки.

Это не проблема отдельного плагина WordPress, модуля или конкретной CMS. Ошибка находится значительно глубже — в самом PHP, на котором работают интернет-магазины, корпоративные сайты, порталы, сервисы и множество других веб-проектов.

Обнаруженным уязвимостям присвоены номера CVE-2026-109618 и CVE-2026-109619. Сам проект PHP выпустил для них внеочередные обновления и рекомендовал пользователям установить исправления как можно быстрее. Главная причина такой срочности — при определенных условиях уязвимости позволяют выполнить посторонний код на сервере без предварительной авторизации.

Разберемся простыми словами, что произошло, насколько это опасно для обычного сайта и что сейчас стоит проверить его владельцу.

Что произошло с PHP

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

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

Официальная команда PHP прямо указывает, что полноценного обходного решения для этих двух проблем нет и наиболее безопасный вариант — обновление PHP.

Для большинства владельцев сайтов этого уже достаточно, чтобы не откладывать проверку на потом.

Причем здесь нейросети

Особый интерес вызвало то, каким образом были обнаружены уязвимости.

Исследователи Wiz использовали ИИ-инструменты для анализа PHP и поиска сложных ошибок в его коде. Нейросети помогали изучать большие объемы информации, проверять гипотезы и быстрее находить возможные цепочки эксплуатации.

По данным Wiz, найденные проблемы находились в коде PHP много лет, а затронутые версии уходят как минимум к PHP 5.4.

Еще несколько лет назад поиск подобных ошибок мог потребовать огромного количества ручной работы со стороны очень квалифицированных специалистов. Искусственный интеллект заметно ускоряет этот процесс.

И в этом есть две стороны. С одной стороны, ИИ помогает специалистам по безопасности быстрее находить опасные ошибки и закрывать их до массовых атак.

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

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

В чем заключается проблема

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

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

В зависимости от настроек сервера и самого сайта последствия могут быть очень разными — от изменения файлов до получения доступа к конфигурационной информации.

Именно поэтому уязвимости получили статус критических.

Что может произойти с сайтом

Фраза «удаленное выполнение кода» для владельца бизнеса звучит довольно абстрактно. На практике последствия могут быть вполне понятными.

После взлома на сайте могут появляться посторонние страницы, ссылки и рекламные блоки. Пользователей могут перенаправлять на другие ресурсы. Злоумышленники способны внедрить вредоносный код, получить доступ к отдельным файлам или использовать сервер для дальнейших атак.

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

Главная страница открывается, каталог доступен, формы работают — но внутри уже появился посторонний код или скрытые страницы.

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

«У меня маленький сайт — кому он нужен?»

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

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

В этом сценарии совершенно неважно, принадлежит сайт международной компании или небольшому местному бизнесу.

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

Что делать владельцам сайтов на 1С-Битрикс

Особенно актуальна эта новость для проектов на «1С-Битрикс: Управление сайтом», потому что сама платформа работает на PHP.

При этом уязвимость обнаружена не в Битрикс, а именно в PHP. То есть установка последних обновлений CMS сама по себе не решает проблему, если сервер продолжает использовать уязвимую версию языка.

С февраля 2026 года минимальным требованием для актуальных версий 1С-Битрикс является PHP 8.2 и выше. Но на старых проектах часто остается другая проблема: сайт может много лет работать на прежней версии Битрикс с большим количеством сторонних модулей и собственных доработок.

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

Для проектов на Битрикс лучше сначала создать резервную копию, проверить актуальность самой платформы и установленных модулей, а затем обновлять PHP и тестировать сайт. После обновления особенно важно проверить каталог, формы, поиск, корзину, оформление заказа, личный кабинет, обмен с 1С, CRM и платежными сервисами.

Главная страница может работать идеально, а ошибка обнаружится только на последнем шаге оформления заказа.

Старый PHP лучше не оставлять «пока работает»

Если сайт несколько лет не обновлялся, стоит отдельно посмотреть, какая версия PHP используется сейчас.

Старые ветки постепенно перестают получать официальные обновления безопасности. Поэтому принцип «ничего не меняем, потому что сайт работает» со временем становится все более рискованным.

Для новых критических уязвимостей исправления вошли в PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Более новые версии соответствующих веток также содержат эти исправления. PHP 8.1 и более ранние ветки уже не получают такие обновления непосредственно от проекта PHP, хотя некоторые поставщики серверных систем могут выпускать собственные исправления.

От владельца сайта здесь не требуется самостоятельно разбираться в номерах пакетов.

Достаточно задать разработчику или технической поддержке простой вопрос:

«Наш PHP защищен от CVE-2026-109618 и CVE-2026-109619?»

Если ответ неочевиден — это уже повод провести проверку.

Что нужно сделать сейчас

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

Безопасные релизы для затронутых актуальных веток начинаются с PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Сам PHP рекомендует пользователям обновляться сразу после обнаружения проблемы.

После обновления необходимо проверить работу сайта. Особенно внимательно — формы, корзину, оформление заказа, личный кабинет и интеграции. Если используется 1С-Битрикс или другой большой проект с множеством доработок, обновление лучше сначала протестировать, а не проводить вслепую на рабочем сайте.

То есть алгоритм довольно простой: узнать версию, установить исправление, проверить работоспособность.

Почему нельзя отложить обновление на несколько месяцев

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

Появляются подробные технические описания, исследователи экспериментируют с различными сценариями, а злоумышленники начинают проверять доступные в интернете системы.

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

Поэтому ждать, пока проблема начнет массово использоваться, не лучший подход.

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

Почему одной установки обновления недостаточно

После обновления нужно убедиться в двух вещах: сервер действительно использует новую версию PHP, а сайт продолжает нормально работать.

• Для обычного корпоративного сайта достаточно пройти основные страницы и отправить тестовую форму.

• Для интернет-магазина стоит дополнительно положить товар в корзину и пройти весь процесс оформления тестового заказа.

• Для Битрикс-проектов нужно проверить также обмен данными, интеграции и сторонние модули.

То есть сообщение «PHP обновлен» — это еще не финал работы. Финал — когда обновленная версия работает на боевом сайте и основные функции успешно протестированы.

А что делать, если сайт уже долго работал на уязвимой версии

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

Стоит обратить внимание на неизвестные файлы, внезапно появившиеся страницы, странные редиректы, изменения пользователей CMS, необычные ошибки и резкие изменения поисковой индексации.

Если есть основания подозревать взлом, простой установки новой версии PHP уже недостаточно. Нужно искать последствия компрометации.

При чем здесь SEO

На первый взгляд эта история относится исключительно к программированию и безопасности. Но для SEO последствия взлома могут быть очень серьезными.

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

Другой сценарий — подмена контента или редиректы. Пользователь открывает результат в Яндексе, а оказывается на казино, рекламном сайте или другой посторонней странице. Поисковые системы реагируют на подобные проблемы быстро.

В результате сайт может потерять позиции, трафик и часть страниц в индексе. В отдельных случаях пользователь увидит предупреждение о небезопасном ресурсе еще до перехода. Поэтому техническая безопасность — это в том числе и часть SEO.

Нет смысла месяцами развивать семантическое ядро, контент и ссылочный профиль, если устаревшее серверное ПО способно поставить весь проект под угрозу.

Сайт нельзя один раз разработать и забыть

История с PHP еще раз показывает, почему коммерческому сайту необходима постоянная техническая поддержка.

Сайт — это не буклет, который однажды сверстали и больше не меняют.

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

Один модуль нельзя обновить из-за другого. Новая версия PHP не работает со старым шаблоном. CMS давно не обновлялась, потому что после первого же обновления что-то ломается.

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

ИИ меняет и кибербезопасность

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

ИИ способен анализировать большие объемы кода, искать подозрительные зависимости и помогать специалистам проверять сложные гипотезы значительно быстрее. Для владельцев сайтов это означает, что жизненный цикл уязвимостей тоже ускоряется.

Проблему быстрее находят.

Быстрее исследуют.

Быстрее выпускают исправление.

Но и потенциальным злоумышленникам становится проще анализировать опубликованную информацию. Поэтому скорость реакции на критические обновления становится все более важной частью нормальной эксплуатации сайта.

Как мы следим за техническим состоянием сайтов в Нейрон

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

Недостаточно вывести страницы в ТОП Яндекса и Google или увеличить трафик. Сайт должен стабильно работать, оставаться доступным для пользователей и поисковых систем и своевременно получать необходимые технические исправления.

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

Особенно это касается крупных интернет-магазинов и сайтов на 1С-Битрикс, где обновление PHP, CMS или отдельного модуля может затронуть каталог, корзину, обмен с 1С, CRM и другие бизнес-процессы.

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

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

И гораздо лучше устранить ее после выхода обновления безопасности, чем разбираться с последствиями после взлома.