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

Короче, что в дайджесте?

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

• Внешний периметр. Citrix NetScaler, MikroTik RouterOS и WordPress оказались в центре внимания из-за сообщений об эксплуатации уязвимостей.
• Фишинг и удалённый доступ. Исследователи массово описывали кампании против российских организаций, в которых использовались вредоносные рассылки, украденные VPN-учётные записи и легитимные инструменты удалённого подключения.
• Цепочка разработки. Вредоносные пакеты и расширения могут превратить рабочее место разработчика в источник утечки ключей, токенов и облачных секретов.
• Финансовые атаки. Android-троян RedWing и FMVT RAT демонстрируют риски для мобильных устройств, бухгалтерских рабочих мест и систем дистанционного банковского обслуживания.
• Готовность к инцидентам. Резервные копии, контроль клиентских данных и проверка доверенных интеграций остаются практическими задачами, а не формальностью.
• План действий и приоритеты исправлений. Подготовили для вас таблицу с планом действий и рекомендации по срочности исправлений.

Дисклеймер

Берегись, внешний периметр

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

В сентябре внимание привлекли три продукта: Citrix NetScaler, MikroTik RouterOS и WordPress Core.

• По Citrix NetScaler в конце сентября были опубликованы данные об активной эксплуатации CVE-2026-88772 (CyberOK News, Google Cloud Threat Intelligence); вендорский и исследовательский контекст также указывают на CVE-2026-88771, а текущая оценка UPS относит обе записи к Emergency / IR.
• Для MikroTik RouterOS в сентябре появилась публикация об атакующей цепочке CVE-2026-67279/CVE-2026-86060, а также уведомление НКЦКИ и соответствующие записи в каталогах уязвимостей.
• В случае WordPress Core сообщалось о попытках эксплуатации CVE-2026-87902 (CyberOK News, Kaspersky, The Hacker News). Здесь важно искать не только сам факт использования WordPress, но и конкретные признаки атаки, включая попытки подключения локальных PHP-файлов и записи временных файлов.

Что это значит для бизнеса?

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

Фишинг жив!

Как проникнуть в организацию, если технические средства защиты работают, а известные уязвимости закрыты? На помощь злоумышленнику приходит доступ через сотрудника компании.

В сентябре исследователи описали несколько кампаний против российских организаций.

• F6 исследовала Mimbrob против ВПК, IT-компаний и военных;
• BI.ZONE сообщила о LxBase RAT в массовых рассылках июля-сентября против российских компаний.
• Kaspersky описала активность NightEagle в инфраструктуре российских компаний с использованием скомпрометированных VPN-учётных записей, GhostContainer на Exchange, Dev Tunnels и rdp2tcp;
• Positive Technologies исследовала DENOmination Group, использовавшую цепочки на Deno, а Kaspersky также выделила Toy Ghouls с MQTT/Matrix-бэкдорами.

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

Что это значит для бизнеса?

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

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

Разработчик, не спи!

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

• В сентябре Aikido сообщила о повторном появлении вредоносной нагрузки Shai-Hulud в npm и о заражённом пакете pub.dev universal_file_viewer 0.1.5.
• Socket описала описала компрометацию MemTensor в npm и PyPI как атаку на цепочку поставки с кражей учётных данных.
• Отдельно отмечены многочисленные VPN/proxy-расширения Chrome для русскоязычных пользователей, компрометация виджетов через Brevo, и ClickFix-ловушка на домене third-party.com, который часто используют как условный пример в документации – человека убеждают самому запустить вредоносную команду и выполнить атаку собственными руками.

Что это значит для бизнеса?

Компрометация аккаунта разработчика или стороннего компонента может поставить под угрозу сразу несколько систем: от исходного кода и процессов сборки до облачной инфраструктуры и данных клиентов. При этом атака может развиваться через инструменты и каналы, которым компания уже доверяет, поэтому обнаружить её сложнее.

Банковские трояны: от телефона до бухгалтерского компьютера

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

• В сентябре F6 описала Android-троян RedWing, распространявшийся в России через поддельные приложения и видео, с удалённым управлением, перехватом SMS, оверлеями и проксированием.
• Также F6 отдельно описывали троян удалённого доступа FMVT RAT, ориентированный на бухгалтерские рабочие места, считыватели смарт-карт и операции дистанционного банковского обслуживания.

Что это значит для бизнеса?

Если мобильное устройство сотрудника используется для подтверждения операций, его компрометация может повлиять на безопасность финансовых процессов. В свою очередь, заражение бухгалтерской станции создаёт риски для работы с системами ДБО и платежей.

В доступных материалах не перечислены конкретные банки, пострадавшие от RedWing или FMVT RAT, поэтому описанные угрозы следует рассматривать как основание для оценки собственных сценариев защиты, а не как подтверждение компрометации определённой организации.

Руки вверх: клиентские данные и вымогательство

Отраслевые сигналы сентября напоминают о рисках, которые не всегда заметны в технических отчётах: остановке критичных процессов и необходимости корректно реагировать на возможную утечку данных.

• В сентябре российское деловое СМИ со ссылкой на выступление руководителя крупного регионального медучреждения сообщило о кибератаке с требованием выкупа; данные на серверах, по этому сообщению, удалось восстановить благодаря резервному копированию. Это не раскрывает технический вектор атаки и не доказывает более широкую кампанию, но даёт практический сигнал для организаций с критичными медицинскими, кадровыми и финансовыми данными.
• SecPost сначала пересказал заявление злоумышленников крупной утечке у российской сети общественного питания, а затем сообщил о позиции компании: она признала кибератаку на ИТ-систему, допустила попадание в открытый доступ части клиентских данных, указала на отсутствие платёжной информации в затронутом контуре, блокировку доступа атакующих и уведомление регулятора. Масштаб и состав утечки остаются заявлением сторон и не подтверждены независимым техническим разбором.

Что это значит для бизнеса?

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

А что делать? Приоритеты для ИБ-команд

1.     Выделить срочное окно для проверки внешне доступных систем.

Citrix NetScaler, MikroTik RouterOS, WordPress: для каждого продукта установите точную версию, доступность извне, наличие исправлений и признаки эксплуатации. Не присваивайте всем системам одинаковый приоритет: учитывайте бизнес-критичность, достижимость уязвимой функции и наличие следов компрометации.

2.     Искать следы проникновения.

Поручите SOC и администраторам почты/VPN/Exchange поиск следов до текущей даты или на доступную глубину журналов: фишинговые вложения, подозрительные VPN-входы, туннели, RDP-переходы и новые службы на серверах.

3.     Проверить цепочку разработки и секреты.

Проведите инвентаризацию зависимостей, расширений редакторов и используемых пакетов. Сопоставьте их с конкретными вредоносными версиями и индикаторами из исследовательских материалов. Проверьте токены CI/CD, ключи публикации, доступы к репозиториям и облачные секреты. Если подтверждена компрометация, отзывайте и заменяйте именно затронутые секреты после проверки артефактов и возможного использования.

4.     Усилить контроль доверенных каналов

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

5.     Связать ИБ и антифрод

Для банков и компаний с ДБО объедините анализ событий на бухгалтерских станциях, мобильных устройствах и платёжных операциях. Проверьте сценарии выявления RedWing и FMVT RAT, а также необычной активности в системах удалённого доступа.

6.     Проверить восстановление и реагирование на утечки

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

7.     Как определить, что исправлять срочно

Чтобы определять срочность исправления уязвимостей, мы в СайберОК запустили открытый каталог уязвимостей cKEV Index. Система опирается на Urgent Patch Score (UPS) — методику приоритизации, благодаря которой уязвимость рассматривается как объект, который «созревает» во времени. Важна не только оценка, но и конкретные события: появился PoC, был собран готовый эксплойт или подтвердилось использование уязвимости в атаках.

• Urgent Patch означает «исправить срочно»;
• Emergency / IR — немедленно обновить систему и проверить возможный взлом.
• Баллы (cKEV score) — компактное число для сортировки очереди, полученное из UPS-сигналов. Чем выше — тем ближе к немедленному действию.

KEV подтверждает известную эксплуатацию, но итоговый приоритет зависит от конкретной инфраструктуры организации.

*Оценки приведены на дату сбора; историческое значение на конец отчётного периода не восстанавливалось. Отсутствие оценки не означает низкий риск.

План действий

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

• Метка P1 означает срочную задачу, которую нужно выполнять сразу, если условие относится к вам.
• Метка P2 означает плановую задачу, которую выполняют в указанный срок.
• При признаках проникновения сразу начинайте реагирование.

Не пытайтесь закрыть все угрозы сразу

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

