КИБЕРБЕЗОПАСНОСТЬ

N-able выпустила второй хотфикс N-central после атак

N-able представила Hotfix 2 для N-central после выявления атак на серверы. Обновление критично для всех версий до 2026.3.1.7.

✍️ Редакция iTech News | 18.09.2025 | ⏱ 3 мин | Источник: The Hacker News
N-able выпустила Hotfix 2 для N-central — что важно знать

N-able выпустила второй хотфикс для N-central после того, как расследование CVE-2026-18577 показало неприятную деталь: атакующие не ограничивались входом в RMM-консоль, а добирались до управляемых систем и закреплялись в них. Для MSP и внутренних IT-команд это уже не история про ещё один срочный патч, а про проверку всего контура, куда дотягивается сервер администрирования.

Второй хотфикс нужен даже после первого

Первые признаки атаки N-able заметила 31 июля 2026 года, а 2 августа выпустила первый хотфикс 2026.3.1.7. Теперь компания просит перейти и на второй хотфикс: по данным The Hacker News со ссылкой на N-able, это не дубль предыдущего исправления, а отдельный пакет дополнительных защит. Целевая сборка для пользователей N-central — 2026.3.1.10.

Ключевая уязвимость — CVE-2026-18577 с оценкой 8,2 по CVSS. Она связана с неполным исправлением более ранней CVE-2026-18556. Проще говоря, первый цикл закрытия дыры оказался недостаточным, а злоумышленники успели подстроить технику атаки быстрее, чем многие команды успели закрыть окно обслуживания.

Атака шла дальше сервера N-central

В этой истории важен не только сам обход аутентификации. N-able признала, что часть атак дошла до управляемых систем, а злоумышленники сохраняли доступ и после первичного входа. В предыдущих разборах Huntress фигурировали штатная функция Take Control, сервис Cloudflared и подозрительные исполняемые файлы вроде svchost.exe в пользовательских папках. Для RMM это почти худший сценарий: взлом одной панели быстро превращается во вход в клиентские сети.

Компания также обновила индикаторы компрометации и добавила новые IP-адреса для проверки журналов, включая 173.249.252[.]176 и 173.249.252[.]200. Но есть важная оговорка: чистая сверка по индикаторам компрометации не доказывает, что инцидента не было. Поэтому проверять нужно не только IOC, но и историю входов, изменения ролей, активность аккаунтов и сессии удалённого управления.

Практические выводы для администраторов

Минимальный план действий выглядит так: обновить сервер N-central до 2026.3.1.10, пересмотреть журналы N-central и межсетевых экранов, проверить сессии Take Control, поискать следы Cloudflared и неожиданных исполняемых файлов на управляемых узлах. Если консоль была доступна из интернета, разговор уже не только о патче, но и о полноценном реагировании на инцидент.

Для русскоязычного рынка история касается не только MSP. Если подрядчик администрирует ваши рабочие станции, серверы или сеть через RMM, стоит задать два скучных, но полезных вопроса: какая сборка N-central стоит сейчас и был ли сервер доступен извне. После кейсов Kaseya VSA, ConnectWise ScreenConnect и SimpleHelp рынок давно знает, что такие платформы удобны не только администраторам.

Источники: The Hacker News, обновление N-able, разбор Huntress, страница первого хотфикса.

Расследование продолжается, так что список индикаторов и рекомендации по проверке, скорее всего, ещё изменятся.

Поделиться: Telegram X LinkedIn