42 дня от первого случая эксплуатации уязвимости до включения в KEV: где появился сигнал

Первое публичное предупреждение появилось не в X и не в лентах, которые отслеживают идентификаторы CVE. Оно появилось в трекере задач самого проекта на GitHub. 11 сентября 2026 года администратор Nextcloud опубликовал журналы доступа, в которых были видны атаки на встроенное приложение сервера документов Collabora (имя приложения richdocumentscode). Это произошло за 32,5 дня до публикации идентификатора CVE и за 42,2 дня до того, как агентство CISA включило уязвимость в свой каталог KEV (Known Exploited Vulnerabilities). 26 октября 2026 года с 10:17 до 10:56 по сингапурскому времени (SGT) мы отправили 60 запросов к EveryInfra (плата списана за 52, всего $0,029576). Результаты мы сравнили с историей изменений NVD, временным рядом FIRST EPSS и 24 другими недавними записями KEV.

Результат однозначный. Поиск в X по CVE ID вернул 106 постов: ни одного до CVE и 80 после KEV. Каждый пост мы разметили один раз по заранее записанному правилу (без второго разметчика), и 93,4% оказались репостами, ботами или рекламой. Машиночитаемое поле SSVC в записи CVE 9 дней показывало «не эксплуатируется». EPSS 10 дней держался на уровне 1,2%.

В этой статье «проверяемый процесс от сигнала до реакции» состоит из пяти этапов, выполняемых ежедневно. Вы ищете названия своих компонентов (а не только идентификаторы CVE) в трекерах задач проектов, на форумах вендоров и на нескольких социальных платформах. Сохраняете каждый исходный ответ с отметкой времени. Сопоставляете результаты со списком активов и отсеиваете шум. Затем обновляете или удаляете компонент либо расследуете проблему и фиксируете, кто выполнил каждый шаг, когда и на основании каких данных. Процесс подсказывает командам эксплуатации и безопасности, чем заняться в первую очередь и почему, но не предсказывает эксплуатацию и не заменяет бюллетени вендоров.

О чём мы не пишем

Мы пишем только о мониторинге и реагировании. Мы не описываем методы атак, детали эксплуатации и форматы запросов. Упоминая взлом, мы указываем только, где администратор написал об этом, когда и что сообщил. Имена личных аккаунтов мы скрываем и называем только аккаунты организаций (например, CISA, CERT.LV, итальянский CSIRT и Censys) и мейнтейнеров проекта. Мы не оцениваем решения вендоров о раскрытии информации, а лишь сопоставляем временные отметки из публичных записей.

Для читателей из федеральных агентств США важнее всего одна деталь. Согласно BOD 26-04, CISA устанавливает сроки устранения по четырём параметрам: статус в KEV, автоматизируемость эксплуатации, технические последствия и доступность из интернета. Для этой CVE после внесения в KEV агентствам отвели три дня и предписали провести первичный криминалистический анализ. Это самый жёсткий срок в директиве. Отсчёт начинается с внесения в KEV, но атаки начались на 42 дня раньше. Эта статья об этом разрыве и о публичных площадках, где его можно было увидеть.

Критерии, которые мы записали до первого запроса

26 октября в 10:16 SGT, до первого запроса, мы записали в файл проверки пять критериев. В 10:29 SGT, до того как посмотреть результаты анализа выборки, добавили ещё два. В таблице ниже каждый критерий указан рядом с результатом, а источник каждого числа приведён в следующих разделах.

К критерию 2 нужно пояснение. В X оба способа поиска (по CVE ID и по названию продукта с указанием симптома) не вернули ни одного связанного поста до публикации CVE. Поэтому сам по себе X разницу не показывает. Разница видна в трекере задач проекта и на форуме: это публичные площадки, которые можно отслеживать по названию компонента. Для критерия 6 мы пишем «формально критерий выполнен», потому что опережение на 1 день и опережение на 30 дней имеют совсем разную ценность. Это число подробно разобрано в одном из следующих разделов.

Основной случай: от первой строки журнала атаки до KEV

Речь идёт о CVE-2026-110447. Согласно бюллетеню безопасности Collabora, уязвимость затрагивает только одно необязательное приложение Nextcloud, «Collabora Online - Built-in CODE Server». Это приложение запускает копию сервера документов внутри сервера Nextcloud. Автономные серверы Collabora Online не затронуты, а в предупреждении на форуме Nextcloud также уточняется, что варианты для Docker и пакеты дистрибутивов Linux безопасны. Исправление вышло в версии 26.4.303, и в бюллетене сказано, что приложение нужно обновить или удалить (отключения недостаточно). В записи NVD говорится, что уязвимость «эксплуатировалась в реальных атаках в сентябре и октябре 2026 года».

Мы собрали все временные отметки, для которых в открытых источниках указано время с точностью до секунды, и брали данные непосредственно из API, а не из сводок. API GitHub Issues возвращает время created_at для issue и каждого комментария. Форум Nextcloud работает на Discourse (документация API), поэтому, если добавить .json к URL темы, можно получить время каждого поста. Время резервирования и публикации взято из API, лежащего в основе записи CVE.org. Время каждого изменения полей NVD взято из API истории изменений CVE в NVD. Время добавления в KEV указано в поле dateReleased в JSON-файле KEV от CISA, а все отметки времени в таблице приведены в UTC.

В этой таблице стоит внимательнее присмотреться к двум интервалам по 70 минут и одному в 0,7 секунды. Версия 26.4.303 вышла 11 сентября в 13:43. Через семьдесят минут первый пострадавший администратор открыл issue и сообщил, что системы были скомпрометированы ещё накануне.

Мы считаем, что в тот момент эти две стороны не знали друг о друге. В примечаниях к выпуску не было ни слова о безопасности, а администратор выполнил обновление только после того, как его попросили об этом в issue. Второй 70-минутный интервал пришёлся на 14 октября. CVE.org опубликовал ID в 02:27, а первый пост в X с этим ID появился через 69,8 минуты.

Интервал в 0,7 секунды виден в API CVE.org. Значение dateReserved равно 02:27:41.637, а datePublished — 02:27:42.315. То есть 33 дня у уязвимости не было даже зарезервированного ID. Любому процессу, работающему по CVE ID, в эти 33 дня было не с чем сопоставлять данные. В этом главная проблема для каждой команды, у которой обработка начинается с ID.

Мы также нашли одно место, где вторичный источник расходится с исходной записью. В бюллетене Censys от 16 октября сказано, что в журналах автора сообщения первый вредоносный запрос датирован 16 сентября. Но в тексте issue приведены строки журнала от 10 сентября в 19:51 и 11 сентября в 09:56 (часовой пояс +0200).

