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

Уязвимость Cisco Unified CM уже используют в атаках

Уязвимость CVE-2026-20230 с оценкой CVSS 8.6 в Cisco Unified CM уже эксплуатируют. Атакующий может записывать файлы и повышать права до root.

✍️ Редакция iTech News | 24.06.2026 | ⏱ 5 мин | Источник: BleepingComputer
🔑

Уязвимость Cisco Unified CM с идентификатором CVE-2026-20230, получившая 8,6 балла по CVSS, перешла из разряда «поставьте патч при первой возможности» в категорию «уже поздно откладывать». Атаку можно провести без аутентификации, а итоговый сценарий неприятный даже по меркам корпоративной телефонии: запись файлов на устройство с последующим повышением привилегий до root. Для российских ИТ-команд это еще один сигнал, что системы унифицированных коммуникаций давно живут не в тени ERP и VPN, а в той же зоне прямого интереса атакующих.

Проблема затрагивает Cisco Unified Communications Manager и Unified Communications Manager Session Management Edition. Cisco выпустила исправления 3 июня 2026 года, а теперь, как пишет BleepingComputer, уязвимость уже используют в реальных атаках. Вендор предупреждал, что ошибка связана с некорректной проверкой входных данных в определенных HTTP-запросах. Это позволяет удаленному неаутентифицированному атакующему провести SSRF-атаку через уязвимое устройство, а затем записать файлы в базовую операционную систему. Дальше начинается классика: если файл удалось положить в нужное место и с нужным содержимым, следующая остановка может называться root.

Первым о наблюдаемой эксплуатации сообщила компания Defused, занимающаяся threat intelligence. По ее данным, атаки шли как минимум с одного IP-адреса, а злоумышленники использовали корректно собранные payload'ы с file://, чтобы создавать файлы на устройстве. Это важная деталь: речь не о «шуме в интернете», где кто-то сканирует все подряд кривыми запросами, а о вполне рабочей технике эксплуатации. На своих honeypot-системах Defused увидела попытки записать текстовый файл с именем /tmp/cve-2026-20230-test.txt. Такой артефакт больше похож на разведку и подтверждение уязвимости, чем на немедленную установку полноценного импланта, но расслабляться тут не с чего: когда проверка уязвимых хостов уже автоматизирована, следующий шаг обычно занимает меньше времени, чем цикл внутреннего согласования окна на обновление.

Почему это не просто SSRF

Само обозначение SSRF здесь может немного усыпить бдительность. Многие команды привыкли думать о server-side request forgery как об ошибке, через которую можно сходить «куда не надо» от имени сервера: во внутреннюю сеть, в метаданные облака, к служебным API. В случае CVE-2026-20230 история жестче. Исследователи из SSD Secure выяснили, что компонент WebDialer обрабатывает пользовательские URL так, что злоумышленник может использовать URI вида file:// и заставить приложение записывать произвольные файлы в операционную систему. То есть цепочка начинается как SSRF, а заканчивается файловой записью на хосте, что уже открывает путь к удаленному выполнению кода и повышению привилегий.

Есть и еще одна деталь, которую полезно понимать администраторам. По данным SSD Secure, для эксплуатации атакующему сначала нужно узнать hostname целевой системы. На бумаге это выглядит как лишний барьер, на практике исследователи показали, что нужную информацию можно получить с самого устройства еще до основной стадии атаки. Иными словами, это не тот случай, где защита держится на «не зная внутреннего имени сервера, злоумышленник ничего не сделает». Если внешне доступен уязвимый интерфейс, hostname в этой схеме скорее техническое условие, чем реальная защита.

Показательно и то, чего пока нет. Defused отдельно отметила, что раньше зафиксированной эксплуатации этой CVE не было, а в каталоге CISA KEV на момент наблюдений она еще не числилась. Для защитников это неудобная ситуация: формально уязвимость может не выглядеть как массово разогнанная кампания, но фактически окно спокойной установки патчей уже закрылось. Как только SSD Secure опубликовала технический разбор и proof-of-concept, порог входа для новых атакующих резко снизился. Сценарий знакомый: сначала advisory, потом первые осторожные пробы, затем публичный PoC, после чего уязвимость перестает быть узкопрофессиональной темой для исследователей.

Что это значит для инфраструктуры связи

Для разработчиков и DevSecOps-команд эта история может казаться периферийной: мол, CUCM живет в мире телефонии, а не в основном контуре разработки. Но для бизнеса именно такие системы часто оказываются «забытым критическим активом». Они интегрированы с корпоративной сетью, обслуживают голосовую связь, иногда имеют доступ из внешних сегментов для удаленных сценариев, а обновляются не так бодро, как браузеры или контейнерные образы. В итоге IP-телефония и UC-платформы становятся удобной точкой входа: не такой шумной, как VPN-шлюз, но достаточно ценной для закрепления в инфраструктуре.

Практический вывод здесь довольно прямой. Если в компании используется Cisco Unified CM или Unified CM SME, откладывать июньские обновления уже нечем оправдать. Нужна проверка внешней доступности WebDialer, ускоренная установка патчей от 3 июня и хотя бы базовая охота за артефактами эксплуатации. В частности, стоит проверить попытки обращения с payload'ами file://, а также появление неожиданных файлов в системе, включая тестовый /tmp/cve-2026-20230-test.txt, который наблюдала Defused. Если устройство уже скомпрометировано, разговор быстро выйдет за рамки «поставить апдейт»: после файловой записи и возможного повышения прав придется разбирать, что еще успел сделать атакующий и не использовался ли сервер как промежуточная точка для движения по сети.

На уровне отрасли история тоже выглядит симптоматично. За последние месяцы новости про активно эксплуатируемые уязвимости все чаще касаются не только браузеров, VPN и веб-приложений, но и специализированных корпоративных платформ, которые долго считались нишевыми и потому якобы менее интересными. Этот аргумент больше не работает. Если продукт стоит на краю корпоративной сети, обрабатывает HTTP-запросы и имеет сложную обвязку, он рано или поздно становится целью. Подробности по наблюдаемой эксплуатации и техническому разбору собраны в материале BleepingComputer; главный вопрос теперь не в том, появятся ли новые попытки взлома, а в том, сколько компаний все еще считают свою телефонию «непубличной системой» и потому не спешат проверять ее на компрометацию.

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