1. Есть ли у нас затронутая система или компонент?
2. Может ли атакующий добраться до него и есть ли признаки, что он уже это сделал?
3. Какие последствия будут для бизнеса, если атака удалась?

Ответы помогут отделить общие сигналы об угрозах от действительно срочных задач.

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

Чем больше находок, тем острее вопрос: что исправлять первым? За каждым обновлением стоят люди и время. Если обнаружение ускоряется, а устранение остаётся на прежнем уровне, растёт очередь открытых проблем.

Поэтому мы открываем cKEV Index — каталог приоритетных уязвимостей СайберОК на основе методики Urgent Patch Score (UPS). В нём собраны проблемы, требующие срочного внимания, и события, которые объясняют их приоритет: появление эксплойта, подтверждение атак и другие свидетельства. В открытой версии представлены стадии Urgent Patch и Emergency / IR с сокращённой историей событий.

Один дома

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

В сентябрьском отчёте Anthropic описаны два показательных случая. В кампании GTG-50014 злоумышленники использовали ИИ на разных этапах — от разведки до эксплуатации и обработки похищенных данных. Один из них организовал массовый разбор Android-приложений для поиска ключей и учётных данных. В случае GTG-50029 одиночный атакующий применял агентов для разведки, анализа кода и проверки находок. Claude помог ему разработать и отладить эксплойт, сработавший, как минимум, на четырёх сайтах.

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

В СайберОК мы видим рост возможностей поиска не только ещё неизвестных уязвимостей, но и удешевление разработки эксплойтов к уже раскрытым недостаткам — 1-day. Для атак на массовый продукт второй путь особенно привлекателен: описание проблемы и выпущенное исправление дают готовую отправную точку.

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

Горшочек, не вари

Исследователи и разработчики используют те же возможности. Наш пример — открытый фреймворк rust-in-peace, который эксперты СайберОК развивают для анализа безопасности программ с помощью ИИ-агентов. Он объединяет несколько способов поиска, проверку гипотез, воспроизведение ошибок и проверку исправлений.

Публичный реестр проекта содержит около сотни находок, направленных разработчикам проектов с открытым исходным кодом, включая ядро Linux.

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

Даже у крупных разработчиков эта работа уже влияет на график выпуска обновлений.

Так, в августовской публикации Where is Exchange SE CU1 anyway? команда Microsoft объяснила задержку первого накопительного обновления Exchange Server Subscription Edition тем, что использование ИИ увеличило объём находок. Каждую из них необходимо подтвердить, воспроизвести, исправить и проверить на регрессии. При этом, ежемесячные обновления безопасности продолжали выходить. Но для выпуска CU1 команда ждала более спокойного месяца: выпускать большое обновление и сразу заставлять администраторов устанавливать следующее, означало бы, удвоить их работу.

Другой пример — Oracle в июльском Critical Patch Update сообщила об исправлении 1434 различных CVE. На тот момент это был крупнейший выпуск обновлений безопасности компании. Среди причин Oracle назвала расширение охвата продуктов, применение ИИ для обнаружения проблем и ускорение разработки исправлений. Да, это квартальное обновление, и не все уязвимости нашёл ИИ. Но тенденция понятна. По нашей оценке, до насыщения ещё далеко.

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

Игры разума или как совладать со следующей волной

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

Что приходит на ум, когда стоит задача приоритизации угроз?

CVSS Base описывает техническую тяжесть уязвимости; дополнительные метрики CVSS учитывают угрозы и особенности среды. EPSS оценивает вероятность эксплуатации CVE в реальных атаках в ближайшие 30 дней (документация CVSS, EPSS FAQ).

Однако выбрать стратегию исправлений по одному EPSS не получается. В работе Prediction Meets Patch Queues: Empirical Limits of EPSS-Only Prioritization Using CISA KEV Additions in 2025 мы проверили распространённый подход: исправлять всё, у чего прогнозируемая вероятность выше выбранного порога.

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

В реальной инфраструктуре к этому добавляются вопросы: установлен ли уязвимый продукт, доступна ли нужная функция, какие права требуются атакующему, что он сможет сделать? Сколько времени займёт обновление и можно ли до него ограничить доступ к опасной функции?

Обстановка тоже меняется. В понедельник опубликовано описание дефекта, в среду появились подробности его воспроизведения — PoC, а в пятницу — готовый модуль эксплуатации. Позже разработчик подтвердил использование уязвимости в атаках. Техническая тяжесть осталась прежней, а срочность выросла.

UPS учитывает эту историю при выборе следующего действия.

Время, вперёд!

Методика описана в исследовании СайберОК UPS Meets Patch Queues: Evidence-timeline prioritization under limited capacity, cadence, and compliance gravity.

UPS собирает проверяемые сигналы: публикации, появление инструментов эксплуатации, сведения об атаках. У каждого события есть дата и источник. По мере поступления сведений уязвимость переходит в следующую фазу работы. Сильный сигнал может сразу поднять её приоритет: проходить все ступени по порядку необязательно.

Каждую фазу можно связать с действиями команды. Конкретные сроки и ответственных задаёт сама организация.

На стадии Emergency команда проверяет, затронуты ли её системы, и ищет следы возможной атаки. Решение о начале расследования принимает по результатам этой проверки.

В таксономии UPS отдельно учитываются публикация PoC, появление готового средства эксплуатации и подтверждение атак. Для сильных сигналов установлена максимальная срочность. Повторные пересказы одного сообщения отсеиваются, чтобы популярность новости не умножала её вес.

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

Показания приборов

В открытой версии cKEV показаны две наиболее срочные стадии UPS — Urgent Patch и Emergency / IR. В карточке есть балл cKEV, фаза и сокращённая история событий. Дополнительные поля содержат описание, CVSS, EPSS, сведения об эксплуатации, ссылки и рекомендации — по мере наличия данных.

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

Сначала смотрите на фазу: сильное свидетельство способно поднять срочность даже при небольшой сумме баллов. Затем разберите событие, которое повлияло на решение, и найдите затронутые системы. Порядок работы получается такой: фаза → основание → системы → действие.

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

Дело техники

Чтобы запись из каталога стала задачей для ИТ, её нужно связать с конкретной системой, ответственным и способом устранения.

1.       Проверьте, затронуты ли ваши системы. Сопоставьте запись с инвентаризацией и результатами проверки внешнего периметра. Уточните версию, конфигурацию, включённые функции и доступ к ним. Одного совпадения названия продукта для этого мало.

2.       Определите последствия и ближайшее действие. Что получит атакующий при успешной эксплуатации? Можно ли установить обновление сейчас? Если потребуется время, выберите временную меру из рекомендаций разработчика: ограничение доступа, отключение функции или изменение конфигурации. Проверьте, что она действительно закрывает опасный путь.

3.       Назначьте ответственного и срок. В задаче должны быть указаны сервис, необходимое изменение и способ проверки результата. Один пакет обновлений может закрыть несколько CVE. Одна CVE может потребовать отдельных изменений в нескольких системах.

4.       Следите за новыми событиями. Готовый эксплойт, подтверждённые атаки или обход исправления могут потребовать пересмотра срока. У задачи должен быть понятный порядок ускоренного согласования.

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

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

Часть работы уже сделана: известны системы, ответственный, порядок обновления и проверки. Можно пересмотреть срок и при необходимости ввести временную меру. Если начать разбор только после экстренного сообщения, все эти действия придётся выполнять одновременно.

В этом и польза ранних стадий UPS: команда получает время на подготовку.

День сурка

Сколько задач начинать заранее? Глубокий разбор каждого слабого сигнала быстро займёт всё время. Ожидание подтверждённых атак оставит команду с подготовкой и установкой обновления в последний момент.

В исследовании UPS мы проверили этот компромисс в модели очереди с ограниченной пропускной способностью. В выборке было 245 уязвимостей, добавленных в CISA KEV в 2025 году. При разных ограничениях пропускной способности 35–53% задач удавалось завершить к дате включения уязвимости в KEV за счёт более ранних сигналов. Контрольной точкой служила дата включения в каталог, к которой эксплуатация уже была подтверждена (исследование и материалы).

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

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

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

Две очереди

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

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

У заказчика очередь состоит из изменений в его инфраструктуре. СКИПА и PentOps помогают найти доступные системы и проверить их защищённость. Сведения об уязвимости объясняют срочность. Ответственный за сервис планирует обновление с учётом его последствий для бизнеса.

Доступ открыт

Ограниченная версия cKEV Index доступна публично: открыть каталог. В ней представлены стадии Urgent Patch и Emergency / IR с сокращённой историей событий.

Полная версия и API доступны пользователям CyberOK СКИПА, PentOps и Vulnum. Через API данные можно включить в собственный процесс управления уязвимостями.

