Интернет начал трещать по швам

За несколько дней сразу несколько базовых компонентов веб-инфраструктуры оказались в центре крупных инцидентов. В PHP обнаружили критические ошибки, GitLab выпустил исправление для уязвимости с максимальной оценкой CVSS, Node.js закрыл опасную ошибку в декодере Brotli, а опубликованный релиз LiteLLM оказался заражённым. Параллельно выяснилось, что криптографические ключи нескольких промежуточных центров сертификации eMudhra были сгенерированы с недостаточной случайностью.

Это не одна общая атака и не доказательство того, что «взломан весь интернет». Речь о нескольких независимых событиях, совпавших по времени и показавших, насколько много сервисов зависит от небольшого числа базовых компонентов.

Главное: проверьте версии PHP, GitLab, Node.js и NGINX; выясните, не использовали ли заражённые артефакты LiteLLM; проверьте TLS-сертификаты и секреты. Если обновление невозможно, ограничьте доступ к уязвимому сервису или временно выведите его из публичной сети.

Хронология

• 14 октября — NGINX. Выпущены обновления, закрывающие пять уязвимостей. Три ошибки безопасности памяти в определённых конфигурациях могли приводить к отказу в обслуживании и при дополнительных условиях — к выполнению кода.
• 17 октября — eMudhra. Chrome Root Program получил сообщение о проблеме с закрытыми ключами восьми промежуточных удостоверяющих центров. Браузерные команды начали блокировать затронутые сертификаты.
• 21 октября — PHP2Shell. Раскрыты две уязвимости в ядре PHP: CVE-2026-109618 и CVE-2026-109619. Они могут позволять удалённое выполнение кода без аутентификации или раскрытие памяти процесса.
• 21 октября — GitLab. Выпущены исправления для CVE-2026-110264 с оценкой CVSS 10.0. Уязвимость затрагивает self-managed-инсталляции и версии, уходящие корнями к GitLab 7.0 (2014 год).
• 21 октября — Node.js. Обновления безопасности для веток 22.x, 24.x и 26.x закрыли, среди прочего, CVE-2026-111497 — ошибку декодера Brotli, потенциально приводящую к удалённому выполнению кода.
• 21 октября — LiteLLM. Версия 1.107.0 появилась на PyPI с вредоносной нагрузкой. Пакет находился там примерно с 11:39 до 13:23 UTC; затронутые Docker-образы оставались скомпрометированными дольше — до 14:20 UTC.
• 21–22 октября — ConnectWise. Microsoft описала кампанию, в которой связанная с Китаем группа Storm-0940 использовала AI-powered инструмент ARTEX при атаке на ConnectWise Cloud Backup и дальнейших попытках доступа к организациям.

PHP2Shell: проблема в самом PHP

PHP2Shell — название двух уязвимостей ядра PHP, опубликованных 21 октября 2026 года: CVE-2026-109618 и CVE-2026-109619. Их оценка достигает CVSS 9.2.

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

Один сценарий позволяет удалённому неаутентифицированному атакующему добиться выполнения кода. Другой связан с раскрытием памяти процесса, где могут оказаться токены, пароли, API-ключи и другие чувствительные данные. Реальная эксплуатируемость зависит от версии, сборки и конфигурации.

Уязвимости обнаруживали несколько исследовательских команд независимо друг от друга, включая Calif, Wiz и OpenAI. Исследователи Wiz описали, как современные AI-модели помогли преодолеть сложность анализа старого кода и построить цепочку эксплуатации. Это не означает, что ИИ автоматически взламывает любой PHP-сайт: он может существенно ускорить отдельные этапы поиска и проверки ошибок.

Что делать: установите исправленный выпуск PHP для вашей ветки, сверившись с официальными рекомендациями PHP и поставщика ОС или контейнерного образа. Если быстро обновиться нельзя, временно изолируйте публичный PHP-сервис либо ограничьте доступ через reverse proxy/WAF. WAF — временная мера, а не замена патчу.

• PHP: https://www.php.net/
• Анализ Wiz: https://www.wiz.io/blog/php2shell-php-rce
• Информация NCSC-NL: https://github.com/NCSC-NL/php2shell

