Отслеживайте уязвимости Черного октября от обнаружения до подтвержденного патча

22 октября Сэм Альтман сказал то, что я до сих пор не могу забыть: «Я больше не думаю, что мы сможем исправить все ошибки». Он сказал это как раз тогда, когда вся индустрия придумывала название для этого месяца, по данным The Guardian. Черный октябрь.

Он, пожалуй, прав. Странно признавать такое, когда ты посвятил свою карьеру работе в сфере безопасности и созданию продуктов безопасности, но посмотрите на последние две недели. Две уязвимости удаленного выполнения кода без аутентификации в самом интерпретаторе PHP. Ошибка повреждения памяти в декодере Brotli, поставляемом вместе с Node.js. Восемь ключей центров сертификации, сгенерированных с настолько низкой случайностью, что их можно было восстановить; все они связаны цепочкой с корневым сертификатом, которому доверял пакет certifi для Python. Добавьте к этому взломанный релиз LiteLLM на PyPI и баг в GitLab с оценкой CVSS 10 — и всё это всего за несколько дней (полный обзор здесь).

Вот что, на мой взгляд, упускают из виду. Большинство людей, которые действительно будут исправлять это, вовсе не инженеры по безопасности. Это разработчик, отвечающий за службу оформления заказа. Это дежурный инженер, которого подняли в 2 часа ночи, потому что воркеры php-fpm продолжают падать. Это архитектор, которому на обзоре руководства задают вопрос «уязвимы ли мы?» и у которого есть около десяти секунд на ответ. Это инженерный менеджер, пытающийся понять, какие задачи из спринта придется сдвинуть. Многие из этих людей прямо сейчас держат открытым New Relic во вкладке браузера. Они просто не воспринимают его как место для поиска ответа на этот вопрос.

Так что эта статья для вас. Я расскажу о том, что произошло и почему это так сложно исправить. Затем я покажу вам, как найти уязвимые службы в New Relic и, что еще важнее, как узнать, действительно ли исправление внедрено повсеместно.

Основные выводы

• Уязвимости Черного октября нацелены на среды выполнения ниже уровня кода приложений: критические уязвимости удаленного выполнения кода (RCE), такие как PHP2Shell (CVE-2026-109618, CVE-2026-109619) и Node2Shell (CVE-2026-111497), эксплуатируют базовые среды интерпретаторов, а не прямые зависимости приложений
• New Relic Security RX обеспечивает видимость среды выполнения в реальном времени: используя существующие агенты APM, Security RX обнаруживает активно выполняющиеся версии среды выполнения и библиотеки без дополнительной конфигурации
• Приоритизация реального состояния продакшена и очистка устаревшего ПО: сосредоточьте исправление на активных работающих продакшн-экземплярах, безопасно выводите из эксплуатации неиспользуемые службы для получения быстрых результатов и экономии средств на облако, а также систематически проверяйте развертывание патчей во всех оставшихся рабочих нагрузках в каждой среде
• Проверка развертывания патчей во всех работающих экземплярах: уязвимости остаются помеченными как активные до тех пор, пока каждый работающий под или экземпляр не перестанет сообщать об уязвимой версии, что гарантирует выявление неустраненных крайних случаев или неудачных региональных развертываний до того, как команды безопасности закроют инцидент

Черный октябрь простыми словами

Название прижилось мгновенно. Я могу объяснить проблемы с помощью трех изображений. Забавно и немного жутко, что всегда находится подходящий комикс XKCD на любой случай

Событие

CVE / бюллетень

Что затронуто

Исправлено в

PHP2Shell

CVE-2026-109618 CVE-2026-109619

Установки PHP, обслуживающие веб-запросы (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed)

8.2.35, 8.3.36, 8.4.27, 8.5.12

Node2Shell

CVE-2026-111497 (плюс еще 7 в ветке 24.x)

Node.js 22.x, 24.x, 26.x и все устаревшие линейки (end-of-life)

22.23.4, 24.22.1, 26.12.1

eMudhra / certifi

GHSA-6q48-6c7w-9gw2

certifi >= 2019.03.09, < 2026.10.18

certifi 2026.10.19 (рекомендуется), pip 26.2.2

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

PHP2Shell (CVE-2026-109618 и CVE-2026-109619)