Методика, таксономия сигналов и исследовательские материалы также опубликованы.

Для начала выберите несколько записей по продуктам, которые используются у вас. Найдите затронутые системы, разберите причину срочности и проверьте, назначены ли ответственный и срок устранения.

Эксперты СайберОК снова полезли туда, куда по доброй воле никто не ходит — в лог-болото и разведданные СКИПА. Не из праздного любопытства, а чтобы разобраться! Как водится, прошлись по инстансам, сверили телеметрию и посмотрели на вещи трезво: какие уязвимости действительно могут испортить жизнь Рунету, а какие просто эффектно всплывали в новостных лентах и так же быстро исчезали.

Исследования, приведённые в статье, выполнялись исключительно на уровне внешнего периметра в сети Интернет и могут выявлять только те векторы и артефакты, которые доступны извне (публичные сервисы, открытые порты, публичные конфигурации и метаданные). Эти результаты не отображают состояние внутренней инфраструктуры, сетевой сегментации, конфигураций на хостах, контроля привилегий или телеметрии. Для корректной и полной оценки уровня безопасности нужно обязательно провести внутренние аудирование.

Обход аутентификации в telnetd / Press -f to pay respect (CVE-2026-24061)

CVSS: 9.8 | KEV: да | Упоминания СКИПА: 60+ | CybVSS: 566.7

Масштаб: На радарах СКИПА мы наблюдаем более 500 инстансов telnetd по косвенным признакам.

Описание: В GNU Inetutils до версии 2.7 telnetd позволяет обходить удаленную аутентификацию с помощью параметра "-f root" для переменной среды USER.

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

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

MongoDB Server / Сжатие с побочным эффектом (CVE-2025-14847)

CVSS: 8.8 | KEV: нет | Упоминания СКИПА: 60+ | CybVSS: 180.1

Масштаб: На радарах СКИПА мы наблюдаем ~6250 инстансов MongoDB Server, из которых потенциально уязвимы 98%.

Описание: В системе управления базами данных MongoDB выявлена уязвимость, связанная с некорректной обработкой размеров сжатых данных при использовании алгоритма zlib. Эксплуатация уязвимости позволяет неавторизованным пользователям несанкционированно получить доступ к конфиденциальной информации.

Что по факту: PoC публично доступен.

Вердикт: Автоматизированная атака маловероятна из-за особенностей эксплуатации, но риск целевых атак сохраняется. Срочно обновите систему!

n8n / ni8mare (CVE-2026-21858, а также CVE-2025-68613 / CVE-2025-68668)

CVSS: 10 | KEV: нет | Упоминания СКИПА: 50+ | CybVSS: 369

Масштаб: СКИПА фиксирует ~12300 доступных инстансов n8n, из которых потенциально уязвимы хотя бы к одной из уязвимостей 54%.

Описание: В версиях до 1.65.0 и после 1.121.0 злоумышленник может получить доступ к файлам на базовом сервере через выполнение рабочих процессов на основе форм. Если рабочий процесс уязвим, неаутентифицированный удаленный атакующий может получить доступ к конфиденциальной информации, что может привести к компрометации системы. Проблема решена в версии 1.121.0.

Что по факту: Демонстрация атаки доступна для публичного ознакомления, однако её успешное проведение требует предварительной подготовки. Хотя риск автоматизированных атак минимизирован, полностью исключать его нельзя.

Вердикт: Срочно обновите систему!

Apache Tika / PDF, который слишком много знал (CVE-2025-66516)

CVSS: 10 | KEV: нет | Упоминания СКИПА: 30+

Масштаб: На радарах СКИПА мы наблюдаем ~200 экземпляров Apache Tika, из которых потенциально уязвимы ~97%.

Описание: В модулях Apache Tika (tika-core, tika-pdf-module, tika-parsers) обнаружена критическая уязвимость XXE, позволяющая злоумышленнику внедрять внешние XML-сущности через специально созданный файл XFA в PDF.

Что по факту: На момент исследования публичных PoC не было. Сейчас существует несколько репозиториев с потенциальными демонстрациями эксплуатации, но их достоверность не подтверждена.

Вердикт: Проверить внешние активы, выполнить обновление.

React Server Components / DoS (CVE-2026-23864)

CVSS: 7.5 | KEV: нет | Упоминания СКИПА: 10+ | CybVSS: 41.9

Масштаб: СКИПА фиксирует ~26 000 доступных инстансов React Server Components, из которых потенциально уязвимы 33%.

Описание: В компонентах React Server Components выявлены уязвимости типа «отказ в обслуживании», затрагивающие пакеты react-server-dom-parcel, react-server-dom-turbopack и react-server-dom-webpack. Уязвимости эксплуатируются при отправке специально сформированных HTTP-запросов к точкам Server Function, что может привести к сбоям, нехватке памяти или чрезмерному использованию CPU. Риски зависят от уязвимого участка кода, конфигурации и самого приложения.

Что по факту: Фундаментальная асимметрия в парсере react-server-dom. POST-запрос вызывает неконтролируемую рекурсию. Итог: 100% CPU, Memory Spike и падение Node.js по OOM. Эксплуатация возможна без авторизации. Фиксируются попытки эксплуатации уязвимости в "дикой природе".

Вердикт: Срочно обновить React и Next.js, настроить WAF.

1C-Битрикс / Path Traversal, Sensitive Data Exposure (BDU:2025-16324 / BDU:2025-16325 / BDU:2025-16349 / BDU:2025-16350)

CVSS: 7.5 | KEV: нет | Упоминания СКИПА: 5+ | COK: да

Масштаб: СКИПА фиксирует ~1 500 000 доступных инстансов 1С-Битрикс, из которых потенциально уязвимы 3% (45 000 хостов!).

Описание: Исследователь СайберОК Роберт Торосян обнаружил несколько уязвимостей в популярных сторонних плагинах Esolutions, размещенных в каталоге решений 1С-Битрикс: Управление сайтом. Уязвимости в плагинах связаны с неверным ограничением имени пути к каталогу. Эксплуатация уязвимостей позволяет нарушителю, действующему удалённо, получить несанкционированный доступ к защищаемой информации.

Что по факту: Большая распространенность в РУ сегменте. Публичного PoC нет, вероятность автоматизированных атак снижена.

Вердикт: При наличии данного плагина на инстансах с 1С-Битрикс требуется обновление!

GeoServer / XXE (CVE-2025-58360)

CVSS: 9.8 | KEV: да | Упоминания СКИПА: 19+ | CybVSS: 341.3

Масштаб: СКИПА наблюдает в Рунете ~200 активных инстансов, из которых 50%+ потенциально уязвимы.

Описание: GeoServer — сервер с открытым исходным кодом для обмена геопространственными данными, имел уязвимость XML External Entity (XXE) в версиях 2.26.0-2.26.2 и 2.25.6. Уязвимость позволяла злоумышленникам определять внешние сущности через незащищенную конечную точку /geoserver/wms

Что по факту: ПО с достаточно высоким уровнем критичности. На момент исследования в Интернет имелся публично доступный валидный PoC.

Вердикт: Требуется срочное обновление, GeoServer также подвержен более серьезным уязвимостям, например, Remote Code Execution.

Fortinet / Множественные уязвимости в продуктах Fortinet (CVE-2025-59718 / CVE-2026-24858 / CVE-2025-59719 / CVE-2020-12812)

CVSS: 9.8 | KEV: да | Упоминания СКИПА: 190+ (в сумме)

Масштаб: СКИПА фиксирует 2400 функционирующих экземпляров FortiOS и FortiWeb. Из них более 50% потенциально уязвимы хотя бы к одной из выявленных проблем безопасности.

Описание: Данные уязвимости в различных версиях продуктов Fortinet (FortiOS, FortiProxy, FortiManager и др.) связаны с критическими недостатками в механизмах проверки подписей SAML, некорректной обработкой регистров имен пользователей и архитектурными ошибками аутентификации через FortiCloud SSO. Эти бреши позволяют злоумышленникам обходить проверку подлинности, включая двухфакторную аутентификацию, и получать несанкционированный доступ к устройствам и системам единого входа.

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

Вердикт: Для обеспечения безопасности необходимо незамедлительно обновить затронутые компоненты до актуальных исправленных версий, указанных производителем.

Adobe Commerce / Неправильная проверка входных данных (CVE-2025-54236)

CVSS: 9.1 | KEV: да | Упоминания СКИПА: 145+ | CybVSS: 497.4

Описание: Версии Adobe Commerce до 2.4.9-alpha2 подвержены уязвимости, связанной с неправильной проверкой вводимых данных. Злоумышленник может использовать эту уязвимость для перехвата сеанса, что увеличивает риск утечки конфиденциальной информации.