Сам issue был открыт 11 сентября, поэтому в нём не может цитироваться строка журнала от 16 сентября как первый запрос. Мы берём текст issue из GitHub API, потому что в 33-дневном окне одна неверная дата в кратком изложении означает ошибку в 6 дней. Данные о масштабе воздействия мы копируем из того же бюллетеня: приложение было установлено на 19 454 хостах и 103 350 веб-ресурсах. Censys уточняет, что уязвимость подтверждена не для всех из них, и оба значения включают сборку того же приложения для ARM64 (1 001 хост).

Почему 33 дня не было CVE

У KEV три обязательных требования, которые CISA перечисляет на странице критериев. У уязвимости должен быть CVE ID. Должны быть надёжные доказательства активной эксплуатации. Должны быть чёткие рекомендации по устранению. Второму и третьему требованиям уязвимость соответствовала уже 11 сентября: в issue были сообщения от трёх администраторов, а исправление уже вышло. Помешало первое требование, поэтому 32,5 дня без ID превратили общий срок в 42 дня.

В записи в блоге Collabora от 14 октября рядом приведены два факта. В этом году компания получила очень много отчётов об уязвимостях, подготовленных с помощью ИИ. А срок получения CVE через GitHub вырос примерно с одного дня до многих недель. В посте не утверждается, что первое вызвало второе. Там сказано, что Collabora сейчас подаёт заявку на статус CVE Numbering Authority (CNA), чтобы сократить ожидание.

Запись CVE.org показывает, что окончательной назначающей организацией была MITRE и что резервирование и публикация произошли в одну и ту же секунду. Это больше похоже на то, что MITRE выступила назначающей организацией последней инстанции, чем на прохождение обычной очереди. Заявлений по этому случаю мы не нашли, поэтому о причине не гадаем.

Этот случай не исключение. В октябре компания Second Security опубликовала исследование «The Patchless Window». Авторы сопоставили 18 594 CVE в проектах с открытым исходным кодом за период с января по август 2026 года с первым публичным коммитом, исправляющим каждую уязвимость. Медианное время от публикации исправления до публикации CVE составило 5,1 дня в январе и 39,2 дня в августе. Разрыв у Collabora составил 32,5 дня, то есть меньше августовской медианы. Так что для компонентов с открытым исходным кодом схема «сначала исправление, через месяц ID» становится нормой.

Материал BleepingComputer от 15 октября ссылался на это исследование, а мы сверили цифры на сайте самого исследования. О случае также писал The Hacker News. Для команды, которая подписана на данные об уязвимостях по CVE ID, вывод прост: в среднем первое оповещение теперь приходит более чем через месяц после публикации исправления. Всё это время исправление уже доступно, но никто не сообщает вам, что оно устраняет уязвимость.

Нужно учесть ещё одно обстоятельство. С 15 апреля 2026 года NIST больше не обогащает данные по каждой CVE. В приоритете записи KEV, ПО, которое использует федеральное правительство, и «критически важное ПО». В качестве причины NIST называет рост числа заявок на CVE на 263% с 2020 по 2025 год. 26 октября API NVD всё ещё показывал эту запись как Deferred (только оценка CVSS 4.0 от назначившей организации и SSVC от CISA). Цель NIST — обогащать записи KEV в течение одного рабочего дня, а с момента внесения в KEV прошло больше двух дней.

Для вас это значит, что многие поля NVD могут быть пустыми до KEV и ещё какое-то время после. Если вы рассчитываете, что оценка NVD поднимет уязвимость в начало очереди, этот план может не сработать именно в этот период. Текст описания был доступен с первого часа. Структурированные поля появились позже, а следующие тесты показывают, насколько позже.

Тест 1: что показывали социальные платформы до CVE

Заметил бы проблему раньше тот, кто отслеживал этот компонент в X? 26 октября с 10:24 до 10:26 SGT мы выполнили три поиска с помощью API для парсинга поиска X (Twitter) (twitter/search). Для каждого поиска задали диапазон дат с 1 сентября по 14 октября. В первом запросе использовали название приложения richdocumentscode. Во втором — название продукта в сочетании со словами, указывающими на симптомы (nextcloud (hacked OR webshell OR compromised OR backdoor)). В третьем — только nextcloud collabora.

Результаты подтвердили один и тот же вывод. Первые два поиска вернули 3 и 5 постов, и все они были опубликованы 14 октября или позже, то есть до публикации CVE не было ни одного. Третий поиск вернул 16 постов, опубликованных до CVE, и ни в одном не говорилось об уязвимости или взломе. Они были посвящены швейцарским федеральным служащим и офисным инструментам с открытым исходным кодом, европейскому цифровому суверенитету и управляемому хостингу Nextcloud. Мы также заметили, что во всех трёх запросах было until:2026-10-14, но в ответах оказалось 3, 5 и 6 постов от 14 октября или позже. Верхняя граница диапазона дат («до определённой даты» в справке по расширенному поиску X) оказалась нестрогой, поэтому мы дополнительно отфильтровали результаты по значению posted_at каждого поста.

На Reddit API для парсинга поиска Reddit (reddit/search) всегда охватывает последний месяц. Наш поиск 26 октября охватил период с 26 сентября, включая 18 дней до CVE. В 10:42 SGT поиск по richdocumentscode с сортировкой по новизне вернул 14 постов. Все 14 были об этой уязвимости, но ни один не появился до CVE. Первым был репост новости о безопасности 14 октября в 20:04, через 17,6 часа после CVE.

Самый полезный пост на Reddit появился 22 октября. Системный администратор в сообществе r/NextCloud описал, как сервер был взломан через встроенное приложение Collabora; под постом было 52 комментария. Через тринадцать секунд тот же автор опубликовал его и в r/Malware. Для Hacker News мы использовали поисковый API Algolia, и запрос richdocumentscode не дал результатов. По запросу nextcloud collabora после 1 сентября первой связанной публикацией стал пост со ссылкой от 15 октября (22:06 UTC, 2 балла, 0 комментариев).

Мы расположили по времени первые связанные публикации на каждой платформе относительно даты публикации CVE. Задача на GitHub появилась на 32,5 дня раньше, а первая публикация на форуме Nextcloud — на 10,7 дня раньше. В X первая связанная публикация появилась на 0,05 дня позже, на Reddit — на 0,73 дня позже, а на Hacker News — на 1,8 дня позже. API для парсинга результатов поиска на YouTube (youtube/search, 10 из 10 результатов с ID) показал первую публикацию на 2,5 дня позже, а API для парсинга результатов поиска на LinkedIn (linkedin/search, 8 из 10) — на 4,0 дня позже. API для парсинга результатов поиска на Weibo (weibo/search) вернул 9 постов о другой уязвимости (PHP2Shell) и 1 дайджест, в котором Collabora упоминалась лишь в одной строке. API для парсинга результатов поиска в Threads (threads/search) вернул 25 постов, опубликованных лишь за последние 19 часов, поэтому по ним нельзя было определить дату первого упоминания.

