Безопасность
Чёрный октябрь 2026 в кибербезопасности: что проверить владельцу сайта
В октябре 2026 года владельцы сайтов столкнулись сразу с несколькими разными угрозами: критическими уязвимостями PHP и Brotli, компрометацией релиза LiteLLM и утечкой секретов из инфраструктуры Railway. В публикациях этот период получил название «чёрный октябрь». За общим названием скрываются отдельные инциденты: у каждого свой механизм, затронутые системы и порядок устранения последствий.
Первое действие для бизнеса — выяснить, какие из этих компонентов используются на сайте и в его инфраструктуре. Затем обновить уязвимое ПО, отозвать потенциально раскрытые ключи и проверить признаки постороннего доступа. Работающий сайт и зелёный значок HTTPS не подтверждают, что система безопасна.
Материал подготовлен по сведениям, проверенным 29 октября 2026 года. Статус расследований и рекомендации разработчиков могут обновляться.
Что произошло в «чёрном октябре»
Ниже — четыре подтверждённых эпизода, которые полезно разобрать владельцу сайта. Это не полный каталог октябрьских инцидентов.
| Компонент или сервис | Характер проблемы | С чего начать проверку |
|---|---|---|
| PHP | Критические ошибки с возможностью удалённого выполнения кода | Узнать версию и сборку PHP, которую использует веб-сервер |
| Brotli | Уязвимость декодера сжатых данных | Найти приложения и образы, содержащие затронутую библиотеку |
| Railway | Доступ злоумышленника к части внутренних систем и секретов | Проверить уведомления провайдера и заменить затронутые учётные данные |
| LiteLLM | Публикация скомпрометированного релиза | Проверить историю установок, сборок и запущенных контейнеров |
PHP2Shell: почему обновления CMS недостаточно
21 октября разработчики PHP выпустили исправления для CVE-2026-109618 и CVE-2026-109619. Эти уязвимости могут позволить удалённое выполнение кода без аутентификации. В официальном предупреждении перечислены установки PHP, обслуживающие веб-запросы, включая PHP-FPM и Apache с mod_php.
Исправления вошли в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. В пакетах Linux исправление может быть перенесено в сборку с другим номером: проверять нужно уведомление поставщика пакета. Для Windows 26 октября появились пересобранные пакеты с суффиксом -1, включающие также исправление Brotli. Есть и дополнительное уведомление PHP от 23 октября об особой комбинации настроек обработки сессий: исполнитель должен учесть его при проверке конфигурации. Официальные сообщения PHP за октябрь.
Если сайт работает на WordPress, 1С-Битрикс или другой PHP-системе, обновление её модулей не заменяет обновление серверного PHP. Попросите хостинг или администратора подтвердить исправленную сборку именно для сайта. Версия PHP в командной строке может отличаться от версии, обслуживающей посетителей.
Brotli: проверять нужно обработку входящих данных
Brotli — технология сжатия данных. В октябре разработчики опубликовали исправления CVE-2026-111497 для декодера: в релизах 1.0.10, 1.1.1 и 1.2.1 указано устранение ошибки, допускающей удалённое выполнение кода. Релизы Google Brotli.
Для оценки риска нужно выяснить, обрабатывает ли приложение недоверенные сжатые данные через уязвимый компонент. Наличие сжатия страниц на сайте само по себе не отвечает на этот вопрос. Библиотека может находиться внутри среды выполнения, HTTP-клиента или контейнерного образа, о котором владелец сайта даже не знает.
Управляемый хостинг тоже требует проверки. Например, AWS отдельно описывает статус среды Lambda и её сред выполнения, а для обновлённых базовых образов рекомендует пересборку и повторное развёртывание. Обновление провайдера не всегда означает, что ваш ранее собранный контейнер уже получил исправление. Бюллетень AWS по Brotli.
Railway: почему нужно менять ключи, даже если сайт доступен
В предварительном отчёте Railway сообщила о доступе к внутренним системам и раскрытии секретов части клиентов. Компания рекомендовала клиентам, зарегистрированным до 21 октября, сменить хранившиеся на платформе ключи. При этом, согласно отчёту, работающие приложения оставались доступны; во время реагирования приостанавливались сборки и развёртывания. Предварительный отчёт Railway.
Для владельца сайта это означает проверку переменных окружения: там могут храниться пароли базы данных, почтовые учётные данные, ключи платёжных и ИИ-сервисов. Заменить значение в панели недостаточно. Старый ключ нужно отозвать у его поставщика, новый подключить к приложению, затем проверить работу интеграции.
LiteLLM: риск может прийти через официальное обновление
21 октября через инфраструктуру релизов LiteLLM была опубликована скомпрометированная версия 1.107.0. В разборе причин разработчики связали атаку с административным ключом, ранее попавшим в публичный репозиторий и не отозванным после удаления файла. Через него атакующий получил дальнейший доступ к инфраструктуре разработки. Разбор цепочки атаки LiteLLM.
Проверять нужно не только текущий список зависимостей. Посмотрите историю установок и сборок: опасная версия могла запускаться временно, в том числе в системе автоматической сборки. Если она использовалась, порядок очистки и ротации секретов следует сверить с уведомлением LiteLLM о затронутом релизе.
Как понять, затронут ли ваш сайт
Отправьте исполнителю перечень проверок и попросите результат по каждому пункту. Ответ «у нас всё обновлено» не позволяет оценить, что именно проверяли.
| Что узнать | Что попросить у исполнителя | Какой результат принять |
|---|---|---|
| Версия серверного PHP | Версию, сборку и источник пакета для каждого сайта | Есть ссылка на исправление поставщика и подтверждение применения |
| Наличие Brotli | Перечень сред выполнения, библиотек и контейнеров | Для используемых компонентов установлен статус исправления |
| Использование Railway | Список проектов и категорий хранившихся секретов | Затронутые секреты заменены, старые отозваны |
| Использование LiteLLM | Историю установок, релизов и образов | Проверен период риска, при необходимости выполнены действия разработчика |
| Следы постороннего доступа | Результаты проверки журналов и изменений | Указаны период, источники данных и найденные отклонения |
| Готовность к восстановлению | Дату и результат тестового восстановления | Подтверждено восстановление файлов и базы в отдельной среде |
Секретные значения в такой отчёт включать не нужно. Достаточно названия сервиса, назначения ключа, даты замены и подтверждения отзыва старого доступа.
План действий: от проверки до подтверждения результата
1. Назначьте ответственного и сохраните данные для расследования
Определите, кто координирует работу: администратор, разработчик или специалист по реагированию. Зафиксируйте время обнаружения проблемы и текущие версии компонентов.
Если есть признаки взлома, до очистки сохраните доступные журналы и снимки системы с ограниченным доступом. Приоритет — остановить ущерб, сохранив по возможности сведения, которые помогут понять путь атаки. Перезапись файлов и удаление журналов могут осложнить расследование.
2. Устраните подтверждённую уязвимость
Исполнитель должен выбрать исправленный пакет для вашей среды, проверить совместимость и применить обновление. После этого нужно убедиться, что рабочие процессы и контейнеры действительно используют новую сборку.
Проверьте вход в административную панель, оформление заказа, формы, оплату, передачу заявок в CRM и фоновые задания. Успешная загрузка главной страницы не заменяет проверку этих сценариев. При несовместимости нужен безопасный способ восстановления работы: возврат к заведомо уязвимой сборке нельзя считать завершённым исправлением.
3. Отзовите раскрытые доступы
Составьте список секретов, доступных затронутой системе: база данных, почта, облако, репозиторий, платёжный провайдер, CRM, ИИ-сервисы. Выполняйте замену с доверенного устройства и в очищенной среде. Новый секрет, введённый на всё ещё заражённом сервере, может утечь повторно.
После замены подтвердите две вещи: приложение работает с новыми данными, а старый доступ больше не действует. Не публикуйте ключи и пароли в переписке или отчёте.
4. Проверьте, не оставил ли атакующий доступ
Обновление закрывает уязвимость, но не доказывает, что её не использовали раньше. Проверьте неизвестные административные учётные записи, изменения файлов, подозрительные задания по расписанию, новые ключи доступа, посторонние процессы и необычные исходящие соединения.
Для сайта также проверьте скрытые ссылки, подмену платёжных реквизитов, перенаправления посетителей и посторонние страницы. Каждый найденный объект нужно сопоставить с легитимными изменениями: необычный файл сам по себе ещё не доказывает атаку.
5. Зафиксируйте границы проверки
В отчёте укажите проверенные системы, период журналов, применённые исправления и оставшиеся вопросы. Формулировка «признаков компрометации не обнаружено в доступных данных за указанный период» точнее, чем безусловное «сайт не взломан».
Что делать, если сайт уже взломали
Если появились неизвестные администраторы, вредоносные файлы или подмена содержимого, действуйте как при инциденте. Ограничьте опасный доступ, сохраните доказательства, установите масштаб и восстановите систему из доверенного состояния. После устранения причины замените затронутые секреты и усилите наблюдение.
Восстановление вчерашней копии не гарантирует очистку: взлом мог произойти раньше. Сначала нужно оценить, можно ли доверять выбранной резервной копии и среде, в которую она восстанавливается.
При признаках заражения полезно отдельно поставить задачу на лечение сайта от вирусов, а проверку причин и границ доступа включить в аудит безопасности сайта.
Как снизить последствия следующего инцидента
Проверяйте безопасность по наблюдаемым результатам. Для компонентов назначьте ответственных за обновления и подписку на уведомления разработчиков. Для секретов ограничьте права и отделите доступы разработки от рабочей системы. Для резервных копий проверяйте восстановление в отдельной среде. Для журналов определите срок хранения и события, на которые должен реагировать ответственный.
Заранее составьте карту зависимостей сайта: хостинг, серверная среда, CMS, пакеты, контейнеры, внешние интеграции и поставщики ключей. Во время следующего предупреждения она позволит быстро ответить на главный вопрос: «Это используется у нас — и где именно?»
Проверку такой карты можно начать с задачи по безопасности сайта: определить используемые компоненты, подтвердить исправления и согласовать порядок реагирования. Практический результат — перечень проверенных систем, устранённых проблем и действий, у которых есть ответственный и срок.
