За одну неделю октября разработчикам пришлось срочно обновлять PHP, Node.js, Java и DNS-сервер BIND, менять сертификаты одного из удостоверяющих центров и проверять, не попали ли к ним заражённые пакеты из PyPI и npm. Поток настолько плотный, что вопрос «надо ли обновляться?» сменился другим: что обновлять первым, а с чем, наоборот, не торопиться.
Коротко
- 21 октября вышли исправления сразу для PHP, Node.js и BIND, а 23 октября PHP сообщил о ещё одной, менее опасной уязвимости.
- Компрометация ключей eMudhra потянула за собой внеплановое обновление Java: проблема одного удостоверяющего центра стала проблемой всех Java-приложений.
- В те же дни заражённые версии LiteLLM и tensorlake показали обратную сторону: слишком быстрое обновление тоже опасно.
- Выход — не «патчить всё сразу», а сортировать: что доступно из интернета, что уже атакуют и где лежат секреты.
Что произошло за неделю
Удобнее всего восстановить события по дням. Большая часть пришлась на 21 октября.
17–20 октября: ключи eMudhra
Исследователь обнаружил, что закрытые ключи восьми промежуточных сертификатов индийского удостоверяющего центра eMudhra можно подобрать почти мгновенно. Промежуточный сертификат — это звено цепочки доверия между корневым сертификатом и сертификатом сайта. Если его ключ известен посторонним, они теоретически могут выпустить «настоящий» сертификат для чужого домена.
Как пишет The Hacker News, Chrome заблокировал шесть промежуточных TLS-сертификатов за несколько часов, а Mozilla 20 октября решила перестать доверять корню emSign ECC Root CA - G3. Chrome планирует сделать то же самое 27 октября. Под этим корнем около 30 800 действующих сертификатов, почти все выпущены через InCommon, сервис для университетов.
Сама компания объявила, что уходит из глобального бизнеса TLS-сертификатов. По её заявлению, эти ключи никогда не использовались для выпуска сертификатов, а системы не взломаны.
21 октября: PHP, Node.js, BIND, LiteLLM, Railway
- PHP выпустил экстренные исправления двух критических уязвимостей, получивших имя PHP2Shell. По данным AWS, попытки эксплуатации начались ещё до публикации патча.
- Node.jsзакрыл 10 уязвимостей в ветках 22, 24 и 26, четыре из них высокой критичности. Самая заметная — удалённое выполнение кода (RCE) в декодере сжатия Brotli. RCE означает, что атакующий может заставить сервер выполнить свой код. Ветка 20 и старше исправлений не получила.
- BIND, один из самых распространённых DNS-серверов, получил исправление уязвимости с оценкой 8,1 из 10. Она касается только серверов с включённым механизмом аутентификации GSS-TSIG.
- LiteLLM, популярная Python-библиотека для работы с разными ИИ-моделями, на несколько часов оказалась в PyPI и Docker в заражённой версии 1.107.0. Компания описала инцидент: злоумышленник получил токены разработчиков GitHub и подменил процесс выпуска релизов.
- Railway, облачная платформа для деплоя, сообщила, что посторонние могли получить доступ к переменным окружения клиентов, то есть к API-ключам и паролям. Компания попросила всех клиентов сменить секреты.
22–23 октября: Java и новая уязвимость PHP
Oracle выпустила внеплановое обновление Java с оценкой 9,1, которое добавляет скомпрометированные сертификаты eMudhra в список недоверенных. По данным SecurityOnline, затронуты Java SE 8, 11, 17, 21, 25 и 27, а также GraalVM.
23 октября PHP опубликовал уведомление о новой уязвимости CVE-2026-115560. Как пишет The Hacker News, она затрагивает только приложения с редкой настройкой сессий, экстренного патча не будет, а временная мера та же, что для PHP2Shell.
Вся неделя одной строкой: три критичных компонента веб-стека, один удостоверяющий центр и две атаки на цепочку поставок за семь дней.
Почему «просто обновиться» не работает
Из этих событий складываются две проблемы, которые тянут в разные стороны.
Первая — уязвимости. С ними всё ясно: чем дольше сервер работает на старой версии, тем выше риск. Случай PHP показал, что атаки могут начаться раньше, чем выйдет патч.
Вторая — атаки на цепочку поставок. Цепочка поставок — это всё, из чего собирается ваше приложение: библиотеки, образы контейнеров, сборочные конвейеры. В случае LiteLLM пострадали именно те, кто ставил «последнюю версию» без фиксации. Заражённая версия лежала в PyPI примерно с 11:39 до 13:23 UTC, а Docker-образы с тегом latest — до 14:20 UTC.
Похожая история случилась 8 октября с npm-пакетом tensorlake. Как выяснили в Endor Labs, вредоносный релиз прошёл через штатный конвейер проекта и получил настоящую подпись происхождения (provenance). Такая подпись подтверждает, где собран пакет, но не то, что исходный код был чистым.
Если коротко: на уязвимости нужно реагировать быстро, а на новые версии зависимостей — осторожно. Чтобы совместить одно с другим, нужен порядок действий.
Как сортировать обновления: пять шагов
Возьмём условную команду (пример наш, данные об уязвимостях — из официальных уведомлений). У неё API на Node.js 22, внутренний сервис на Java 17, свой DNS-сервер на BIND, Python-воркер с LiteLLM, а часть сервисов развёрнута на Railway.
Шаг 1. Понять, что у вас стоит
Без списка компонентов любая сортировка превращается в гадание. Такой список называют SBOM — это перечень всех библиотек и их версий в продукте.
Важно учитывать не только код, но и рантаймы внутри контейнеров и приложений. Java, встроенная в чужой продукт, тоже нуждается в обновлении.
Шаг 2. Оценить реальную досягаемость
Оценка CVSS (те самые 9,1 или 8,1 из 10) говорит, насколько плоха уязвимость в теории. Для решения важнее другое: может ли атакующий до неё дотянуться.
- Node.js: уязвимы приложения, которые распаковывают Brotli-данные от недоверенной стороны, включая ответы, полученные через fetch(). API нашей команды принимает внешние запросы, значит, обновляем сегодня.
- BIND: GSS-TSIG у команды не включён, поэтому эта уязвимость её не касается. Обновление можно поставить в ближайшее плановое окно.
- Java: сервис ходит по HTTPS к внешним партнёрам, поэтому список недоверенных сертификатов должен быть свежим. Это обновление ставим в приоритете.
Шаг 3. Свериться с внешними сигналами
Есть два полезных источника. Каталог KEV американского агентства CISA перечисляет уязвимости, которые уже используются в реальных атаках. Если CVE есть в KEV, её закрывают в первую очередь.
Вторая метрика — EPSS. Это оценка вероятности того, что уязвимость начнут эксплуатировать в ближайшие 30 дней. У свежих CVE она бывает обманчиво низкой: например, для Java-уязвимости SecurityOnline приводит значение 0,4%. Низкая цифра объясняется тем, что для атаки нужно перехватывать трафик. Но для сервиса, который постоянно ходит к внешним партнёрам, это не повод откладывать обновление.
Шаг 4. Разобраться с зависимостями и секретами
- Фиксировать версии в lock-файлах и не тянуть latest в продакшен. Lock-файл записывает точные версии всех зависимостей.
- Для обычных релизов, которые не закрывают уязвимости, выдерживать паузу в несколько дней.
- Если заражённая версия всё же была установлена, LiteLLM советует считать секреты украденными и менять всё, до чего мог дотянуться хост. Только переустановки пакета недостаточно.
- Клиентам Railway — сменить все ключи, не дожидаясь подтверждения, что их аккаунт затронут.
Шаг 5. Проверить, что всё действительно обновилось
Обновление считается завершённым, когда новая версия работает везде: в образах, в CI, на резервных серверах. С сертификатами есть отдельная ловушка.
Аналитик IDC Сакши Гровер предупреждает, что замена сертификата сайта не решает всё. Java-хранилища ключей, прокси, балансировщики и встроенные устройства держат свои списки доверия и могут продолжать доверять отозванным сертификатам.
Весь цикл одной строкой: инвентаризация → досягаемость → внешние сигналы → зависимости и секреты → проверка, что обновилось везде.
Ограничения и критика
Не каждая громкая новость означает немедленную угрозу. Исследователь безопасности Маркус Хатчинс усомнился в заявлениях, что рабочий эксплойт PHP2Shell легко собрать с помощью ИИ.
В другой публикации он отметил, что публичные демонстрации пока работают только на конкретных версиях PHP с определённым ПО, а эксплуатации в реальных атаках сам он не наблюдал.
При этом данные AWS о попытках атак до публикации патча показывают, что расслабляться тоже рано.
Есть вопросы и к самой сортировке. CVSS часто завышает или занижает реальный риск, а EPSS для свежих уязвимостей опирается на мало данных. KEV обновляется уже после того, как атаки замечены. Ни одна метрика не заменяет знания своей инфраструктуры.
Открытый вопрос: кто будет оплачивать такой темп? Большая часть исправлений этой недели пришлась на проекты, которые держатся на небольших командах и волонтёрах.
Почему это происходит сейчас
Одна из причин — уязвимостей просто стало больше. FIRST, международное объединение команд реагирования на инциденты, ещё в июне прогнозировал около 66 000 CVE за 2026 год. Среди причин он называл ИИ-инструменты, которые находят ошибки в коде самостоятельно.
Вторая причина — концентрация. Тысячи компаний зависят от одних и тех же компонентов: PHP, Node.js, Java и нескольких удостоверяющих центров. Ошибка в одном месте сразу становится общей проблемой, как показала связка eMudhra и Java.
Что это значит для разработчиков и бизнеса
Для разработчиков это значит, что обновления перестают быть разовой задачей. Нужны фиксированные версии, понятный список зависимостей и автоматизация.
С сертификатами то же самое. ACME — протокол автоматического выпуска сертификатов, а ARI — его расширение, через которое удостоверяющий центр может попросить досрочную замену.
Стоит проверить, поддерживает ли ARI ваш ACME-клиент. По данным Chrome, без него стандартные клиенты могут не заменить сертификат вне обычного окна продления.
Для бизнеса важнее всего время реакции. Яш Кадакия из компании Security Brigade в комментарии Computerworld сформулировал это так: «Можно отдать на аутсорс сервис, но нельзя отдать на аутсорс ответственность». Это касается и облачных платформ, и удостоверяющих центров, и библиотек с открытым кодом.
Вывод
«Чёрный октябрь» вряд ли окажется разовым всплеском. Скорее он показывает новый режим, в котором уязвимости и атаки на зависимости идут параллельно. Выигрывают команды, которые знают свой стек и умеют быстро отличить «обновить сегодня» от «обновить в плановом окне».
По нашей оценке, главный урок недели не в конкретных CVE. Он в том, что скорость обновлений и осторожность с зависимостями теперь нужно планировать вместе.