Чек-лист для сайтов на PHP

1. Найдите все экземпляры PHP. Проверьте production, staging, виртуальные машины, контейнеры, cron-задачи, панели хостинга и забытые сайты.
2. Уточните фактическую версию. Сверьте CLI и PHP-FPM/Apache: они могут отличаться. Проверьте версию внутри контейнера, а не только на хосте.
3. Обновите до исправленной версии. Используйте официальный security-релиз для поддерживаемой ветки PHP. Если PHP обновляет хостинг-провайдер, запросите подтверждение.
4. Если обновление задерживается — уменьшите экспозицию. По возможности временно отключите публичный доступ, ограничьте входящие запросы и примените проверенные правила WAF.
5. Проверьте признаки компрометации. Просмотрите access/error-логи веб-сервера, PHP-FPM, приложения, файлы, cron, процессы, исходящие соединения и изменения учётных записей.
6. Ротируйте секреты при подозрении на доступ. В первую очередь — пароли БД, API-токены, облачные ключи, SSH-ключи и production-секреты. Делайте это с чистой системы после ограничения доступа атакующего.
7. Проверьте плагины и зависимости. WordPress, Drupal, Joomla и Magento не означают автоматическую компрометацию, но все их экземпляры на уязвимом PHP нужно инвентаризировать.
8. Зафиксируйте результат. Запишите версии до и после обновления, время работ, проверенные логи и оставшиеся исключения.

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

GitLab: CVSS 10.0 и риск для self-managed-серверов

21 октября GitLab опубликовал исправления для CVE-2026-110264, уязвимости с оценкой CVSS 10.0. При определённых условиях она позволяет неаутентифицированному пользователю выполнять произвольный код на self-managed-сервере. Причина связана с целочисленным переполнением при компиляции специально сформированного регулярного выражения.

Затронутый диапазон начинается с GitLab 7.0 (2014 год). GitLab.com уже обновлён поставщиком; владельцам собственных инсталляций необходимо самостоятельно проверить версию и обновиться. На момент публикации не сообщалось о подтверждённой эксплуатации именно этой уязвимости. CVSS 10.0 означает максимальную оценку риска, но не означает, что каждый сервер можно взломать при любых настройках.

Исправленные версии:

Важно: обновление от 12 октября не закрывает CVE-2026-110264. Если GitLab уже обновляли в середине месяца, проверьте версию повторно.

• GitLab: https://about.gitlab.com/releases/
• Обзор CVE-2026-110264: https://thehackernews.com/2026/10/critical-gitlab-flaw-cvss-100-could.html

Node.js: RCE в декодере Brotli

В релизах безопасности от 21 октября Node.js перечислил несколько уязвимостей в ветках 22.x, 24.x и 26.x. Среди них — CVE-2026-111497, ошибка записи за пределы буфера в декодере Brotli, потенциально позволяющая удалённое выполнение кода.

Уязвимость обнаружили при участии OpenAI Codex Security; исправления подготовили сопровождающие Node.js. Это пример того, как AI-инструменты могут помогать находить ошибки в реальном коде, но исправления всё равно требуют проверки и выпуска сопровождающими проекта.

Опубликованные исправленные релизы:

• Node.js 22.x — 22.23.4
• Node.js 24.x — 24.22.1
• Node.js 26.x — 26.12.1

Node.js 20.x и более старые ветки уже не получают обычные обновления безопасности; планируйте переход на поддерживаемую ветку. Проверьте также контейнерные образы, serverless-функции, CI runners и приложения, которые используют Node.js транзитивно.

• Официальный бюллетень: https://nodejs.org/en/blog/vulnerability/october-2026-security-releases

NGINX: пять уязвимостей

14 октября NGINX выпустил версии 1.30.6 (stable) и 1.31.7 (mainline), исправляющие пять уязвимостей. Три ошибки связаны с безопасностью памяти и получили оценку CVSS v4.0 9.2 от F5. В определённых конфигурациях они могут приводить к падению worker-процесса, отказу в обслуживании и потенциально к выполнению кода, если защитные механизмы вроде ASLR отключены или обходятся.