Логику этой таблицы можно проследить шаг за шагом. Во-первых, все публичные сигналы до CVE появились на площадках самого проекта: в трекере задач и на пользовательском форуме вендора. Во-вторых, авторами были пострадавшие администраторы и мейнтейнеры, а их публикации содержали логи и номера версий, которые можно проверить. В-третьих, первые публикации в соцсетях появились после CVE. Их разместили новостные аккаунты по информационной безопасности, которые читали записи CVE, а не задачи в трекерах. Поэтому основная стратегия мониторинга — «искать название компонента в задачах и на форумах проектов». Социальные платформы усиливают сигнал позже, и на них появляются сообщения пострадавших, но в этом случае системой раннего предупреждения они не были.

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

Тест 2: после публикации CVE объём постов растёт вслед за добавлением уязвимости в KEV

В 10:26 SGT мы один раз выполнили поиск в X по CVE-2026-110447 с лимитом в 200 результатов и сортировкой от новых к старым. В ответе было 106 постов, поэтому лимит не был исчерпан. Мы разбили посты на три периода. До CVE постов было 0, а за 9,7 дня от CVE до KEV — 26. За 2,3 дня после KEV появилось 80 постов, из них 49 только за 24 октября. На первые 48 часов после KEV пришлось 71,7% всех постов.

Форма этой диаграммы ясно показывает одно: в X KEV служит усилителем, а не сигналом. Уязвимость эксплуатировалась в сентябре, а в описании CVE 14 октября было сказано «exploited in the wild». Крупные новостные аккаунты о безопасности написали об этом в тот же день. Но настоящая волна репостов пошла только после уведомления CISA о KEV. Многие новостные аккаунты о безопасности и боты берут ежедневное обновление KEV как источник, а многие компании открывают тикеты только по записям KEV.

Для мониторинга это значит, что оповещение «объём постов в X по ID резко вырос» в этом случае сработало бы после KEV. Объём постов показывает, что обсуждают сейчас. Он не показывает, кого уже атаковали. Если ваш пайплайн использует объём публикаций в соцсетях как триггер, он измеряет внимание, а внимание возникло позже всего.

Распределение по языкам тоже полезно. Из 106 постов 68 были на английском, 18 на японском, 5 на французском, 4 на испанском, 3 на корейском и 1 на китайском. Для команды из США важна доля постов на японском: один такой пост был единственным сообщением в X до KEV от непосредственного пострадавшего о компрометации. Мониторинг только англоязычных постов его бы пропустил. Если вы фильтруете публикации по языку, не исключайте языки стран, в которых ваши пользователи запускают это ПО.

Тест 3: 93,4% шума и как он выглядит

Мы разделили 106 постов на 6 классов по правилу, сформулированному заранее. Чтобы чётко обозначить ограничения: все 106 постов были размечены один раз по этому правилу, а второй разметчик не проводил независимую проверку. Поэтому 93,4% — результат одного прохода разметки по этому правилу, а границы его погрешности неизвестны. Прежде чем использовать это число в официальном отчёте, попросите другого человека заново разметить 106 постов по тому же правилу и укажите степень согласованности результатов двух разметок. «Сигнал» добавляет факт, которого нет в записи CVE или бюллетене вендора. «Шум» делится на три класса: репосты бюллетеней или новостных материалов; шаблонные боты и ежедневные дайджесты; рекламный или нерелевантный контент.

Итог: 80 репостов, 12 ботов и дайджестов и 7 рекламных или нерелевантных постов, всего 99 постов (93,4%). Четыре из 7 сигнальных постов опубликовали организации с собственными данными: CERT.LV (Латвия), CSIRT (Италия), Censys и CISA. Два поста содержали новые факты от людей, которые проверили записи. Один пост показал, что поле SSVC противоречит описанию, а другой — что в NVD есть оценка CVSS 4.0, но нет оценки 3.x. Последний пост опубликовал японский администратор (23 октября, 08:29 UTC), сервер которого за неделю до этого был заражён майнинговым ПО через эту уязвимость.

Только 4 из этих 7 постов появились до KEV. Значит, команда, которая до KEV читала каждый пост с ID, прочитала бы 26 постов, чтобы найти 4 полезных. После KEV соотношение было хуже: 80 постов и 3 полезных. После добавления уязвимости в KEV затраты на чтение растут, а ценность информации — нет.

Некоторые из 7 рекламных и нерелевантных постов относятся к типам, которые вы снова встретите с другими уязвимостями. Добавьте их в правила фильтрации шума. Были посты, которые использовали заголовок для продвижения криптотокена, и реклама продуктов в духе «подключите ИИ-бота к URL и получайте оповещения». Были посты с «советами для багбаунти», которые объясняют, как находить и проверять системы без патчей; мы их удалили и не пересказываем. Один общий комментарий о том, что «каждую неделю кажется, будто рушится небо», попал в выборку только потому, что содержал ID.

Шум есть не только в X. В ветке форума Nextcloud из 7 постов посты 3 и 6 опубликовал один и тот же новый аккаунт. Оба содержали ссылку на внешнюю страницу с «бесплатной 30-секундной самопроверкой». Пост 7 оставил руководитель сообщества: он написал, что две ссылки почти идентичны и что команда следит за спамом. В Weibo 8 из 10 результатов оказались одним и тем же текстом о PHP2Shell, опубликованным 8 аккаунтами в течение 2 секунд; это типичная схема работы фермы аккаунтов. В Threads 6 из 25 результатов по запросу «Nextcloud Collabora» оказались итальянскими постами с глаголом «collabora» («работает вместе»).

Тест 4: машиночитаемые поля риска отставали от текста

Многие конвейеры обработки уязвимостей не читают текст описания. Они читают структурированные поля. Одним из источников служат три точки принятия решений SSVC, которые CISA добавляет в записи CVE через свой проект Vulnrichment: exploitation, automatable и technical impact. Другой источник — ежедневная оценка EPSS от FIRST, которая прогнозирует вероятность того, что в ближайшие 30 дней будет наблюдаться эксплуатация. Для установления сроков для федеральных ведомств директива BOD 26-04 использует статус KEV, automatable, technical impact и exposure, причём три из этих параметров CISA предоставляет через Vulnrichment.

