21 октября 2026 года разработчики PHP выпустили экстренные обновления безопасности, закрывающие две критические уязвимости: CVE-2026-109618 и CVE-2026-109619.
Они позволяют злоумышленнику при определённых условиях выполнить произвольный код на сервере без авторизации. Для владельца сайта это риск потери данных, подмены страниц, размещения вредоносного кода и нарушения работы ресурса. Защита начинается с проверки версии PHP, установки исправлений и проверки самого сайта после обновления.
Ситуация затрагивает не только разработчиков и системных администраторов. Если сайт принимает заявки, хранит данные клиентов, участвует в продажах или привлекает посетителей из Google, его безопасность напрямую связана с работой и продвижением ресурса. При этом обновить PHP недостаточно, если на сайте остались другие уязвимости, устаревшие расширения или следы предыдущего взлома.
Какие уязвимости обнаружены в PHP в октябре 2026 года
PHP — один из основных языков программирования, используемых для создания сайтов и веб-приложений. На нём работают многие проекты на WordPress, Joomla, Drupal и других системах управления содержимым, а также интернет-магазины и индивидуально разработанные сайты.
21 октября 2026 года команда PHP объявила о выпуске исправлений для двух критических уязвимостей:
- CVE-2026-109618 — ошибка обработки нехватки памяти, способная привести к повреждению внутреннего состояния PHP и выполнению произвольного кода.
- CVE-2026-109619 — ошибка управления внутренними данными между запросами, при определённых условиях также позволяющая выполнить произвольный код.
Обе уязвимости имеют критический уровень опасности. Для успешной атаки не обязательно получать учётную запись администратора сайта: воздействие может происходить через специально сформированные HTTP-запросы к уязвимому серверу.
Главная проблема заключается в том, что уязвимость находится в самом PHP, а не только в конкретной теме оформления, плагине или системе управления сайтом. Поэтому простая установка нового шаблона, смена пароля администратора или удаление подозрительного расширения не устраняет первопричину риска.
Подробности опубликованы в официальных материалах PHP и предупреждениях специалистов по информационной безопасности:
Какие версии PHP затронуты и до какой версии нужно обновляться
Уязвимости затрагивают PHP 5.4 и более новые версии вплоть до выпусков, в которых ещё не установлены соответствующие исправления. Наличие обновления зависит от ветки PHP и поставщика программного обеспечения.
По состоянию на 22 октября 2026 года в официальных выпусках PHP опубликованы следующие исправленные версии:
| Ветка PHP | Исправленная версия | Рекомендация |
|---|---|---|
| PHP 8.5 | 8.5.12 | Обновить до исправленного выпуска |
| PHP 8.4 | 8.4.27 | Обновить до исправленного выпуска |
| PHP 8.3 | 8.3.36 | Обновить до исправленного выпуска |
| PHP 8.2 | 8.2.35 | Обновить до исправленного выпуска |
У PHP 8.1 и более старых веток есть отдельная проблема: они завершили жизненный цикл официальной поддержки и не получают новые исправления от основной команды PHP. Некоторые поставщики серверных платформ могут выпускать собственные исправления для старых версий, поэтому состояние пакета необходимо проверять у конкретного хостинг-провайдера.
Важно различать номер версии и наличие исправления. Например, PHP 8.3.20 и PHP 8.3.36 относятся к одной ветке, но первая версия не содержит рассматриваемых исправлений. Само наличие PHP 8.3 в панели управления хостингом ещё не говорит о безопасности сервера.
Предпочтительный вариант — перейти на поддерживаемую ветку PHP и установить последний исправленный выпуск. Но перед переключением необходимо проверить совместимость сайта с новой версией, особенно если проект давно не обновлялся и использует собственные модули или расширения.
Как проверить, какая версия PHP используется на сайте
Владелец сайта не обязан самостоятельно разбираться в серверных настройках. Но он должен понимать, кто отвечает за их проверку и устранение уязвимостей.
Узнать используемую версию PHP можно несколькими способами:
- Через панель управления хостингом. Найдите настройки PHP для нужного домена. В панели может быть указана активная версия интерпретатора.
- Через техническую поддержку хостинга. Уточните не только номер версии, но и наличие исправлений для CVE-2026-109618 и CVE-2026-109619.
- Через системного администратора или веб-студию. Специалист проверит конфигурацию сервера и определит, какая версия PHP обслуживает сайт.
- Через серверные команды. При наличии соответствующего доступа можно выполнить команду
php -v. Однако она может показывать версию PHP для командной строки, которая отличается от версии, используемой сайтом через PHP-FPM или веб-сервер.
Последний нюанс особенно важен. На сервере могут одновременно работать несколько версий PHP для разных сайтов или задач. Проверка только через командную строку не всегда подтверждает, что веб-запросы обрабатываются исправленной версией.
После обновления необходимо убедиться, что новая версия действительно используется нужным доменом, а сайт открывается и выполняет свои основные функции.
Почему нельзя просто переключить PHP на новую версию
Обновление PHP может повлиять на работу сайта. Старые плагины, библиотеки, собственные скрипты и отдельные функции могут быть несовместимы с новой версией языка.
Поэтому безопасное обновление включает несколько действий:
- проверку текущей версии PHP и конфигурации сервера;
- проверку совместимости CMS, шаблона, плагинов и библиотек;
- создание резервной копии файлов и базы данных;
- установку исправленной версии PHP;
- проверку страниц, форм, авторизации, поиска и других важных функций;
- анализ журналов ошибок после переключения.
Если сайт старый, перед обновлением может потребоваться модернизация отдельных компонентов. В таком случае сначала оценивают риски и выбирают подходящий порядок работ.
Откладывать исправление уязвимости на неопределённый срок тоже нельзя. Если совместимость с актуальной версией PHP отсутствует, необходимо согласовать временные меры с хостинг-провайдером и подготовить переход на поддерживаемую среду. Возможность использования исправленного пакета для старой ветки нужно подтверждать отдельно.
Если проекту требуется техническое обновление, BMG.by выполняет доработку и модернизацию сайтов. Объём работ зависит от состояния исходного кода, используемой CMS и требований к совместимости.
Что может произойти с сайтом при эксплуатации уязвимости
Наличие уязвимой версии PHP не доказывает, что сайт уже взломан. Но оно создаёт риск, который необходимо устранить. При успешной атаке последствия зависят от конфигурации сервера, прав процесса PHP и возможностей злоумышленника.
Возможные последствия включают:
- Размещение вредоносного кода. Злоумышленник может попытаться изменить файлы сайта, внедрить перенаправления или добавить посторонний контент.
- Кражу данных. При наличии соответствующих прав атакующий может получить доступ к конфиденциальной информации, доступной приложению.
- Создание скрытых учётных записей. После проникновения могут появиться дополнительные способы доступа к административной части сайта.
- Рассылку спама и вредоносных ссылок. Скомпрометированный ресурс могут использовать для рассылок, размещения посторонних страниц или перенаправления посетителей.
- Нарушение работы сайта. Изменения файлов, нагрузки на сервер или вредоносные процессы могут привести к ошибкам и недоступности страниц.
Даже если главная страница открывается, это не подтверждает отсутствие взлома. Вредоносные изменения могут затрагивать только отдельные URL, показываться определённым посетителям или активироваться при конкретных условиях.
Поэтому после обнаружения уязвимости нужно не только обновить PHP, но и оценить состояние самого сайта. Если есть подозрение на проникновение, сначала сохраняют необходимые журналы и данные для расследования, затем устраняют причину и проверяют ресурс.
Как защитить сайт от взлома: что необходимо проверить
Защита сайта состоит из нескольких уровней. Обновлённый PHP закрывает известные уязвимости интерпретатора, но не заменяет остальные меры информационной безопасности.
1. Обновление CMS, плагинов и библиотек
Устаревшие компоненты могут содержать собственные уязвимости. Необходимо проверять систему управления сайтом, расширения, шаблон, сторонние библиотеки и серверное программное обеспечение. Устанавливать обновления следует с учётом совместимости и предварительного резервного копирования.
2. Резервное копирование
Резервная копия позволяет восстановить сайт после неудачного обновления, повреждения данных или инцидента безопасности. Копировать нужно не только файлы, но и базу данных, а также необходимые настройки.
При этом наличие копии ещё не гарантирует восстановление. Важно проверять возможность её использования, хранить резервные версии отдельно от основного сайта и не перезаписывать все копии заражёнными данными.
3. Контроль доступа
Необходимо ограничить административные права, удалить неиспользуемые учётные записи, использовать уникальные пароли и многофакторную аутентификацию там, где она доступна. Доступы сотрудников и подрядчиков следует пересматривать после завершения работ.
4. Мониторинг доступности и изменений
Контроль доступности помогает обнаруживать сбои, а мониторинг файлов, журналов ошибок и подозрительных запросов позволяет быстрее заметить признаки атаки. Эти задачи связаны, но не равнозначны: проверка того, что главная страница открывается, не заменяет анализ событий безопасности.
5. Проверка сайта после обновлений
После изменения PHP или компонентов CMS необходимо проверить ключевые страницы и функции. Для интернет-магазина это могут быть каталог, карточки товаров, корзина и оформление заказа. Для корпоративного сайта — формы заявок, поиск, личный кабинет и интеграции.
Если техническое состояние проекта неизвестно, начать можно с аудита сайта. Он позволяет определить объём необходимых проверок и составить план дальнейших работ.
Почему резервные копии и круглосуточный мониторинг действительно важны
Инциденты безопасности не всегда происходят в рабочее время. Поэтому критические сбои и подозрительная активность требуют своевременного обнаружения, а восстановление сайта не должно зависеть исключительно от того, когда сотрудник увидит сообщение о проблеме.
Мы уделяем внимание сопровождению сайтов, контролю их состояния, резервному копированию и обновлению компонентов. Наш подход строится на регулярной технической работе, а не на разовом вмешательстве после появления ошибки.
При этом необходимо разделять несколько задач:
- Мониторинг доступности показывает, отвечает ли сайт на запросы и доступны ли контролируемые страницы.
- Мониторинг безопасности предполагает анализ подозрительных событий, изменений и признаков несанкционированного доступа.
- Резервное копирование создаёт возможность восстановления данных и файлов.
- Обновление компонентов устраняет известные уязвимости и поддерживает совместимость программного обеспечения.
- Техническое сопровождение объединяет необходимые работы по поддержанию сайта в рабочем состоянии.
Ни одна из этих мер в отдельности не даёт абсолютной защиты. Даже круглосуточный мониторинг не исключает атаку, а резервная копия не предотвращает проникновение. Их задача — снизить риски, быстрее обнаружить проблему и сократить время восстановления.
Мы работаем с сайтами и их владельцами десятки лет. За это время стало очевидно: техническое сопровождение требует постоянного внимания, а не только реакции на сообщения об ошибках. Поэтому в рамках согласованного обслуживания мы берём на себя технические задачи, которые иначе владельцу пришлось бы контролировать самостоятельно.
Подробнее об условиях сопровождения можно узнать на странице сопровождения сайтов.
Ограничение зарубежного трафика в Беларуси: что происходит с сайтами
На фоне обнаружения критических уязвимостей PHP белорусским хостинг-провайдерам было объявлено об ограничении входящего трафика из-за пределов Республики Беларусь. В опубликованном уведомлении причиной названа необходимость снизить последствия кибератак, связанных с эксплуатацией CVE-2026-109618 и CVE-2026-109619.
Согласно этому уведомлению, доступ к размещённым в Беларуси сайтам из других сегментов интернета мог быть ограничен, при этом доступ из доверенных сетей крупных поисковых роботов, включая Google и Яндекс, предполагалось сохранить.
Информация о сроках снятия ограничений должна была обновиться 22 октября 2026 года в 10:00 (UPD: но не обновилась). Само по себе объявление этого времени не подтверждает, что ограничения уже сняты. Актуальный статус необходимо уточнять у хостинг-провайдера и проверять с внешних сетей.
Для владельцев сайтов здесь есть несколько важных нюансов.
Доступность сайта для людей и поисковых роботов может различаться
Если посетители из других стран не могут открыть сайт, это не обязательно означает, что его сервер полностью отключён. Причина может заключаться в ограничении сетевого доступа, а не в ошибке CMS или PHP.
Обратная ситуация тоже возможна: сайт открывается у владельца из Беларуси, но недоступен пользователям из других стран. Проверка только с одного компьютера не позволяет сделать вывод о доступности ресурса для всей аудитории.
Сохранение доступа для поисковых роботов не гарантирует сохранение позиций
Даже если доступ Googlebot и других поисковых роботов сохраняется, необходимо учитывать фактическую доступность страниц, ответы сервера и возможность нормального обхода сайта. Отдельно следует проверять, какие именно сети и запросы доступны при действующих ограничениях.
Если поисковый робот получает успешный ответ, а пользователи из отдельных стран не могут открыть сайт, последствия для поисковой видимости и пользовательского трафика будут зависеть от продолжительности ограничений, конфигурации ресурса и поведения поисковой системы.
Что проверить владельцу сайта
- Доступен ли сайт из Беларуси и из других стран.
- Какой HTTP-статус получает сервер при обращении к основным страницам.
- Могут ли поисковые роботы получить содержимое страниц.
- Не появились ли ошибки обхода в Google Search Console и Яндекс Вебмастере.
- Сохраняется ли доступность форм, API и внешних интеграций.
- Изменились ли количество посещений, источники трафика и число заявок.
Не следует сразу менять DNS, переносить сайт на другой сервер или перестраивать SEO-конфигурацию только на основании сообщения об ограничении трафика. Сначала нужно установить, какие именно соединения ограничены, как долго действует мера и затрагивает ли она целевую аудиторию сайта.
Как ограничения доступа могут повлиять на SEO
Поисковое продвижение зависит не только от контента и ссылок. Google должен иметь возможность регулярно получать страницы, анализировать их содержимое и проверять технические сигналы сайта. Если страницы становятся недоступными, поисковый робот может фиксировать ошибки и сокращать частоту обхода.
При кратковременных сетевых ограничениях не следует автоматически ожидать потери позиций. Риск зависит от продолжительности проблемы, характера ответов сервера, доступности роботов и того, какие страницы затронуты.
Особое внимание необходимо уделить следующим показателям:
- HTTP-ответы. Ошибки 5xx могут указывать на проблемы сервера, а 403 — на запрет доступа. Но код ответа необходимо интерпретировать с учётом причины ограничения.
- Доступность ключевых страниц. В первую очередь проверяют страницы, которые привлекают органический трафик и приносят заявки.
- Обход сайта. Важно убедиться, что поисковые роботы могут получать содержимое, а не только загружать главную страницу.
- Индексация. Нужно отслеживать новые ошибки, изменения количества проиндексированных страниц и сообщения в инструментах для веб-мастеров.
- Органический трафик. Снижение посещаемости необходимо сопоставлять с датами ограничений, техническими журналами и другими изменениями на сайте.
Отдельно следует помнить, что доступность сайта для Googlebot не равнозначна доступности для всех пользователей. Поисковая система может продолжать обход страниц, пока часть потенциальных клиентов не может попасть на сайт.
Поэтому технический контроль и SEO-аналитика должны работать совместно. В BMG.BY мы рассматриваем техническое состояние ресурса как одну из составляющих поискового продвижения. Если требуется оценить влияние доступности и ошибок сервера на органический трафик, можно обратиться за SEO-продвижением и технической оптимизацией сайта.
Что делать, если сайт уже взломан
Если обнаружены подозрительные страницы, неизвестные файлы, неожиданные перенаправления или посторонние административные учётные записи, одной смены версии PHP недостаточно. Необходимо проверить, не получил ли злоумышленник доступ к сайту до установки обновления.
Рекомендуемый порядок действий:
- Ограничить дальнейший доступ злоумышленника. В зависимости от ситуации временно ограничивают доступ к административной части, отзывают скомпрометированные учётные данные и применяют другие меры с учётом архитектуры проекта.
- Сохранить журналы и сведения об инциденте. Они могут помочь установить время проникновения, затронутые файлы и использованные учётные записи.
- Установить исправленную версию PHP. Одновременно следует проверить состояние остальных серверных компонентов.
- Провести проверку файлов и базы данных. Необходимо искать посторонние скрипты, изменённые файлы, неизвестные учётные записи и подозрительные записи в базе данных.
- Устранить причину проникновения. Помимо обновления PHP, нужно закрыть другие обнаруженные уязвимости и пересмотреть права доступа.
- Восстановить сайт из проверенной копии при необходимости. Перед восстановлением важно убедиться, что выбранная копия не содержит вредоносных изменений.
- Проверить работу сайта после очистки. Следует протестировать основные функции, формы, интеграции и доступность страниц.
Если сайт используется для приёма заявок, продаж или обработки персональных данных, при расследовании инцидента необходимо отдельно оценить возможную утечку информации и обязательства по уведомлению затронутых лиц или уполномоченных органов.
Не стоит удалять подозрительные файлы без предварительной фиксации обстоятельств инцидента. Такое действие может затруднить выяснение причины взлома, а оставленный злоумышленником механизм повторного доступа позволит атаковать сайт снова.
Для восстановления и технической проверки можно обратиться за ремонтом и модернизацией сайта. Конкретный состав работ определяется после оценки состояния проекта.
Кто должен отвечать за безопасность сайта
У владельца сайта есть несколько вариантов: самостоятельно заниматься техническим обслуживанием, поручить его штатному специалисту или передать задачи внешней веб-студии. Выбор зависит от сложности проекта и доступных ресурсов.
Самостоятельное обслуживание требует не только доступа к панели управления. Необходимо следить за обновлениями, совместимостью компонентов, резервными копиями, журналами ошибок и состоянием серверной инфраструктуры. Если эти задачи выполняются от случая к случаю, часть рисков остаётся незамеченной.
При работе со штатным специалистом важно определить его ответственность: кто устанавливает обновления, кто проверяет резервные копии, кто реагирует на инциденты и кто восстанавливает сайт после сбоя.
При передаче сопровождения веб-студии нужно заранее согласовать состав услуг, время реакции, доступность специалистов, порядок резервного копирования и действия при инцидентах. Формулировка «сайт находится на обслуживании» сама по себе не раскрывает, какие работы действительно выполняются.
BMG.by — небольшая семейная веб-студия, которая работает напрямую с заказчиками, без посредников. Мы не строим работу на поточном обслуживании десятков проектов одним специалистом. Для нас важнее контролировать согласованный объём задач и понимать техническое состояние каждого сайта, с которым мы работаем.
Мы занимаемся разработкой, сопровождением и продвижением сайтов. Это позволяет учитывать не только работоспособность кода, но и влияние технических изменений на страницы, индексацию, формы заявок и другие функции ресурса.
Посмотреть примеры выполненных работ можно в портфолио BMG.by и разделе кейсов по разработке и продвижению сайтов.
Как BMG.by помогает поддерживать сайты в рабочем состоянии
Мы рассматриваем сопровождение как постоянную техническую работу, а не как разовую услугу после возникновения проблемы. Конкретные действия зависят от проекта и согласованного перечня работ.
В рамках разработки и сопровождения сайтов мы уделяем внимание следующим направлениям:
- Техническое состояние. Проверка работоспособности страниц, форм и других важных функций сайта.
- Обновления. Контроль актуальности CMS, расширений и других компонентов с учётом совместимости.
- Резервное копирование. Создание копий файлов и базы данных в соответствии с принятой схемой обслуживания.
- Мониторинг. Контроль доступности и анализ выявленных технических проблем в пределах настроенных средств наблюдения.
- SEO. Контроль технических факторов, которые могут влиять на обход, индексацию и поисковую видимость страниц.
- Восстановление и доработка. Устранение обнаруженных проблем и адаптация сайта к изменившимся требованиям.
Мы также принимаем обращения по техническим вопросам в любое время суток. При этом формат обслуживания, доступность специалистов и сроки реакции должны соответствовать согласованным условиям конкретного проекта. Круглосуточная возможность обратиться за помощью не равнозначна обещанию мгновенного устранения любой неисправности.
Если вам нужна не отдельная установка обновления, а постоянный контроль технического состояния сайта, изучите условия услуг BMG.by. После оценки проекта можно определить, какие задачи необходимо выполнять регулярно, а какие потребуют отдельной доработки.
Что проверить владельцу сайта прямо сейчас
Если ваш сайт работает на PHP, рекомендуем начать с конкретных действий:
- Узнать точную версию PHP, которая обрабатывает запросы сайта.
- Проверить наличие исправлений для CVE-2026-109618 и CVE-2026-109619.
- При необходимости перейти на поддерживаемую исправленную версию PHP после проверки совместимости.
- Создать резервную копию файлов и базы данных.
- Проверить работу ключевых страниц и функций после обновления.
- Убедиться, что нет признаков уже состоявшегося проникновения.
- Проверить доступность сайта из Беларуси и других стран с учётом актуального статуса ограничений трафика.
- Проверить сообщения Google Search Console и Яндекс Вебмастера, а также серверные журналы.
- Определить, кто отвечает за дальнейшие обновления, мониторинг и восстановление.
Не нужно ждать появления ошибок или жалоб посетителей. При критических уязвимостях правильный порядок действий — установить состояние системы, устранить подтверждённые риски и проверить результат.
Если вы не знаете, какая версия PHP используется на вашем сайте, давно не обновляли CMS или не уверены в актуальности резервных копий, начните с технической оценки проекта. Специалисты BMG.by помогут определить необходимые работы по разработке, сопровождению и продвижению сайта.