Ещё две проблемы связаны с обработкой HTTP/3 и TLS-сессий. Эксплуатация зависит от конкретных директив и настроек: нельзя утверждать, что любой стандартный NGINX одинаково уязвим. Но конфигурационная зависимость — не повод откладывать обновление.

Что проверить:

• обновить NGINX Open Source до 1.30.6 или 1.31.7 либо более новой исправленной версии;
• для NGINX Plus, Ingress Controller, Gateway Fabric и других продуктов F5 свериться с отдельными рекомендациями поставщика;
• проверить использование alias вместе с rewrite, $request_filename, map с регулярными выражениями, AIO и SSI;
• после обновления протестировать конфигурацию и перезапустить сервис согласно эксплуатационной процедуре.
• Официальные advisories: https://nginx.org/en/security_advisories.html
• Рекомендации CSA Singapore: https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-150/

LiteLLM: заражённый релиз в цепочке поставки

21 октября атакующие скомпрометировали процесс публикации LiteLLM — Python-библиотеки и прокси для работы с провайдерами языковых моделей. На PyPI появился пакет litellm==1.107.0, содержавший вредоносный код для кражи учётных данных и загрузки дополнительных инструментов удалённого доступа. Заражённые образы также распространялись через Docker Hub и GitHub Container Registry.

По данным команды LiteLLM, пакет находился на PyPI примерно с 11:39 до 13:23 UTC. Затронутые Docker-теги были скомпрометированы примерно с 11:46 до 14:20 UTC. Официальный исходный тег GitHub не содержал вредоносные файлы: опубликованные артефакты были собраны из репозитория, контролируемого атакующим.

Это важный нюанс: проверка только исходного кода или Git-тега не всегда гарантирует безопасность опубликованного пакета. Нужно проверять происхождение артефакта, процесс сборки и конкретный digest, попавший в production.

Если вы могли установить заражённый LiteLLM

1. Проверьте журналы установки и сборки: litellm==1.107.0, а также Docker-образы v1.107.0, latest, main-latest и main-stable, использованные в указанное окно.
2. Если такой пакет или образ запускался, считайте окружение потенциально скомпрометированным до завершения проверки.
3. Изолируйте затронутый workload и сохраните логи, сведения о пакетах и container digests.
4. С чистой машины отзовите и замените секреты, доступные процессу: облачные ключи, токены AI-провайдеров, API-токены, SSH-ключи и учётные данные CI/CD.
5. Проверьте исходящие соединения, процессы, автозапуск, изменения файлов и действия в облачных журналах.
6. Закрепите проверенный безопасный релиз. Команда LiteLLM рекомендовала временно использовать 1.106.2 или более раннюю явную версию, опубликованную до инцидента; перед развёртыванием перепроверьте официальное уведомление.

По заявлению LiteLLM, частный enterprise-релиз не был затронут. Это не относится автоматически к сторонним образам или самостоятельно собранным вариантам.

• Официальное уведомление: https://docs.litellm.ai/blog/security-incident-oct-21-2026
• Анализ Datadog Security Labs: https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-docker/

eMudhra: слабая случайность в ключах доверия

Восемь промежуточных сертификатов удостоверяющих центров eMudhra оказались связаны с закрытыми ключами, созданными с недостаточной криптографической случайностью. В опубликованном разборе указано, что некоторые ключи эллиптической кривой P-384 имели значения, которые можно было восстановить по открытым данным сертификата. Обладая соответствующим закрытым ключом, злоумышленник мог бы выпускать поддельные сертификаты и выдавать себя за чужие сайты.

Это проблема инфраструктуры доверия, а не обычная ошибка веб-приложения. Chrome заблокировал затронутые промежуточные сертификаты через CRLSet; Mozilla также заблокировала их в Firefox. По данным eMudhra, затронутые промежуточные центры, за исключением одного, не были введены в production и не выпускали конечные сертификаты. Расследование продолжалось.