С помощью API истории изменений NVD мы получили все изменения данных SSVC в этой записи. Через EPSS API мы получили временной ряд. Описание CVE с 03:17 14 октября содержало фразу «exploited in the wild». Данные SSVC менялись так, как показано в таблице.

Итак, 9,7 дня описание сообщало об эксплуатации, а структурированные поля сначала были пустыми, а затем 9 дней указывали: «не эксплуатируется». На «эксплуатируется» они сменились лишь через 47 минут после KEV. Оценка EPSS все эти 10 дней держалась на уровне 1,2 % (на тот момент около 68-го перцентиля) и достигла 12,3 % только на второй день после KEV. Правило вида «открыть тикет, если SSVC = active или EPSS выше 10 %» сработало бы через 1–2 дня после KEV. Это на 11 дней позже текста описания.

Один пользователь X заметил это расхождение. В 21:03 UTC 23 октября он опубликовал обновление: KEV добавил уязвимость примерно через 6 минут после его первого поста о расхождении, и SSVC теперь показывал active. В посте читателям советовали заново получить данные, если в их конвейере осталось старое значение. Там же упоминался срок для федеральных ведомств — 26 октября. Среди 106 постов это был один из немногих, имевших непосредственную ценность для конвейера.

Это не значит, что SSVC и EPSS бесполезны. В FAQ по EPSS сказано, что EPSS — не полноценная оценка риска, а SSVC — суждение аналитика, которому нужны доказательства. Наше наблюдение более узкое: пока доказательства существовали только в трекере задач проекта, ни одно из полей их не учло. Используйте структурированные поля для сортировки, а не как обязательный фильтр. Добавьте отдельное текстовое правило для фраз вроде «exploited in the wild» в описании.

Тест 5: 24 недавние записи KEV — насколько раньше о них писали в X

Одного случая недостаточно. Мы взяли все 30 записей, которые KEV добавил с 26 сентября по 23 октября. У шести были старые ID 2015–2025 годов (например, ProFTPD и BIND 2015 года). Для остальных 24 мы по одному разу выполнили поиск каждого ID в X через twitter/search с 10:28 до 10:41 SGT, установив лимит 200. В качестве времени KEV мы брали первую аннотацию KEV в истории изменений NVD. Эта аннотация появляется через несколько минут или часов после публикации CISA, поэтому полученное время представляет собой верхнюю границу, а рассчитанное опережение X оказывается слегка завышенным. В этом отличие от основного случая, где используется dateReleased из KEV JSON от CISA (19:30 23 октября). Аннотация KEV в NVD для той же CVE появилась в 20:17, на 47 минут позже. Старые версии каталога не указывают время публикации для каждой записи, поэтому в срезе для всех 24 используется аннотация NVD, а опережение в основном случае на той же основе составляет 9,7 дня.

Результат: у 23 из 24 CVE (95,8 %) до KEV был хотя бы один пост в X с этим ID, что формально соответствует критерию 6. Но медианное опережение, рассчитанное по неокруглённым значениям, составило около 1,16 дня (12-е и 13-е значения — 1,12 и 1,19 дня), и лишь в 13 из 24 случаев опережение превышало 1 день. Важнее другое: для 17 CVE первый пост в X появился в пределах 0,3 дня от публикации в NVD. Причина в разрыве между NVD и KEV. Для 12 из 24 CVE KEV появился в тот же день, что и NVD, или на следующий, в основном для подтверждённых вендором уязвимостей нулевого дня (Citrix NetScaler, Fortinet, Ivanti). Кажется, что X опережает источники, только когда этот разрыв велик (Atlassian — 10 дней, Ahsay — 10 дней, наш основной случай — 9,7 дня), причём это опережение почти полностью обусловлено самой публикацией CVE.

Если отсортировать разрыв между NVD и KEV по календарным дням, картина становится яснее. Разрыв составил 0 дней для 9 CVE, 1 день для 3 и 2 дня для 2. Разрывы в 5, 6 и 9 дней были у одной CVE каждый, разрыв в 10 дней был у 3 CVE, а в 27 дней — у 4. Медиана составила 1,5 дня.

Таким образом, записи KEV за этот месяц делятся на две группы. В первой вендор подтверждает уязвимость нулевого дня, и CVE с KEV появляются почти одновременно. Во второй CVE была опубликована задолго до этого, а доказательства эксплуатации появились позже.

В первой группе X помогает быстрее увидеть срочный бюллетень вендора, и опережение составляет несколько часов. Во второй группе опережение X зависит от того, заметил ли кто-нибудь CVE после публикации. Случай Plex показывает, что о ней могут молчать три недели. Кроме того, у 6 CVE посты в X с ID появились раньше, чем NVD их добавила, обычно потому, что ID первым указал бюллетень вендора. Поэтому при построении хронологии не считайте время поступления в NVD моментом, когда ID стал публичным.

Исключение — 4 CVE в Plex Media Server. NVD опубликовала их 23 сентября, но первый пост в X с этими ID появился 18 октября. Это на 24,9 дня позже и всего за 2,2 дня до KEV; этот случай разобран в следующем разделе. Есть ещё два замечания. Для CVE-2026-88771 и CVE-2026-102764 поиск вернул все 200 постов, заданные лимитом, поэтому наше время первого появления для них — нижняя граница. Кроме того, поиск X возвращает ранжированную выборку, а не все посты.

С SSVC всё проще. Ни у одной из 30 записей не было exploitation: active до KEV, так что в этой выборке «active» в SSVC лишь отражает KEV. Для 12 CVE, у которых были данные EPSS за день до KEV, все 12 оценок были ниже 10 %. В этой выборке ни одно из полей не предупредило раньше каталога.

Три случая для сравнения: NetScaler, Plex2Shell, PHP2Shell

Чтобы понять, есть ли закономерность, мы сравнили три события того же периода. По каждому мы один раз выполнили поиск в X и сопоставили временные отметки из первичных источников, приняв публикацию CVE за день 0.

NetScaler: в X информация появилась раньше, но ранние сообщения были лишь слухами. В 10:54 SGT мы поискали NetScaler за 26–28 сентября и получили 176 постов. Первый появился в 15:07 UTC 26 сентября. Крупный аккаунт написал, что из-за неизвестной, активно эксплуатируемой уязвимости нулевого дня в NetScaler учреждения отключают устройства. NVD получила CVE-2026-88771 в 17:16 27 сентября, а в X к тому моменту было уже 77 постов.

В нескольких ранних постах говорилось, что слух пошёл из обсуждений системных администраторов на Reddit. CISA добавило уязвимость около 20:16 того же дня.