Что по факту: На радарах СКИПА на данный момент мы наблюдаем всего ~220 доступных извне хостов. Потенциально уязвимы 30%.

Вердикт: Критическая уязвимость, есть концептуальный PoC (то, как могла бы выглядеть уязвимость с логической точки зрения), но при этом распространенность на отечественном ландшафте низкая. Если имеете в своих активах, не стоит затягивать с обновлением — для эксплуатации не требуется взаимодействие с пользователем.

Fortinet / Обход авторизации (CVE-2025-59718)

CVSS: 9.8 | KEV: да | Упоминания СКИПА: 70+ | CybVSS: 492.5

Описание: В версиях Fortinet FortiOS и FortiProxy до 7.6.3, 7.4.10 и 7.2.14, а также в FortiSwitchManager до 7.2.6 и 7.0.5 обнаружена уязвимость в проверке криптографической подписи. Злоумышленник без авторизации может обойти систему единого входа в FortiCloud, используя специально сформированное ответное сообщение SAML.

Что по факту: В реалиях конца 2025 года, данные продукты Fortinet (за исключением FortiOS) встречаются крайне редко на внешнем периметре Рунета.

Вердикт: В Рунете нет живых инстансов.

Cisco AsyncOS / Обход авторизации (CVE-2025-20393)

CVSS: 10 | KEV: да | Упоминания СКИПА: 65+ | CybVSS: 193.1

Описание: В системе фильтрации спама Cisco AsyncOS для устройств Cisco Secure Email Gateway и Cisco Secure Email and Web Manager выявлена критическая уязвимость. Злоумышленники, не имеющие аутентификации, могут использовать её для выполнения команд с правами администратора на затронутом оборудовании. Проблема заключается в недостаточной проверке HTTP-запросов при карантинировании спама. Злоумышленник способен эксплуатировать уязвимость, отправив на устройство специально сформированный HTTP-запрос. Успешная атака позволяет выполнять произвольные команды в базовой операционной системе от имени суперпользователя.

Что по факту: Среди внешних активов однозначно можно задетектировать только AsyncOS. Для уязвимости нет публично доступных PoC'ов.

Вердикт: Всего в Рунете мы наблюдаем до 20 доступных хостов, из которых 15% потенциально уязвимы.

WatchGuard Fireware OS / RCE (CVE-2025-14733)

CVSS: 9.3 | KEV: нет | Упоминания СКИПА: 35+ | CybVSS: 145.5

Описание: В WatchGuard Fireware OS обнаружена уязвимость, позволяющая удалённому неаутентифицированному злоумышленнику выполнять произвольный код при записи за пределы допустимого диапазона. Уязвимость распространяется на VPN для мобильных пользователей, использующих IKEv2 и на VPN для филиалов с IKEv2 и динамическим шлюзом. Она затрагивает следующие версии Fireware OS:

• от 11.10.2 до 11.12.4_Update1;
• от 12.0 до 12.11.5;
• от 2025.1 до 2025.1.3.

Что по факту: На момент исследования публичный PoC в сети недоступен.

Вердикт: В Рунете насчитывается до 180 хостов, 100% потенциально уязвимы. На момент исследования публично доступных PoC не выявлено, что снижает вероятность массовых и автоматизированных атак.

SmarterTools SmarterMail WT / Почта с сюрпризом (CVE-2025-52691)

CVSS: 10 | KEV: да | Упоминания СКИПА: 40+ | CybVSS: 173.1

Описание: Успешная эксплуатация уязвимости в системе SmarterTools SmarterMail WT позволяет неавторизованному злоумышленнику загружать произвольные файлы в любое место на почтовом сервере, потенциально обеспечивая удаленное выполнение кода.

Что по факту: В открытом доступе находятся Proof-of-Concept и nuclei-шаблоны, что свидетельствует о наличии у злоумышленников эффективных инструментов для проведения атак. Это создает предпосылки для повышения вероятности автоматизированных атак. Хорошая новость: ПО специфичное, эксперты СайберОК обнаружили всего 2 потенциально подходящих под описания и классификацию хостов на просторах Рунета.

Вердикт: Страшно, но не в реалиях Российского сегмента.

Fortinet FortiSIEM / Специально сконструированный TCP (CVE-2025-64155)

CVSS: 9.8 | KEV: нет | Упоминания СКИПА: 30+ | CybVSS: 251.8

Описание: Некорректная нейтрализация специфических команд операционной системы в уязвимостях продуктов Fortinet FortiSIEM версий 7.4.0, 7.3.0–7.3.4, 7.1.0–7.1.8, 7.0.0–7.0.4 и 6.7.0–6.7.10 создаёт риск для несанкционированного выполнения команд или кода через специально сконструированные TCP-запросы.

Что по факту: На момент исследования в сети обнаружен публичный PoC, его достоверность не была проверена. В РУ-сегменте доступные извне хосты не обнаружены.

Вердикт: В Рунете не встречается на внешнем периметре.

MOVEit Transfer/ Гроза интернета, но не Рунета (CVE-2023-34362)

CVSS: 9.8 | KEV: да | Упоминания СКИПА: 75+ | CybVSS: 614.5

Описание: В MOVEit Transfer до версий 2021.0.6, 2021.1.4, 2022.0.4, 2022.1.5 и 2023.0.1 обнаружена уязвимость SQL-инъекции. Злоумышленник может получить доступ к базе данных, вывести информацию и выполнить SQL-операторы. Уязвимость эксплуатируется через HTTP или HTTPS начиная с мая 2023 года. Подвержены все версии до указанных, включая старые.

Что по факту: Существует общедоступный PoC и nuclei-шаблоны, которые могут использоваться для автоматизированных атак.

Вердикт: Программное обеспечение данного типа не представлено в открытом доступе в российском сегменте Интернет.

Выводы

Декабрь–январь снова доказали прописную истину: важна не цифра CVSS, а то, насколько ПО распространено в Рунете, доступно извне и реально эксплуатируемо.

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

Пользуясь случаем, приглашаем вас в наш телеграм-канал, где мы регулярно рассказываем о самых показательных находках.

По данным СКИПА за последние три месяца можно выделить следующие тенденции:

• Общее число уязвимостей стабилизировалось после сентябрьского всплеска (октябрь: −38%, ноябрь: +3%).
• Количество критичных багов уменьшилось и держится на стабильном уровне (октябрь: −41%, ноябрь: −1%).
• Наблюдается быстрый рост наиболее опасных сценариев эксплуатации (октябрь: +109%, ноябрь: +17%).
• Количество KEV снизилось после сентябрьского пика, но в ноябре злоумышленники вновь активизировались (октябрь: −45%, ноябрь: +17%).

Интересно, что по данным зарубежного аналитика Jerry Gamblin, в ноябре 2025 было опубликовано всего 2 900 уязвимостей (а это на 29% меньше, чем в прошлом году!). Однако наша СКИПА зафиксировала 4 742 реальные уязвимости за тот же период. Почему? Разница объясняется тем, что мы используем 15 источников, включая зарубежные CNA, бюллетени вендоров, технические advisories, активные PoC и телеметрию попыток эксплуатации. На самом деле, угроз меньше не стало — просто часть уязвимостей в ноябре не успела получить идентификатор. СКИПА фиксирует такие случаи напрямую - поэтому наш анализ риска остаётся точнее и чувствительнее.

Теперь, когда есть общий фон, посмотрим, какие уязвимости действительно попали в зону риска, а какие просто запугивали без причины.

TOП: Высокий риск + высокий охват в Рунете

Раскрытие данных в Squid (CVE-2025-62168)

CVSS: 7.5 | KEV: да

Масштаб: На радарах СКИПА мы наблюдаем ~140.000 инстансов Squid, из которых уязвимы около 72%.

Описание: В версиях Squid до 7.2 из-за некорректной обработки ошибок происходило непреднамеренное раскрытие учётных данных, используемых при HTTP-аутентификации. Уязвимость позволяла обходить механизмы защиты и перехватывать токены безопасности или другие чувствительные данные доверенного клиента, в том числе применяемые внутри веб-приложений, использующих Squid для балансировки нагрузки на серверную часть приложения.

Что по факту: Критическое ПО, высокая распространенность в Рунете.

Вердикт: Cерьёзная уязвимость, в открытом доступе есть PoC, требуется срочное обновление.

SuiteCRM / Кто не экранирует — тот рискует (CVE-2025-64492 / BDU:2025-10914)

CVSS: 8.8 | KEV: нет | СOK*: да

Масштаб: На радарах СКИПА мы наблюдаем ~1000 инстансов SuiteCRM, из которых уязвимы около 5% (на момент публикации информации в БДУ)