Владельцам сайтов следует проверить цепочку TLS-сертификата. Google предупредил, что удаление связанного корневого сертификата из Chrome Root Store может повлиять на сайты, которые продолжают использовать соответствующую иерархию. Если сертификат цепляется к затронутому корню, получите новый сертификат из доверенной иерархии и установите его до запланированного изменения доверия.

• Google Chrome Security: https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/
• Заявление eMudhra: https://emudhra.com/en/post/certificate-security-incident

ConnectWise: AI-агенты используются и атакующими

Microsoft описала кампанию группы Storm-0940, связанной с Китаем, в которой использовался ARTEX — открытый фреймворк для тестирования на проникновение с возможностью автоматизировать задачи с помощью AI-моделей. Кампания затронула ConnectWise Cloud Backup и включала попытки дальнейшего доступа к организациям.

По данным Microsoft, атаки были направлены на организации разных отраслей. Большинство попыток не увенчалось успехом, однако в ряде случаев злоумышленники получили привилегированный доступ к облачным средам, который мог сохраниться после первоначальной очистки. В сообщениях об инциденте фигурируют попытки входа более чем в 2 250 Microsoft 365 tenants. Это число обозначает масштаб попыток, а не подтверждённое успешное проникновение во все эти среды.

Организациям, использующим ConnectWise, Microsoft 365 или интеграции резервного копирования, важно не ограничиваться сбросом пароля: проверьте журналы входов, OAuth-приложения, согласия приложений, роли администратора, активные сессии, service principals и изменения политик доступа.

• Reuters: https://www.reuters.com/technology/chinese-linked-hackers-compromise-connectwise-target-hundreds-global-attack-2026-10-21/

Почему всё это важно

У событий разные причины: ошибки управления памятью в C/C++, целочисленное переполнение, ошибки обработки сжатых данных, компрометация процесса сборки, слабая генерация криптографических ключей и злоупотребление автоматизированными инструментами атак. Объединяет их другое — современная инфраструктура построена из множества взаимозависимых слоёв.

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

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

Универсальный чек-лист на сегодня

• Составить список публично доступных сервисов и версий PHP, GitLab, Node.js и NGINX.
• Обновить затронутые компоненты и проверить, что обновление действительно применилось.
• Проверить контейнерные образы и зависимости, особенно LiteLLM и связанные артефакты.
• Если использовался заражённый релиз, изолировать систему, отозвать секреты и провести расследование.
• Проверить TLS-цепочки и заменить сертификаты, зависящие от затронутой иерархии eMudhra.
• Просмотреть логи на признаки эксплуатации, необычные процессы, исходящие соединения и подозрительные входы.
• Проверить MFA, OAuth-приложения, сервисные учётные записи, права доступа и резервные копии.
• Если невозможно быстро установить патч, временно ограничить или отключить доступ к уязвимому сервису.
• Подписаться на официальные security advisories используемых продуктов и назначить ответственного за повторную проверку.

В Великобритании власти сообщили, что 32 государственных сервиса временно были недоступны, а ещё четыре — частично недоступны в рамках защитных мер. Это не означает, что все они были взломаны: власти объяснили отключения предосторожностью на время обновления и проверки систем. Иногда временная недоступность безопаснее, чем сохранение публичного доступа к потенциально уязвимому сервису.

Источники и дальнейшее чтение

1. PHP / PHP2Shell: Wiz Research, NCSC-NL, PHP
2. GitLab CVE-2026-110264: The Hacker News, GitLab releases
3. Node.js: Security releases, 21 October 2026
4. NGINX: Official security advisories, Singapore CSA
5. LiteLLM supply-chain incident: Official incident report, Datadog Security Labs
6. eMudhra certificates: Google Chrome Security, eMudhra statement
7. ConnectWise / ARTEX: Reuters

Материал подготовлен по открытым публикациям, доступным на 22 октября 2026 года. Статусы инцидентов, исправленные версии и рекомендации могут меняться; перед действиями сверяйтесь с официальными уведомлениями поставщиков. Описанные инциденты не означают, что каждый перечисленный продукт был успешно взломан.