В отдельном оповещении CISA призвало организации проверить системы на компрометацию до установки патча. Citrix в тот же день опубликовала бюллетень безопасности. Это типичная картина для крупного вендора, уязвимости нулевого дня и пограничного устройства. Пострадавшие — крупные организации, и новость сначала расходится среди специалистов как «что-то не так». Затем в течение суток появляются данные вендора, CVE и запись KEV. X опередил их на 26 часов, но этот контент был непроверенными слухами: его достаточно, чтобы запустить плейбук «проверьте логи», но не для выводов.

Plex2Shell: вендор предупредил заранее, но никто не услышал. Компания Plex опубликовала уведомление на форуме в 18:30 UTC 1 сентября. В нём говорилось, что версия 1.43.3 исправляет несколько проблем безопасности и что CVE уже запрошены. Сейчас у уведомления 86 684 просмотра. Но поиск в X по запросу plex "security update" за 1–22 сентября нашёл только 1 пост.

CVE (например, CVE-2026-96652) вышли 23 сентября. В бюллетене ACN (Национального агентства по кибербезопасности Италии) для каждой CVE указаны невысокие оценки, например 4,3 и 6,5 (CVSS 3.1). Поэтому внимания на них почти не обратили.

Перелом произошёл 16 октября, когда исследователь опубликовал полный анализ того, как 4 уязвимости складываются в цепочку. 17 октября ханипот другого исследователя зафиксировал эксплуатацию (его блог). Первый пост в X со словом «Plex2Shell» появился в 15:59 18 октября, а 20 октября CISA добавило эти CVE. Закономерность такая: совокупный риск уязвимостей с низкими оценками стал виден только после публичного анализа, а первым публичным сигналом было собственное уведомление вендора. Ваш мониторинг должен улавливать фразы вроде «важное обновление безопасности, подробности позже». Сообщение пострадавшего на Reddit (r/unRAID, 109 комментариев) появилось 21 октября, уже после KEV.

PHP2Shell: больше всего внимания в X, но в KEV до сих пор нет. 20 октября команда PHP объявила об исправлении двух критических уязвимостей. Первый пост в X с CVE-2026-109618 появился в 18:56 UTC 20 октября, примерно за 19 часов до исправления и CVE (13:48 UTC 21 октября, по данным CVE.org). Наш единственный поиск нашёл 68 постов ещё до окончания эмбарго в 14:00 21 октября. Отдел анализа угроз AWS сообщил в блоге, что его сеть ханипотов зафиксировала попытки эксплуатации 17 октября, за 4 дня до раскрытия. Агентство ЕС CERT-EU отразило событие в своём бюллетене.

Но когда мы открыли каталог KEV 26 октября, он всё ещё был версии 2026.10.23 и не содержал этих идентификаторов. Наш поиск в 10:52 SGT вернул максимально возможные 200 постов за период с 20 по 23 октября, и верхняя граница даты снова соблюдалась нестрого. Этот случай показывает, что внимание в соцсетях и попадание в KEV не связаны. Для KEV нужны надёжные доказательства эксплуатации в реальных атаках, а попыток атаковать ханипоты может оказаться недостаточно. Для уязвимости вроде PHP2Shell не ждите KEV: назначайте срок установки исправления с учётом доступности ваших систем извне.

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

От сигнала к реагированию: процесс, который запускается раз в день

Этап 1 — мониторинг источников. В вашем списке должны быть не ID CVE, а имена используемых компонентов, например richdocumentscode, Plex Media Server или NetScaler. Для каждого компонента предусмотрено три вида источников. Первый — трекер задач и релизы проекта: у GitHub есть бесплатный API для получения новых задач и релизов. Второй — форум вендора или страница уведомлений безопасности: многие форумы работают на Discourse, который отдаёт JSON. Третий — поиск по ключевым словам в нескольких соцсетях. JSON-файл KEV и описание CVE нужны для подтверждения информации и определения сроков, а не как отправная точка.

В этом случае при ежедневном мониторинге трекера задач richdocumentscode слово «Hack» было бы обнаружено в заголовке задачи 11 сентября. Это на месяц раньше любого оповещения по подписке на ID. Стоимость такого мониторинга — один бесплатный вызов API на компонент в день. Выигрыш — 32,5 дня.

Этап 2 — сохранение доказательств. Сохраняйте каждый необработанный ответ без правок вместе с параметрами запроса, временем в UTC и хешем файла. Причин две. Во-первых, позже вы должны суметь ответить на вопрос «когда мы узнали?» во время форензик-триажа, предусмотренного BOD 26-04, и при подготовке отчётов об инцидентах. Во-вторых, контент на платформах меняется: посты удаляют, комментарии редактируют, а в сводках бывают ошибки. Расхождение в дате у Censys мы нашли только потому, что вернулись к сохранённому тексту задачи.

Этап 3 — сопоставление с активами. Сопоставляйте инвентарь по имени компонента, а не по ID CVE: в августе медианная длительность периода без ID по данным Patchless Window составила 39,2 дня. При сопоставлении нужно учитывать тип развёртывания. Эта уязвимость затрагивает только встроенное приложение CODE, а отдельная установка Collabora не затронута. Сопоставление по вопросу «используем ли мы Collabora?» даёт много ложных тревог. Хуже того, среди них может затеряться тот единственный сервер, который действительно уязвим.

Этап 4 — отсев шума. Пометьте каждую запись одним из 6 классов из теста 3. Репосты, боты, продвижение и посты с подсказками для атак не попадают в очередь на реагирование, но остаются в архиве для последующих проверок. В этом тесте было отсеяно 93,4% результатов поиска в X по ID и 100% результатов по названию продукта до появления CVE. Ваши правила также должны учитывать совпадения слов в разных языках (итальянское «collabora»), фермы аккаунтов (8 аккаунтов, 2 секунды) и ссылки на «бесплатную самопроверку» на форумах.

Этап 5 — реагирование. В бюллетене Collabora рекомендуется обновиться до 26.4.303 или удалить приложение, поскольку отключить его недостаточно. Если вы используете уже не поддерживаемую версию Nextcloud 29 или более раннюю, обновите Nextcloud или удалите приложение.

Пост 4 на форуме Nextcloud предлагал практическую проверку: после обновления проверка целостности Nextcloud сообщила о «лишнем файле» в папке приложения. CSIRT Италии упоминал установку веб-шеллов и кражу учётных данных. Поэтому для любого экземпляра, который был доступен извне после 10 сентября, мы советуем ещё три действия: запустите проверку целостности, просмотрите журналы доступа и смените пароли, которые может прочитать веб-сервер.

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