Описание: В одном из компонентов SuiteCRM была обнаружена уязвимость, связанная с внедрением SQL-кода вслепую по времени. Эта уязвимость позволяет злоумышленнику, прошедшему аутентификацию, получать данные из базы, измеряя время отклика, что потенциально может привести к извлечению конфиденциальной информации.

Что по факту: Публичный PoC отсутствует, доля потенциально подверженных инстансов снизилась примерно до 5%, что демонстрирует слаженную и оперативную работу по управлению уязвимостями.

Вердикт: Риск автоматизированной атаки сильно снижен благодаря оперативному устранению уязвимости и обновлению уязвимых хостов.

TrueConf Server / Что там за кулисами? (BDU:2025-13736 / BDU:2025-13737 / BDU:2025-13738 / BDU:2025-11412)

CVSS: 5.3 - 8.1 | KEV: нет | СOK: да

Масштаб: На радарах СКИПА мы наблюдаем ~11.000 инстансов TrueConf, из которых уязвимы около 30% для цепочки и 15% для XSS.

Описание: Цепочка уязвимостей включает обход авторизации, отсутствие ограничений на количество попыток входа и уязвимость, позволяющую выполнять команды операционной системы. Также обнаружена отдельная отражённая XSS-уязвимость, которая может помочь миновать первый и второй этап при автоматизированной эксплуатации.

Что по факту: Публичный PoC отсутствует, уязвимость оперативно устранена, риск автоматизированных атак снижен.

Вердикт: Обновить TrueConf Server до версии 5.5.2. Рекомендуется ограничить доступ к административному интерфейсу, внедрить fail2ban или альтернативные средства защиты серверов от атак методом перебора, настроить WAF/IDS, проверить и сбросить учётные данные администраторов, провести аудит логов и процессов.

RCE в компонентах React Server / Реактивная паника (CVE-2025-55182)

CVSS: 10.0 | KEV: нет

Масштаб: На радарах СКИПА мы наблюдаем более 40.000 инстансов React, которые могут использовать React Server Components, из них уязвимы примерно 40%.

Описание: В компонентах React Server Components версий 19.0.0, 19.1.0, 19.1.1 и 19.2.0, включающих пакеты react-server-dom-parcel, react-server-dom-turbopack и react-server-dom-webpack, обнаружена уязвимость удалённого выполнения кода без предварительной аутентификации. Проблема заключается в небезопасной десериализации полезных данных из HTTP-запросов к конечным точкам функций React Server Components.

Что по факту: Усложнение атак на React связано с тем, что признаки присутствия компонентов на хосте не всегда легко обнаруживаются, что затрудняет их идентификацию. В сети активно обсуждаются PoC и лаборатории для воспроизведения данной уязвимости, единого мнения на этот счет нет, но на данный момент сам автор находки подчеркивает неоднозначность эксплойтов и предупреждает о возможной путанице и ложноположительных результатах.
Предположительно, для успешной атаки требуется знать значение Server Reference ID.

Вердикт: Критическая уязвимость, которая с бешеной скоростью набирает обороты эксплуатации в дикой природе, патчить незамедлительно! СКИПА зафиксировала 70+ (!) упоминаний данной уязвимости в сети Интернет.

АНТИТОП: Высокий риск + низкий охват в Рунете

Grafana / Укради админки (CVE-2025-41115)

CVSS: 10.0 | KEV: нет | Упоминания СКИПА: 25+

Масштаб: На радарах СКИПА мы наблюдаем ~24.000 инстансов Grafana, из которых уязвимы около 2%.

Описание: При включённом и корректно настроенном SCIM, злоумышленник может отправить специально сформированные запросы к уязвимому инстансу, что позволит захватить учетную запись существующего пользователя вплоть до администратора или создать нового пользователя с высокими привилегиями.

Что по факту: Grafana Cloud и лицензированные облачные провайдеры получили патчи и подтверждают, что их сервисы защищены. Grafana OSS не затронута.

Вердикт: Критическая уязвимость. В момент попадания уязвимости в поле зрения СКИПы, система обнаружила публичный PoC в открытом доступе. Уязвимость легко эксплуатируется на тех инстансах, где остаются токены по умолчанию. Но при этом, массового распространения в Рунете нет, так как требуется специфичная конфигурация Grafana Enterprise и SCIM

PaperCut NG / Обход авторизации (CVE-2023-27350)

CVSS: 9.8 | KEV: да | Упоминания СКИПА: 55+

Описание: Уязвимость позволяет удаленным злоумышленникам обходить аутентификацию на уязвимых установках PaperCut NG.

Что по факту: Исторически, СКИПА знает около 11.000 инстансов, но на момент исследования живых хостов не обнаружено.

Вердикт: В Рунете нет живых инстансов.

Apache Struts / RCE (CVE-2018-11776)

CVSS: 8.1 | KEV: да | Упоминания СКИПА: 55+

Описание: Apache Struts подвержен удаленному выполнению кода, когда alwaysSelectFullNamespace имеет значение true. Уязвимость возникает в случае, если результаты используются без указания пространства имен, при этом верхний пакет либо не имеет пространства имен, либо использует подстановочные знаки. Аналогичная ситуация наблюдается при использовании тега URL, если для него не заданы значения и действия, а верхний пакет не имеет пространства имен или использует подстановочные знаки.

Что по факту: В РУ сегменте Интернета не обнаружено активных экземпляров данного ПО.

Вердикт: Риск для Рунета минимален.

SPIP / RCE (CVE-2023-27372)

CVSS: 9.8 | KEV: нет | Упоминания СКИПА: 25+

Описание: SPIP до версии 4.2.1 допускает удаленное выполнение кода через значения форм в публичной области, поскольку сериализация обрабатывается неправильно.

Что по факту: Есть публичный PoC и публичные nuclei шаблоны.

Вердикт: В русскоязычном сегменте Интернета случаи эксплуатации маловероятны, риск массовых автоматизированных атак низкий.

Sitecore XP / RCE (CVE-2021-42237)

CVSS: 9.8 | KEV: да | Упоминания СКИПА: 15+

Описание: В Sitecore XP возможна небезопасная десериализация, позволяющая удалённо выполнять команды на хосте. Эксплуатация не требует аутентификации и специальных настроек.

Что по факту: В ноябре были упоминания данной уязвимости, в сети есть публичный nuclei-шаблон, есть риск автоматизированных атак.

Вердикт: Уязвимость представляет серьёзную угрозу, однако в Рунете крайне мало экземпляров данного ПО, что снижает приоритет для массовых атак. Тем не менее, для уязвимых систем необходимо провести обновление и внедрить защитные меры.

Выводы

Ноябрь вновь показал, что в уязвимостях главное не цифра CVSS, а сочетание массовости ПО и простоты эксплуатации. Именно поэтому в зоне реального риска оказываются Squid и TrueConf — они широко распространены в Рунете, и ошибки в них потенциально приводят к серьёзным инцидентам.

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

Наш совет: обновлять нужно всё, но первый приоритет отдаём тем сервисам, которые действительно стоят у вас на периметре и имеют подтверждённые векторы эксплуатации. Это и есть реальная кибергигиена.

Мы каждый день копаемся в периметре Рунета и делимся самыми интересными находками. Подписывайтесь на наш телеграм, чтобы не пропустить важное.

Как вы провели Хэллоуин? Вот мы в СайберОК качественно повеселились и попугались, ведь наши эксперты-охотники на привидений до самого рассвета рыскали по внешнему периметру Рунета и вытаскивали на свет главных монстров октября – как новых, так и хорошо забытых старых.

TOП: Высокий риск + высокий охват в Рунете

RCE в Microsoft WSUS / Обновить нельзя эксплуатировать (CVE-2025-59287)

CVSS: 9.8 | KEV: да

Масштаб: На радарах СКИПА мы наблюдаем ~300 инстансов Microsoft WSUS SimpleAuthWebService, из которых уязвимы около 40%.

Описание: Критическая уязвимость RCE в службах обновления Microsoft Windows Server (WSUS). Проблема вызвана небезопасной десериализацией данных AuthorizationCookie с помощью BinaryFormatter в методе EncryptionHelper.DecryptData() . Уязвимость позволяет злоумышленнику без аутентификации выполнить удаленный код с привилегиями SYSTEM, отправив вредоносные зашифрованные файлы cookie на конечную точку GetCookie().

Что по факту: Критическое ПО, успешные кейсы эксплуатации уязвимости в дикой природе уже зафиксированы.

Вердикт: Cерьёзная уязвимость с KEV, срочно обновить.

BIND 9 / Cache Poisoning (CVE-2025-40778)