Две ошибки безопасности памяти в ядре PHP, получившие оценку CVSS v4 9.2. Веб-запрос без аутентификации может обратиться к любой из них, и обе приводят к удаленному выполнению кода. В Apache mod_php эксплойт срабатывает до того, как запускается какой-либо код вашего приложения, поэтому ваш код может быть безупречным, и это не спасет. Wiz Research, обнаружившие эти уязвимости с помощью инструментов на базе ИИ, опубликовали технический отчет. PHP лежит в основе примерно 69% веб-сайтов с известным языком на стороне сервера, per W3Techs.

Злоумышленники не стали ждать патча. Приманки-ханипоты MadPot от Amazon зафиксировали первую попытку эксплойта 17 октября, за четыре дня до того, как PHP выпустил исправления 21 октября. Генеральный директор Cloudflare Мэтью Принс заявил, что сеть зафиксировала тысячи попыток за десять часов до объявления и миллионы вскоре после него (через SecurityWeek). И буквально вчера, 26 октября, CISA добавила оба CVE в свой каталог известных эксплуатируемых уязвимостей, поскольку исследователь зарегистрировал 35 успешных выполнений оболочки (shell execution) на ханипотах под управлением PHP 8.4.26 с mod_php (The Register).

Исправленные версии — 8.2.35, 8.3.36, 8.4.27 и 8.5.12. В собственном бюллетене PHP прямо говорится, что полноценных обходных путей (mitigations) не существует и обновление — единственный безопасный выбор. Если вы используете версию 8.1 или более старую, вы находитесь на неподдерживаемой ветке, поэтому вам потребуется бэкпорт от вендора или обновление.

Node2Shell (CVE-2026-111497)

Эта уязвимость кроется в декодере Brotli, поставляемом в составе Node.js. Если ваше приложение декомпрессирует данные Brotli, полученные от злоумышленника, с помощью node:zlib, некорректный ввод может привести к записи за пределами внутреннего буфера. Худший сценарий — удаленное выполнение кода; менее опасные последствия — сбои в работе и утечка памяти процесса. Это затрагивает ветки 22.x, 24.x и 26.x, исправления доступны в версиях 22.23.4, 24.22.1 и 26.12.1. Ветка получила еще семь исправлений для 24.x, долгосрочной (LTS) ветки, на которой работает множество продакшн-сервисов. Всё, что работает на 20.x или более ранних версиях, больше не поддерживается и не получит исправлений.

eMudhra и certifi (GHSA-6q48-6c7w-9gw2)

Восемь промежуточных центров сертификации eMudhra имели закрытые ключи, сгенерированные со слишком низкой случайностью. Они связаны в цепочку с корневым сертификатом emSign, которому certifi (набор CA для requests и pip) доверял с 2019 года. Любой, у кого есть восстановленный ключ, может создать правдоподобный сертификат для любого доменного имени. Chrome и Firefox быстро заблокировали их. Однако приложения и контейнеры Python используют собственный набор CA, поэтому они остаются уязвимыми до тех пор, пока кто-нибудь не обновит certifi до версии 2026.10.19 или новее (рекомендация GitHub). Есть один нюанс: pip поставляет собственную копию certifi, поэтому вам также потребуется pip 26.2.2 (Python.org guidance). С тех пор компания eMudhra объявила, что полностью уходит из бизнеса TLS-сертификатов.

Почему исправлять это так сложно?

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

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

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

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

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

Если вам интересны более детальные цифры, отчет Verizon 2026 DBIR и отчет 2026 OSSRA report от Black Duck стоят того, чтобы потратить на них полдня.

Это подводит меня к вопросу, который на этой неделе кажется мне самым важным: установлено ли исправление повсеместно? Большинство сканеров не могут на него ответить.

В чем помогает New Relic

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

Security RX подходит к этому с другой стороны. Он опирается на агенты APM, которые вы уже используете, поэтому он видит, что именно загружено и работает в каждом сервисе — без каких-либо изменений в агентах, внедрения новых инструментов или даже необходимости выполнять их обновление.

Меньше шума, включая то, что находится под вашим кодом. Security RX показывает только те модули библиотек, которые действительно загружены в работающих сервисах, а также саму среду выполнения, например версию PHP или Node.js. Поэтому PHP2Shell и Node2Shell появляются прямо рядом с результатами по библиотекам, а не в отдельном отчете, к которому ни у кого в вашей команде нет доступа. Каждая находка получает приоритет и причину для приоритизации, например «Эксплойт крайне вероятен».