Этап 6 — закрытие случая. По каждому случаю нужно указать, кто и когда им занимался, на основании каких доказательств действовал (со ссылкой на необработанный ответ в архиве) и что сделал. После добавления уязвимости в KEV сравните срок устранения из записи KEV со временем закрытия. В таблице ниже приведён предлагаемый минимальный набор полей записи. Все эти поля использовались в тесте.

Стоимость: 50 компонентов за один месяц

В 10:13 SGT 26 октября мы прочитали каталог возможностей, а источником цен служит страница тарифов. twitter/search, reddit/search, youtube/search, linkedin/search и threads/search стоят по $0,000556 за запрос. weibo/search стоит $0,000806 за запрос. Оплата идёт за каждый запрос, а не за результат. Мы также выполнили 3 поиска EveryInfra с глубиной quick ($0,000694 каждый) в интернете и на форумах, чтобы найти посты, опубликованные до появления CVE. Все 3 поиска вернули 0 результатов.

Возьмём небольшую команду с 50 компонентами, доступными из интернета, и по одному поиску в X и на Reddit для каждого компонента в день. Это 100 запросов × $0,000556 = $0,0556 в день, или $1,668 за 30 дней. API GitHub Issues, форумы на Discourse, NVD, CVE.org, KEV и EPSS — бесплатные публичные API, поэтому в эту стоимость они не входят.

Пустые результаты и сбои не оплачиваются. Из наших 60 запросов 6 упёрлись в лимит запросов (статус 429), в 1 был неверный параметр (статус 422), и 1 вернулся пустым. Ни один из этих 8 не был оплачен. С нас списали за 52 запроса ($0,029576), а главное изображение и одна иллюстрация обошлись ещё в $0,06.

Стоит ли запускать цикл каждый час? При тех же 50 компонентах ежечасный цикл означает 2 400 запросов в день, то есть $1,3344 в день и около $40,03 в месяц. Это в 24 раза дороже ежедневного запуска и сокращает время до обнаружения менее чем на сутки. В нашем случае первый сигнал появился за 32,5 дня до CVE, поэтому при таком запасе времени разница между ежедневной и ежечасной проверкой не важна. Ежечасный мониторинг подходит для уязвимостей нулевого дня в пограничных устройствах вроде NetScaler, где CVE и запись в KEV появляются в течение суток. Такой список обычно короткий, поэтому ведите его отдельно, а полный список проверяйте ежедневно.

Как получить те же данные из кода или ИИ-клиента

Один запрос с помощью curl для поиска в X по ID (вместо ключа указана заглушка):

curl -s https://api.everyinfra.com/api/v1/social \
  -H "Authorization: Bearer <API Key>" \
  -H "Content-Type: application/json" \
  -d '{"platform":"twitter","action":"search","params":{"keyword":"CVE-2026-110447","sort":"latest","limit":200}}'

Каждое поле ответа, используемое в этой статье, мы сверили с response_fields для twitter/search в каталоге.

Для Reddit используйте reddit/search с параметрами keyword и sort (newest, relevance и другие). Чаще всего вам понадобятся поля community, comment_count и posted_at. Временной диапазон всегда ограничен последними 30 днями. Если нужна история более чем за 30 дней, архивируйте результаты по мере получения.

Чтобы запускать те же поиски из Claude Code, получите ключ в разделе Быстрый старт и подключите удалённый MCP-сервер:

claude mcp add --transport http everyinfra https://api.everyinfra.com/mcp \
  --header 'Authorization: Bearer ${EVERYINFRA_API_KEY}'

После этого достаточно одной инструкции: «С помощью everyinfra_call_api найди в X посты по richdocumentscode и по CVE-2026-110447 и раздели их на опубликованные до и после 2026-10-14 02:27 UTC». Затем можно попросить перечислить аккаунты организаций отдельно от личных. В ответе используются те же поля posted_at и author_username, что и в таблице выше.

Вот какие ошибки и результаты списаний мы увидели в этом тесте. Когда мы задали для sort в Reddit несуществующее значение oldest, ответ был 422 invalid_value. В ошибке были перечислены все допустимые значения и сказано «Nothing was charged». Когда другие запросы на том же тестовом ключе исчерпали лимит в 10 запросов в минуту, ответ был 429 rate_limited со значением retry_after. Это тоже не оплачивалось, а все повторные попытки через retry_after плюс 10 секунд прошли успешно.

Синхронный запрос без результатов возвращает статус 200 с count, равным 0, и billing.reason со значением empty_result_refunded. Плата за такой запрос не списывается. Подробности построчной сверки см. в разделе о возврате средств за сбои и сверке. Когда поиск в X возвращает максимально допустимое число результатов, самые ранние посты могут быть отброшены, а в ответе не будет сообщения об ошибке. Самостоятельно сравнивайте count с лимитом.

Изменения за последние 60 дней и связанные исследования

23 октября 2026 г.: CISA добавило CVE-2026-110447 с трёхдневным сроком и требованием провести форензик-триаж. См. оповещение CISA. Для поля forensicTriage: Yes в записи KEV стоит создать отдельное правило. Оно означает: «После установки патча проверьте, не произошло ли компрометации».

21 октября 2026 г.: PHP2Shell стала публичной, и AWS сообщила, что эксплуатация началась на 4 дня раньше. См. сравнительные случаи выше. Для вас: при расследовании отсчитывайте назад от самой ранней известной эксплуатации, а не вперёд от даты бюллетеня.

20 октября 2026 г.: CISA добавило сразу шесть уязвимостей, и четыре из них составляли цепочку Plex2Shell. Уязвимости с низкими оценками могут попасть в KEV, если образуют цепочку. Фильтр по отдельным оценкам CVSS их пропускает.

14 октября 2026 г.: Collabora возложила вину на очередь запросов на присвоение CVE и подала заявку на статус CNA. Идентификаторы CVE будут появляться быстрее, когда проекты с открытым исходным кодом начнут получать статус CNA. До тех пор подписка по ID может опаздывать на месяц.

Октябрь 2026 г.: Second Security опубликовала исследование Patchless Window. В августе медианное время от публикации исправления до публикации CVE составило 39,2 дня. Следите за компонентами с открытым исходным кодом по их коммитам, релизам и задачам и не ждите ID.

25 сентября 2026 г.: в статье на arXiv предложена GPM — метрика приоритизации на основе звёзд, форков и пользователей репозиториев с эксплойтами на GitHub (arXiv 2609.31004). По словам авторов, GPM интегрирована в EPSS версии 5. Активность в публичных репозиториях теперь учитывается при формальной оценке. Но нашим сигналом было сообщение пострадавшего в трекере задач, а не код эксплойта, поэтому эта метрика его не охватывает.