CVSS: 8.6 | KEV: нет

Масштаб: На радарах СКИПА мы наблюдаем ~4.100 инстансов BIND-9, из которых уязвимы около 25%.

Описание: При определённых обстоятельствах BIND недостаточно валидирует записи в ответах, что позволяет злоумышленнику внедрять поддельные данные в кэш.

Что по факту: Публичный PoC доступен, злоумышленник способен внедрять поддельные записи в кэш уязвимого резолвера, что приведёт к подмене DNS-ответов для всех его клиентов (редирект трафика, подмена адресов сервисов и т.п.). Потенциально масштабная атака на незащищённые инстансы.

Вердикт: Серьёзная уязвимость — обновить BIND немедленно. До патча: ограничить рекурсивный доступ (ACL), запретить рекурсию на публичных серверах, включить/проверить DNSSEC на критичных зонах, мониторить нестандартные RRset в кэшe и логи ответов.

BIND 9 / Повышаем градус эксплуатации (CVE-2025-40780)

CVSS: 8.6 | KEV: нет

Масштаб: На радарах СКИПА мы наблюдаем ~4.100 инстансов BIND-9, из которых уязвимы около 25%.

Описание: Ослабление энтропии генератора псевдослучайных значений, используемого для формирования transaction ID и source port. Сужение пространства возможных комбинаций значительно повышает вероятность успешного угадывания полей, по которым резолвер сопоставляет ответы с запросами.

Что по факту: В сочетании с уязвимостью в обработке unsolicited RRs (CVE-2025-40778) сниженная случайность делает приёмы форженных ответов гораздо более надёжными — публичный PoC показывает практическую пригодность этой техники. Риск — массовая подмена кэша при таргетинге уязвимых резолверов.

Вердикт: Критично — поставить патч как можно скорее. До патча: по возможности ограничить исходящие/входящие порты, использовать NAT/порт-рандомизацию на сетевом уровне, включить DNSSEC, отслеживать аномалии в совпадениях transaction ID/port и рассмотреть перевод критичных клиентов на надёжные внешние резолверы.

АНТИТОП: Высокий риск + низкий охват в Рунете

CrushFTP / Гонка за креслом admin (CVE-2025-31161)

CVSS: 9.8 | KEV: да | Упоминания СКИПА: 50+

Описание: CrushFTP версии до 10.8.4 / 11.x до 11.3.1 содержат уязвимость, позволяющую обойти аутентификацию и получить контроль над учётной записью crushadmin (если не используется прокси в DMZ). В методе авторизации AWS4-HMAC (S3-совместимой) в HTTP-компоненте FTP-сервера есть состояние гонки: сервер сначала вызывает login_user_pass() без запроса пароля — в этот момент сессия проходит проверку HMAC и считается аутентифицированной, а позднее сервер повторно проверяет пользователя.

Что по факту: В Рунете ~4000 экземпляров, есть публичный PoC и nuclei-шаблоны, но массовых кейсов эксплуатации подтвердить не удалось.

Вердикт: Cерьёзная уязвимость, однако активность в Рунете не зафиксирована массово.

Axigen / Обход 2FA (CVE-2023-23566)

CVSS: 9.8 | KEV: нет | Упоминания СКИПА: 5+

Описание: Уязвимость в Axigen 10.3.3.52 даёт возможность обхода двухэтапной аутентификации, что позволяет злоумышленнику получить доступ к ящику при подключении учётной записи к стороннему веб-почтовому сервису.

Что по факту: Уязвимости подвержена версия приложения 10.3.3.52. В Рунете инстансы с данной версией не обнаружены.

Вердикт: Опасна по сути, но для РФ-сегмента не актуальна.

Nest RCE / Небезопасная песочница (CVE-2025-54782)

CVSS: 8.8 | KEV: нет | Упоминания СКИПА: 10+

Описание: В версиях ≤0.2.0 в пакете @nestjs/devtools-integration была обнаружена критическая уязвимость удалённого выполнения кода (RCE). При активации пакет предоставляет доступ к локальному HTTP-серверу разработки с конечной точкой API, использующей небезопасную песочницу JavaScript.

Что по факту: В РУ сегменте не обнаружено активных инстансов данного ПО.

Вердикт: Крайне низкий риск для Рунета.

Moxa / Админская дверь без замка (CVE-2025-6892)

CVSS: 8.7 | KEV: нет | Упоминания СКИПА: 5+

Описание: В сетевых устройствах безопасности и маршрутизаторах Moxa обнаружена уязвимость, связанная с некорректной авторизацией. Изъян в механизме аутентификации API позволяет получить несанкционированный доступ к защищённым конечным точкам API, включая те, которые предназначены для выполнения административных функций. Эта уязвимость может быть эксплуатирована после входа в систему аутентифицированного пользователя, поскольку система не может должным образом проверить контекст сеанса и не ограничивает привилегии должным образом.

Что по факту: Не удалось оценить распространенность в Рунете.

Вердикт: Крайне низкая вероятность активной эксплуатации в РУ сегменте.

Grafana Image Renderer RCE / Хардкод ключик (CVE-2025-11539)

CVSS: 10 | KEV: нет | Упоминания СКИПА: 5+ | Cybvss: 54.6*

Масштаб: По данным СКИПА в Рунете работает ~150 активных инстансов, на момент исследования 100% из них уязвимы.

Описание: Grafana Image Renderer уязвим к удалённому выполнению кода из-за уязвимости записи произвольного файла. Это связано с тем, что конечная точка /render/csv не проходит проверку параметра filePath, что позволяет злоумышленнику сохранить общий объект в произвольном месте, а затем загрузить его процессом Chromium. Экземпляры уязвимы, если токен по умолчанию («authToken») не изменён или известен злоумышленнику.

Что по факту: Так как токен можно легко получить из исходного кода приложения, необходимо срочно изменить «authToken» на отличный от стандартного значения.

Вердикт: В Рунете такие экземпляры встречаются нечасто и не задерживаются на радарах.

XWiki Platform / RCE (CVE-2025-24893)

CVSS: 9.8 | KEV: да | Упоминания СКИПА: 30+

Описание: Уязвимость в XWiki реализуется через эндпоинт SolrSearch и позволяет любому пользователю выполнить произвольный код на хосте — без необходимости привилегий. Причина — недостаточная санитизация и/или некорректная обработка пользовательских параметров при формировании запросов/шаблонов для поискового компонента (Solr/механизмы шаблонизации).

Что по факту: В октябре был всплеск упоминаний уязвимости в публичных источниках. Эксперты СайберОК рассмотрели данную уязвимость в марте 2025 года: на момент исследования было приблизительно 7–8% уязвимых инстансов.

На сегодняшний день СКИПА видит примерно ~130 активных хостов с данным ПО в Рунете.

Вердикт: Уязвимость крайне опасная, но низкая распространённость в Рунете делает её менее приоритетной с точки зрения массовой эксплутации — однако для подверженных инстансов обновление и внедрение компенсирующих мер остаются обязательными.

Выводы

Может быть самая страшная ночь в году и осталась позади, но уязвимостям сон не ведом.

1. Знайте свой сетевой периметр — освятите его светом инвентаризации и патчей.
2. Если по сети ползёт эксплойт — действуйте без промедления, пока тени не окутали ваши сервисы.
3. Даже редкие уязвимости могут ожить в полночь — удавите их прямо в колыбели.

И пусть ваши системы вздохнут спокойно под покровом обновлений.

В нашем телеграм-канале — кладовая знаний по кибербезопасности и мониторингу внешних атак. Заглядывайте.

Фаззинг — один из ключевых методов поиска уязвимостей и скрытых ресурсов на веб-серверах. Однако классический подход, использующий статические словари, часто неэффективен: он генерирует огромное количество бесполезных запросов и при этом может пропускать специфичные для целевого приложения директории и файлы. В данной статье рассматриваются методы оптимизации этого процесса с использованием краулинга, детектирования технологий и больших языковых моделей (LLM). Мы покажем, как комбинация этих методов позволяет значительно расширить охват поиска при одновременном сокращении количества запросов к серверу, делая процесс анализа более целенаправленным и эффективным.

Введение

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

Поиск скрытых директорий и файлов — одна из рутинных, но критически важных задач при оценке безопасности веб-приложений. Стандартный подход, однако, часто напоминает поиск иголки в стоге сена. Инструменты вроде ffuf перебирают тысячи путей из заранее подготовленного универсального словаря, который содержит всё — от путей для PHP и ASPX до файлов бэкапов и конфигураций для десятков фреймворков. При тестировании же конкретного хоста (например, сайта на Drupal) это приводит к тому, что подавляющее большинство запросов оказывается заведомо нерелевантными, создавая избыточную нагрузку и повышая шанс пропустить реально существующие уязвимости. Таким образом, мы сталкиваемся с двумя задачами оптимизации:

1. Расширение охвата: найти больше скрытых ресурсов, чем позволяет стандартный словарь, особенно если ресурсы кастомизированы.
2. Сокращение запросов: уменьшить количество HTTP-запросов к серверу, убрав из словаря заведомо неподходящие пути, что ускоряет анализ и снижает нагрузку на сервер.

В качестве тестового стенда для демонстрации методов использовался контейнер с веб-приложением на базе Drupal / PHP / Apache.

Как расширить охват и найти больше скрытых ресурсов

Отправная точка: Классический фаззинг
Используя стандартный общедоступный словарь объемом 9057 записей и запустив ffuf, на тестовом стенде было обнаружено 16 существующих эндпоинтов. Это наш базовый уровень, который мы будем стараться улучшить.

Динамический словарь на основе краулинга и LLM
Первый шаг к оптимизации — создание динамического словаря, зависящего от контекста конкретного хоста. Отличный пример такого подхода — утилита Brainstorm (от Invicti Security). Ее логика работы заключается в следующем:

1. Краулинг: сначала инструмент собирает все доступные ссылки с главной страницы сайта (по умолчанию – 25 ссылок).
2. Генерация гипотез: Собранные URL передаются большой языковой модели (LLM) с задачей: «На основе этих путей предложи еще 50 возможных эндпоинтов».
3. Верификация: Сгенерированные пути отправляются в ffuf для фаззинга.
4. Итерация: Найденные рабочие эндпоинты снова передаются в LLM для генерации новых гипотез. Этот цикл повторяется несколько десятков раз (например – 20).

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

Запустив похожую утилиту, но выполняющую на этапе подготовки рекурсивный поиск ссылок по всей глубине хоста, этот метод позволил обнаружить 21 эндпоинт. Количество запросов к хосту составило всего 1000 запросов (50 URL в каждой из 20 итераций), но это уже целевой, «умный» фаззинг. Помимо этого, было совершено 20 запросов к LLM.

Следует отметить, что 1000 запросов – это верхняя оценка, так как LLM зачастую предлагает повторяющиеся URL, и один раз пометив URL как несуществующий, можно не совершать повторные его вызовы, сократив тем самым нагрузку на хост и уменьшив время работы.

Учет технологического стека
Метод Brainstorm можно улучшить, если дать LLM больше информации о цели. Эту информацию легко извлечь, например, из заголовков ответа хоста:

Уже на этом этапе можно сказать, что на хосте используется Drupal, Apache и PHP, а следовательно, обнаружить на нем пути характерные для ASP.NET или оборудования Cisco маловероятно.

Но если начинать анализировать используемые технологии, то лучше использовать специализированные утилиты:

• httpx от Project Discovery, который под капотом имеет модифицированный Wappalyzer и позволяет детектировать множество технологий, исходя из тела и заголовков ответа главной страницы;
• nuclei от Project Discovery, который, будучи запущен с тегом tech, использует шаблоны для детекта технологий из специализированных URL.

Кроме того, можно в LLM передать заголовки и тело ответа хоста, чтобы была возможность задетектировать технологии, которые оказались незамеченными двумя предыдущими утилитами. Итоговая схема выглядит следующим образом:

Как можно увидеть, технологии были определены примерно одинаковые, но LLM дополнительно из тела ответа смог вытащить название используемой темы – Olivero Theme – что потенциально может расширить пространство потенциальных эндпоинтов.

Помимо указанных httpx и nuclei, можно использовать любые другие утилиты для детектирования используемых технологий, в том числе Aquatone и EyeWitness, которые с помощью headless браузера обращаются к хосту, делают скриншот главной страницы и передают его LLM с целью визуального опознания технологий.

Далее можно использовать схему Brainstorm, но отправить в качестве входных данных не результаты краулинга, а результаты техдетекта.

Тестирование такой схемы на стенде покажет не совсем обнадеживающие результаты - при таком же количестве запросов к хосту и LLM, данный метод позволил обнаружить всего 18 эндпоинтов:

Однако остается возможность совместить эти два метода, направив на вход LLM всё что есть – обнаруженные технологии и результаты краулинга:

При таком подходе количество обнаруженных эндпоинтов значительно возрастает, при том что количество отправленных запросов остается тем же – не более 1000 к хосту и 20 к LLM:

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

Как сократить количество запросов без потери качества

Что делать, если мы не можем позволить себе десятки тысяч запросов на один хост? Нужно сделать статический словарь «умнее».

Контекстное усечение словаря (Crop Dict)

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

Но здесь возникает проблема – даже в самом простом словаре из 9000 записей содержится порядка 157 тысяч символов, что превышает лимит контекста большинства LLM. Решением данной проблемы может быть разбиение словаря на чанки по 100-200 записей. Каждый чанк поочередно отправляется в LLM для фильтрации. После обработки всех чанков получается усеченный словарь.

Опытным путем было выявлено, что оптимальный размер чанка составляет 100-200 записей. Если чанк будет слишком большим, есть опасность не влезть в размер окна контекста или получить галлюцинации LLM. При слишком маленьком размере чанка значительно увеличивается количество запросов к LLM, что приводит к удорожанию процесса, особенно на больших проектах.

Использовав 100 чанков и сравнив словари, можем заметить, что усеченный словарь значительно “похудел” – почти в три раза:

Использовав усеченный словарь вместе с ffuf, добьемся уменьшения количества запросов в три раза ценой потери всего одного эндпоинта по сравнению с статичным словарем.

Но в таблице можно также увидеть и главную проблему данного подхода – для контекстного усечения словаря потребовалось 100 обращений к LLM, что приводит к плохой масштабируемости процесса на большом скоупе.

Предварительно размеченный словарь (Pre-marked Dict)

Чтобы избежать многократной дорогостоящей фильтрации словаря для каждого хоста, можно заранее подготовить такой словарь и переиспользовать при необходимости.

Идея проста: взяв список всех возможных детектируемых технологий (например, из шаблона nuclei tech-detect) и сопоставив с стандартным словарем, можно каждой технологии в соответствие поставить перечень эндпоинтов, которые наиболее характерны для нее. Например:

Так как процедура довольно трудоемкая, целесообразнее будет выполнить ее с помощью LLM, по аналогии с предыдущим методом:

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

Реализовав весь процесс и запустив ffuf с полученным списком эндпоинтов, были получены следующие результаты:

Отправив всего 1302 запроса к хосту, смогли обнаружить 12 эндпоинтов. При этом было выполнено всего 100 обращений к LLM, после чего словарь можно переиспользовать сколько угодно раз.

Используя “best practice” и совмещая с динамическим словарем описанные методы сокращения словаря (усеченный словарь и предварительно размеченный), можно добиться гораздо лучших результатов:

• Комбинация Усеченный словарь + Динамический словарь: 40 эндпоинтов, ~4270 запросов, 120 запросов к LLM на каждый хост.
• Комбинация Предварительно размеченный словарь + Динамический словарь: 39 эндпоинтов, ~2000 запросов, всего 20 запросов к LLM для этого хоста (плюс 100 однократных запросов на разметку).

Выводы

Таким образом, можно сделать следующие выводы:

• Для точечного, глубокого анализа одного критически важного хоста, если важен каждый скрытый эндпоинт или нет ограничений на количество отправляемых запросов, лучше использовать большой статический словарь в сочетании с динамическим словарем (Crawling + Techdetect + LLM).
• Если количество запросов всё же важно, то следует отталкиваться от того, какую погрешность мы готовы принять и сколько хостов у нас в скоупе. При одном хосте разумнее использовать усеченный словарь, при большом скоупе – предварительно размеченный, в любом случае дополнив их динамическим словарем.

Заключение и перспективы

Представленные методы показывают, как интеграция больших языковых моделей в традиционные инструменты пентеста позволяет перейти от «грубой силы» к интеллектуальному, контекстно-зависимому анализу. Логика, опробованная на фаззинге директорий, легко переносится и на другие области:

• Фаззинг параметров: Оптимизация работы таких инструментов, как x8, Arjun или ParamMiner, путем предсказания наиболее вероятных имен параметров на основе техдетекта.
• Фаззинг поддоменов: Генерация гипотетических поддоменов, релевантных для конкретной организации, на основе данных, найденных в открытых источниках.

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

Привет, сисадмины и блу-тимы! 👋

В сегодняшнем списке собрали самые громкие CVE месяца — расскажем, кто реально опасен, а кто просто лает, но не кусает. Не паникуем, патчим и держим руку на логах.