«Исправлено» означает исправлено везде. Множество инструментов закрывают уязвимость в тот момент, когда мерджится PR. Прекрасно, если ваши деплои всегда идут по плану. Security RX не отметит CVE как устраненную, пока она не исчезнет из каждого работающего экземпляра, так что вы вовремя заметите развертывание, которое все еще зависло, или пропущенный регион. Работать в сфере безопасности сейчас и без того непросто. Дайте вашему CISO хоть немного уверенности, чтобы он мог сегодня спокойно поспать.

Вот пример, похожий на те, с которыми уже пришлось столкнуться на этой неделе. Допустим, ваш платежный сервис отображается как уязвимый к RCE в Brotli (CVE-2026-111497), потому что на нем запущен Node.js 22.14.0, а команда, отвечающая за сервис, клянется, что они перешли на 22.23.4 еще вчера. Все немного раздражены. Инструмент ошибается? Откройте CVE и изучите детали для этого сервиса. Скорее всего, один экземпляр не получил обновление и все еще работает на Node.js 22.14.0, в то время как остальные показывают статус «Больше не обнаруживается». Команда действительно обновилась, и инструмент тоже прав. Вы просто нашли тот самый единственный экземпляр, который пропустили при деплое.

Одно предостережение: агенты APM сообщают данные о среде выполнения по умолчанию каждые 30 минут, поэтому для только что развернутого сервиса может потребоваться некоторое время, чтобы статус изменился на «Больше не обнаруживается». Честно говоря, я предпочту небольшую задержку слепой зоне в любой день.

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

Как отслеживать «Черный октябрь» в New Relic

Вот что мы заметили в отношении того, как люди реально используют Security RX: это часть повседневной инженерной работы. Большинство времени инженер открывает инструмент, когда уже расследует CVE в своем сервисе. Более чем в половине таких сеансов они открывают боковую панель, чтобы получить контекст безопасности, такой как ошибки, логи или трассировки (обычно в течение минуты), для быстрой триажи. Затем они возвращаются во время развертывания фикса, отслеживая любые проблемы после деплоя и регрессии. Это безопасность и поддержка ПО, объединенные в едином контексте.

Давайте разберем несколько вопросов, на которые вам, возможно, придется ответить, и то, как сделать это в New Relic прямо сейчас.

Ответ на вопрос «уязвимы ли мы?» для всей организации

Для архитектора или технического лидера, которому нужна общая картина, перейдите в Security RX > All Vulnerabilities и установите фильтр Disclosed at на последние 1–7 дней. Все недавно раскрытые уязвимости, затрагивающие вашу инфраструктуру, отображаются с приоритетом, причиной приоритизации и количеством затронутых и незатронутых сущностей. Помните, что здесь можно использовать фильтры по сущностям (Entity) и командам (Team), чтобы получить более детальную информацию, например о том, что именно работает у вас в продакшене. Вставьте CVE-2026-111497 в поле Search by name or cve, чтобы сразу перейти к конкретной уязвимости.

В качестве альтернативы можно начать с Overview > CVE Advisory, что даст вам отфильтрованный список, или открыть страницу All Vulnerabilities, также ограниченную конкретным аккаунтом, например Production.

Триажа из вашего сервиса или быстрая фильтрация по всей компании

• Начните со своего сервиса. В каждой сводке по APM-сервису есть плитка Vulnerabilities с количеством критических и высоких уязвимостей, расположенная прямо рядом с Issues, Deployments и Service levels. Перейдите по ней или используйте раздел Security RX в левой навигации (Overview, Libraries, Vulnerabilities). Отфильтруйте по Time since first detected за последнюю неделю, чтобы увидеть только то, что появилось недавно.
• Откройте CVE. На странице с деталями содержатся инструкции по устранению с версиями исправленных восходящих (upstream) пакетов и пакетов дистрибутива, журнал активности уязвимости и связанные тикеты Jira. Боковая панель позволяет держать в поле зрения собственные сигналы сервиса: время отклика, пропускную способность, частоту ошибок, отклонения и логи.
• Получите контекст перед принятием решения. Это момент, когда большинство людей в любом случае переходят к ошибкам, логам и трассировкам сервиса. Ведет ли себя сервис странно? Перезапускаются ли воркеры или что-то порождает дочерние процессы, которых быть не должно? (В списке ниже есть и другие примеры.) Тихий внутренний сервис и публичный API оформления заказа, который внезапно начал выдавать ошибки, требуют совершенно разного уровня срочности.
• Решите, что является балластом, с чем можно подождать, и отслеживайте это. Самый быстрый способ массово закрыть тонну уязвимостей и сэкономить на облачных затратах — отключить неиспользуемые сервисы. Затем, возможно, у вас есть сервис, который никогда не обрабатывает данные Brotli извне, и вы решили пропатчить его в следующем спринте. Используйте Change to ignored и установите срок 14 дней, причину, описание и ссылку на документацию в соответствии с вашими правилами обработки исключений безопасности. Каждое изменение попадает в журнал аудита, и уязвимость вернется в ваш список при планировании следующего спринта.