19 августа 2026 г.: исследование оценило развёрнутый граф знаний об угрозах на выборке из 10 000 постов об угрозах в соцсетях (журнал Information). В графе уже содержалось 96% значимых для реагирования уязвимостей из этих постов, и сведения о них появлялись там как минимум так же быстро. Соцсети опережали его только в раннем предупреждении об активной эксплуатации. Это согласуется с нашим результатом: ценность данных из соцсетей заключается в нескольких сообщениях пострадавших и слухах, а не в покрытии CVE.

Август 2026 г.: в исследовании STINER оповещения в X использовались для построения картины угроз в Европе (arXiv 2608.14418). Выяснилось, что атаки в разных странах заметны в X очень по-разному. При мониторинге соцсетей всегда нужно учитывать язык и регион: в этом случае единственным сообщением из первых рук в X до KEV был пост на японском. Для справки о методе: ещё в 2015 году в статье на USENIX Security уже пытались по постам в Twitter предсказывать реальные эксплойты.

Ограничения этой статьи

Во-первых, основной случай только один, а по каждому сравнительному случаю мы искали лишь однажды. У нас нет контрольной группы уязвимостей, которые не эксплуатировались, поэтому мы не можем рассчитать долю ложных тревог. Мы также не можем утверждать, что за каждой задачей в духе «нас взломали» стоит реальная уязвимость. Здесь сигнал из задачи был достоверным, потому что в ней были логи, несколько человек наблюдали одно и то же, а мейнтейнер ответил в течение 3 дней. У других задач всех трёх признаков может не быть.

Во-вторых, поиск X возвращает ранжированную выборку. Наш поиск по ID вернул 106 постов и не упёрся в лимит, но мы не можем доказать, что в X нет более ранних постов. Ограничение по дате until ни в одном из 4 наших запросов, где оно использовалось, не соблюдалось строго, поэтому мы фильтровали по posted_at. Поиск Reddit охватывает только последний месяц, поэтому мы не смогли проверить Reddit за 10–25 сентября. Общий веб-поиск по reddit.com до 14 октября вернул только старые вопросы о настройке, без сообщений о компрометации.

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

В-четвёртых, наблюдения по SSVC и EPSS относятся к одной ситуации: в описании уже сказано, что уязвимость эксплуатируется. Не обобщайте их до «эти поля всегда запаздывают». EPSS оценивает вероятность, и её задача не в том, чтобы дублировать KEV.

FAQ

Что значит, если CISA добавило уязвимость в KEV?

Это означает, что CISA располагает идентификатором CVE, надёжными доказательствами эксплуатации в реальных атаках и чёткими рекомендациями по устранению уязвимости. Согласно BOD 26-04, федеральные ведомства обязаны устранить её не позднее срока, указанного в записи. В данном случае на это отвели три дня и дополнительно потребовали провести форензик-триаж. Запись в KEV всегда появляется позже записи CVE. Здесь она появилась через 9,7 дня после CVE и через 42,2 дня после первого публичного сообщения. (По поисковой подсказке «cisa kev meaning».)

EPSS или CISA KEV: что использовать для приоритизации?

Они отвечают на разные вопросы. KEV сообщает о подтверждённой эксплуатации, а EPSS оценивает вероятность того, что в ближайшие 30 дней будут обнаружены случаи эксплуатации. В этом случае значение EPSS оставалось на уровне 1,2% в течение всех 10 дней до появления записи в KEV. Для всех 12 CVE из KEV, по которым в нашей выборке были данные, оценка EPSS за день до появления записи в KEV была ниже 10%. Используйте оба источника для сортировки и добавьте правило поиска по тексту для фразы «exploited in the wild». (По поисковой подсказке «epss vs cisa kev».)

Как устранить уязвимость Collabora в Nextcloud?

Обновите приложение «Collabora Online - Built-in CODE Server» до 26.4.303 или удалите его, поскольку отключить его недостаточно. Если у вас Nextcloud 29 или более ранней версии, обновите Nextcloud или удалите приложение. Отдельные серверы Collabora не затронуты. Если ваш экземпляр был доступен извне, также запустите проверку целостности, просмотрите журналы и смените учётные данные. (По поисковой подсказке «nextcloud collabora vulnerability fix».)

Читайте также

• Страницы платформ: API для парсинга X (Twitter), API для парсинга Reddit, API для парсинга Weibo
• Страницы возможностей: Поиск в X, Поиск в Reddit, Поиск в YouTube, Поиск в LinkedIn, Поиск в Threads, Поиск в Weibo
• Из той же серии: Аналитика уязвимостей как продукт, Сигналы схем «памп и дамп» в соцсетях, Данные соцсетей как исследовательская выборка

Источники