🔥 HOT-HOT! TOП-5 уязвимостей по охвату в Рунете

🐙 GitLab / Вебхук-шпиён (CVE-2025-6454)

CVSS: 8.8 | KEV: нет | Real World Danger: 2.0

Масштаб: На радарах СКИПА фиксируется ~30.000 активных инстансов GitLab в Рунете. Из них ~37% потенциально уязвимы.

Суть: Уязвимость позволяет аутентифицированному пользователю инициировать внутренние запросы через прокси и внедрять SSRF в заголовки-вебхуков.

Что по факту: Старые инстансы под риском CI/CD атак. Патч вышел в релизе 18.3.2. — обновись прямо сейчас!

Вердикт: Массовая поверхность атаки — апдейт обязателен. Смотрим в оба за вебхуками в средах разработки и CI.

💥 UMI CMS / XSS-ловушка для админов (BDU:2025-08683)

CVSS: 9.1 | KEV: нет

Масштаб: По данным СКИПА в Рунете работает ~20.000 активных инстансов UMI CMS. ~2.000 из них уязвимы.

Описание: Некорректная валидация веб-страниц позволяет внедрять XSS через специально подготовленный файл, захватывать админ-сессии и выполнять вредоносный JS в контексте панели управления.

Что по факту: Большая база инсталляций + солидный пул уязвимых экземпляров = привлекательный вектор для целевых атак, мошенничества с аккаунтами и дальнейшей компрометации сайтов. Несмотря на небольшое количество упоминаний, баг простой и работающий.

Вердикт: Высокий приоритет для аудита UMI-инстансов, патчинга и внедрения правил очистки/контроля контента.

🕵️ PARTS SOFT CMS / Тук-тук! Кто в системе живет? (BDU:2025-05287 / BDU:2025-05286)

BDU:2025-05286 — CVSS: 6.1 | KEV: нет
BDU:2025-05287 — CVSS: 7.5 | KEV: нет

Масштаб: На радарах СКИПА наблюдаем ~5.000 инстансов PARTS SOFT CMS. Пока патча нет — потенциально все уязвимы.

Описание: Различия в ответах сервера позволяют злоумышленнику осуществлять перебор (enumeration) пользователей. Это раскрывает конфиденциальную информацию и упрощает атаки password-spraying и фишинг. Перебор ID может использоваться для целенаправленной CSRF-эксплуатации.

Что по факту: Широкое наличие в открытой сети и отсутствие исправления — классика для автоматизированных массовых атак, особенно в связке с фишинг-кампаниями.

Вердикт: Мониторим, ставим ограничение запросов, ставим WAF/ratelimit — пока патча нет, компенсируем.

📹 TrueConf Server / Онлайн-конференция для эксплойтов (BDU:2025-10114 / BDU:2025-10115 / BDU:2025-10116)

BDU:2025-10114 — CVSS: 7.5 | KEV: нет
BDU:2025-10115 — CVSS: 7.5 | KEV: нет
BDU:2025-10116 — CVSS: 9.8 | KEV: нет

Масштаб: TrueConf — одна из самых популярных платформ ВКС в РФ. По данным СКИПА, в Интернете доступно несколько тысяч установок, более 80% из них потенциально уязвимы (один хост может быть затронут всеми тремя уязвимостями). На данный момент не наблюдается доступных публичных эксплойтов.

Описание: В августе найдены три уязвимости в TrueConf Server; все подтверждены вендором и исправлены.

Что по факту: Платформа широко распространена, процент уязвимых инстанций высокий — если не применили апдейты, можно получить массовые проблемы с конфиденциальностью и доступностью.

Вердикт: Критический приоритет для операторов ВКС — массовый патчинг и проверка инсталляций обязательны.

🌐Cisco IOS/IOS XE / Открытый SNMP ≠ «всё ок» (CVE-2025-20352)

CVSS: 7.7 | KEV: нет | Real World Danger: 4.0

Масштаб: СКИПА фиксирует >30 000 устройств с SNMP v1/v2c в Рунете. Из них ≈1 700 выглядят потенциально уязвимыми к CVE-2025-20352.

Описание: Переполнение стека в подсистеме SNMP Cisco IOS/IOS XE. Для эксплуатации требуются валидные SNMP-учётки. При низких правах возможен DoS (перезагрузка). На IOS XE при повышенных правах возможен RCE через специально сформированные SNMP-пакеты. Уязвимость имеет признаки 0-day — используется злоумышленниками.

Что по факту: Если у вас открыт SNMP и/или скомпрометированы SNMP-учётные записи —риск растет. Операторам сети срочно проверить SNMP-доступность, применить фильтрацию и обновления, а также отозвать/сменить credentials.

Вердикт: Критично для сетевой инфраструктуры — приоритет для немедленной проверки и мер по снижению риска (фильтрация, обновление, смена учётных данных).

💀 АНТИТОП-5

🎁 FreePBX / Купи модуль, взломы в подарок (CVE-2025-57819)

CVSS: 10 | KEV: да | Real World Danger: 2.0 | Упоминания СКИПА: 25+

Описание: Уязвимость в FreePBX (терминалы 15/16/17) позволяет обходить защиту пользовательских данных и получить неавторизованный доступ к админке, что теоретически даёт возможность манипуляций с базой данных и удалённого выполнения кода. Вендор выпустил фиксы.

Что по факту: Для эксплуатации нужен платный модуль EndPoint Manager. Публичные PoC/шаблоны нестабильны и экзотичны (техники типа time-based / union-based).

Вердикт: Cерьёзная уязвимость по описанию и с KEV в истории, но риск для Рунета локален и специфичен.

📊 Telerik Report Server / Читать отчеты без смс и регистрации (CVE-2024-4358)

CVSS: 9.8 | KEV: да | Real World Danger Score: 5.0 | Упоминания СКИПА: 10+

Описание: В старых сборках Telerik Report Server на IIS возможен обход аутентификации, что даёт неавторизованному атакующему доступ к ограничённой функциональности и потенциальной эскалации.

Что по факту: Уязвимость серьёзная, KEV есть, но продукт в Рунете встречается редко — видимых хостов мало.

Вердикт: Опасна по сути, но для РФ-сегмента не популярна. Патчите, если есть.

🔧 BIG-IP Next Central Manager / Слишком откровенный API (CVE-2024-26026)

CVSS: 9.8 | KEV: не подтверждено | Real World Danger Score: 2.0 | Упоминания СКИПА: 5+

Описание: SQL-инъекция в API BIG-IP Next Central Manager может позволить атакующему выполнить произвольные запросы к базе данных.

Что по факту: Интерфейсы видны преимущественно в локалках; публичных экземпляров в интернете почти не найдено; демонстрационной среды/экземпляра в интернет-пространстве эксперты не обнаружили.

Вердикт: Теоретически критично, но в Рунете ПО практически не представлено — риск крайне низкий.

🧩 SAP NetWeaver на IBM i-series / Проверка подлинности (CVE-2025-42958)

CVSS: 9.1 | KEV: не подтверждено | Real World Danger Score: 2.0 | Упоминания СКИПА: < 5

Описание: Недостаточная проверка подлинности в приложении на IBM i-series даёт возможность неавторизованным пользователям с высокими привилегиями работать с конфиденциальными данными и административными функциями.

Что по факту: Критичный профиль, но продукт крайне редок в Рунете. Уход вендора с рынка РФ может осложнить апдейты, но публичных уязвимых хостов не видно.

Вердикт: Серьёзная уязвимость для тех, у кого есть такой актив, но массовой угрозы в Рунете нет.

🛡️ GitHub Enterprise Server / Админ играет в root-рулетку (CVE-2024-2469)

CVSS: 7.2 | KEV: не подтверждено | Real World Danger Score: 2.0 | Упоминания СКИПА: < 5

Описание: Уязвимость позволяла злоумышленнику с ролью администратора выполнить код и получить root-доступ через SSH. Исправлено в рядах релизов.

Что по факту: GitHub Enterprise в РФ-сегменте встречается редко; публичных инстансов с подтверждённой уязвимостью не обнаружено.

Вердикт: Технически серьёзно, но для отечественной инфраструктуры — практически неактуальна.

💡 Выводы

Среди этих CVE есть как действительно подтверждённые и опасные (KEV), так и те, которые на бумаге выглядят страшно, но в Рунете встретить их почти нереально. Правила просты:

• Знайте свой сетевой периметр! Патчите то, что реально активно у вас в сети.
• KEV = рэд флэг. Если там есть эксплойты, то действуйте.
• Даже редкие уязвимости требуют внимания

Заглядывайте к нам в телеграм — там много материалов по информационной безопасности и мониторингу внешних атаĸ. И обновись сейчас! ⚡