Следите за развертыванием исправления

• Следите за ошибками во время деплоя. Страница CVE, которая подсказала, что именно нужно обновить, также показывает, изменяются ли частота ошибок и время отклика после выпуска патча. Никто не хочет менять уязвимость на простой.
• Убедитесь, что уязвимость устранена везде. Перейдите к полной информации о влиянии CVE (или «Просмотреть все объекты»), чтобы узнать область поражения и статус исправления. На графике показано, как количество затронутых объектов уменьшается, а количество больше не обнаруживаемых — растет со временем. Используйте выпадающий список «Статус», чтобы отфильтровать то, что все еще подвержено уязвимости, и выпадающий список «Отчетность», чтобы включить объекты, которые в данный момент находятся в офлайне, чтобы хост, отключенный для обслуживания, не выпал незаметно из поля зрения.

На что стоит обратить внимание в процессе развертывания патчей

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

• Сбои или перезапуски php-fpm или воркеров node происходят чаще обычного. Попытки повреждения памяти обычно сначала выглядят как нестабильность, а уже потом как что-то другое.
• Ошибки нехватки памяти (OOM) или сообщения «zend_mm_heap corrupted» в логах PHP. Обработка OOM — это именно тот путь, который использует CVE-2026-109618.
• Всплески крупных некорректных многочастных POST-запросов (multipart) к эндпоинтам PHP, зачастую с огромным количеством полей или частей.
• Порождение дочерних процессов из php-fpm или node, особенно оболочек (shell) или curl. Это явный признак того, что кто-то уже выполняет свой код.
• Необычный исходящий трафик с хостов PHP или Node.js.

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

Счастливого Хэллоуина, полагаю

Хэллоуин уже в субботу, и я готов поспорить, что немало из вас потратит часть этого дня на наблюдение за тем, как процесс развертывания медленно продвигается по регионам. Если это про вас, держите вкладку «Область влияния» открытой. И будьте снисходительны к тому, кто отвечает за самый последний экземпляр на старой версии, а также к конфеткам-кукурузкам (candy corn). Никто на самом деле не понимает, почему и то, и другое все еще существует.

Кристл Портокарреро — признанный лидер в области кибербезопасности и бизнеса, которая использует свой обширный технический опыт для создания ценности для клиентов, уделяя основное внимание результатам, а не технологиям. Ее путь в технологической индустрии отмечен заметной работой в компании Juniper Networks, где она руководила портфелем решений для безопасности облаков и дата-центров, а также должностью вице-президента в Training Experts, предоставлявшей первоклассных инструкторов, разработчиков контента и консультантов для ведущих технологических компаний, включая Microsoft, Boeing и федеральное правительство США. Ее практический опыт в сочетании со стратегическим видением помогает преодолеть разрыв между техническим мастерством инженеров по безопасности и клиентоориентированной разработкой продуктов. В настоящее время Кристл отвечает за глобальный портфель решений безопасности в New Relic, выводя на рынок инновационные продукты, которые способствуют реализации миссии New Relic по расширению возможностей всех инженеров.

Взгляды, выраженные в этом блоге, принадлежат автору и не обязательно отражают точку зрения New Relic. Любые решения, предлагаемые автором, зависят от конкретной среды и не являются частью коммерческих решений или поддержки, предлагаемых New Relic. Пожалуйста, присоединяйтесь к нам исключительно в Explorers Hub (support.newrelic.com) для получения вопросов и поддержки, связанных с этой публикацией в блоге. Этот блог может содержать ссылки на контент на сторонних сайтах. Предоставляя такие ссылки, New Relic не принимает, не гарантирует, не одобряет и не поддерживает информацию, взгляды или продукты, доступные на таких сайтах.