1. CollaboraOnline/richdocumentscode, задача #354 на GitHub «Security issue - Hack», 11 сентября 2026 г., https://github.com/CollaboraOnline/richdocumentscode/issues/354
2. CollaboraOnline/richdocumentscode, релиз 26.4.303, 11 сентября 2026 г., https://github.com/CollaboraOnline/richdocumentscode/releases/tag/26.4.303
3. GitHub, «REST API endpoints for issues», дата обращения: 26 октября 2026 г., https://docs.github.com/en/rest/issues/issues
4. Форум сообщества Nextcloud, «To Collabora Built-in User: Update ASAP», 3 октября 2026 г., https://help.nextcloud.com/t/to-collabora-built-in-user-update-asap/250516
5. Discourse, документация API, дата обращения: 26 октября 2026 г., https://docs.discourse.org/
6. CVE Program, запись CVE-2026-110447, 14 октября 2026 г., https://www.cve.org/CVERecord?id=CVE-2026-110447
7. CVE Services API, метаданные записи CVE-2026-110447, дата обращения: 26 октября 2026 г., https://cveawg.mitre.org/api/cve/CVE-2026-110447
8. NIST NVD, сведения о CVE-2026-110447, опубликовано 14 октября 2026 г., изменено 24 октября 2026 г., https://nvd.nist.gov/vuln/detail/CVE-2026-110447
9. NIST NVD, CVE Change History API, дата обращения: 26 октября 2026 г., https://nvd.nist.gov/developers/vulnerability-change-history
10. Collabora Online, бюллетень безопасности GHSA-g3vx-3m76-fghh, 14 октября 2026 г., https://github.com/CollaboraOnline/online/security/advisories/GHSA-g3vx-3m76-fghh
11. Collabora Online, «Stay Safe: Upgrade Everything Regularly», 14 октября 2026 г., https://www.collaboraonline.com/blog/stay-safe-upgrade-everything-regularly/
12. Censys, «Oct 16 Advisory: Collabora Online Built-in CODE Server OS Command Injection», 16 октября 2026 г., https://censys.com/advisory/cve-2026-110447/
13. CISA, «Known Exploited Vulnerabilities Catalog», дата обращения: 26 октября 2026 г., https://www.cisa.gov/known-exploited-vulnerabilities-catalog
14. CISA, JSON-фид KEV (версия 2026.10.23), дата обращения: 26 октября 2026 г., https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
15. CISA, «Reducing the Significant Risk of Known Exploited Vulnerabilities» (критерии KEV), дата обращения: 26 октября 2026 г., https://www.cisa.gov/known-exploited-vulnerabilities
16. Second Security, «The Patchless Window», октябрь 2026 г., https://thepatchlesswindow.com/
17. BleepingComputer, «Hackers exploit Collabora RCE flaw to backdoor Nextcloud servers», 15 октября 2026 г., https://www.bleepingcomputer.com/news/security/hackers-exploit-collabora-rce-flaw-to-backdoor-nextcloud-servers/
18. NIST, «NIST Updates NVD Operations to Address Record CVE Growth», 15 апреля 2026 г., https://www.nist.gov/news-events/news/2026/04/nist-updates-nvd-operations-address-record-cve-growth
19. Hacker News, API поиска Algolia, дата обращения: 26 октября 2026 г., https://hn.algolia.com/api
20. Hacker News, пост со ссылкой «Hackers exploit Collabora RCE flaw to backdoor Nextcloud servers», 15 октября 2026 г., https://news.ycombinator.com/item?id=50111052
21. Reddit r/NextCloud, сообщение администратора «Nextcloud compromised via the built-in Collabora app», 22 октября 2026 г., https://www.reddit.com/r/NextCloud/comments/1xcsjlx/nextcloud_compromised_via_the_builtin_collabora/
22. cisagov, репозиторий Vulnrichment, дата обращения: 26 октября 2026 г., https://github.com/cisagov/vulnrichment
23. FIRST, «EPSS Frequently Asked Questions», дата обращения: 26 октября 2026 г., https://www.first.org/epss/faq
24. CISA, «BOD 26-04: Prioritizing Security Updates Based on Risk», 10 июня 2026 г., https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
25. FIRST, EPSS «Get the Data» (включая API), дата обращения: 26 октября 2026 г., https://www.first.org/epss/data
26. CISA, «Stakeholder-Specific Vulnerability Categorization (SSVC)», дата обращения: 26 октября 2026 г., https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc
27. CISA, «Critical Zero-Day Vulnerabilities Exploited in Citrix NetScaler ADC, Gateway», 27 сентября 2026 г. (обновлено 9 октября), https://www.cisa.gov/news-events/alerts/2026/09/27/critical-zero-day-vulnerabilities-exploited-citrix-netscaler-adc-gateway
28. Citrix, бюллетень безопасности CTX697096, 27 сентября 2026 г., https://support.citrix.com/support-home/kbsearch/article?articleNumber=CTX697096
29. NIST NVD, сведения о CVE-2026-88771, 27 сентября 2026 г., https://nvd.nist.gov/vuln/detail/CVE-2026-88771
30. Форум Plex, «Important Security Update for Plex Media Server v1.43.2 and earlier», 1 сентября 2026 г., https://forums.plex.tv/t/important-security-update-for-plex-media-server-v1-43-2-and-earlier/942319
31. Agenzia per la Cybersicurezza Nazionale (ACN), «Plex Media Server: rilevato sfruttamento in rete delle catena di attacco Plex2Shell», октябрь 2026 г., https://www.acn.gov.it/portale/w/plex-media-server-rilevato-sfruttamento-in-rete-delle-catena-di-attacco-plex2shell
32. boredhackerblog, «Plex vulnerabilities being exploited in the wild to drop a cryptominer», 17 октября 2026 г., https://www.boredhackerblog.info/2026/10/plex-vulnerabilities-being-exploited-in.html
33. CISA, «CISA Adds Six Known Exploited Vulnerabilities to Catalog», 20 октября 2026 г., https://www.cisa.gov/news-events/alerts/2026/10/20/cisa-adds-six-known-exploited-vulnerabilities-catalog
34. NIST NVD, сведения о CVE-2026-96652, 23 сентября 2026 г., https://nvd.nist.gov/vuln/detail/CVE-2026-96652
35. AWS Security Blog, «Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot», 21 октября 2026 г., https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
36. CERT-EU, бюллетень безопасности 2026-018 «Critical Vulnerabilities in PHP», 20 октября 2026 г., https://cert.europa.eu/publications/security-advisories/2026-018
37. NIST NVD, сведения о CVE-2026-109618, 21 октября 2026 г., https://nvd.nist.gov/vuln/detail/CVE-2026-109618
38. CISA, «CISA Adds One Known Exploited Vulnerability to Catalog» (CVE-2026-110447), 23 октября 2026 г., https://www.cisa.gov/news-events/alerts/2026/10/23/cisa-adds-one-known-exploited-vulnerability-catalog-0
39. Akhoundali et al., «GitHub Engagement Signals for CVE Prioritization: The GitHub Popularity Metric (GPM)», arXiv 2609.31004, 25 сентября 2026 г., https://arxiv.org/abs/2609.31004
40. «Time-Series and Social-Media Threat Analytics over a Deployed Cyber-Threat Knowledge Graph», Information 17(8):794, 19 августа 2026 г., https://www.mdpi.com/2078-2489/17/8/794
41. Ech-Chammakhy et al., «STINER: Automated Extraction of Strategic Cyber Threat Intelligence from X», arXiv 2608.14418, 14 августа 2026 г., https://arxiv.org/abs/2608.14418
42. Sabottke, Suciu, Dumitraș, «Vulnerability Disclosure in the Age of Social Media: Exploiting Twitter for Predicting Real-World Exploits», USENIX Security 2015, https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/sabottke
43. Справочный центр X, «How to use advanced search», дата обращения: 26 октября 2026 г., https://help.x.com/en/using-x/x-advanced-search
44. NIST NVD, документация API CVE, дата обращения: 26 октября 2026 г., https://nvd.nist.gov/developers/vulnerabilities
45. The Hacker News, «Hackers Backdoor Nextcloud Servers Through Critical Flaw in Collabora’s Built-in CODE App», октябрь 2026 г., https://thehackernews.com/2026/10/hackers-backdoor-nextcloud-servers.html