Уязвимость Zyxel GS1900 позволила атакующим скомпрометировать 996 управляемых коммутаторов в 48 странах и похитить их конфигурации с учётными данными. Производитель уже выпустил исправление, но история неприятна тем, что вредоносный код работал и на устройствах с предыдущим июньским патчем. Для российских компаний это ещё один повод проверить, не превратился ли веб-интерфейс сетевого оборудования в самый короткий путь внутрь инфраструктуры.
Речь идёт о CVE-2026-107441 — ошибке записи за границы выделенной памяти в веб-интерфейсе управления коммутаторами серии GS1900. Злоумышленнику не требовалась аутентификация: достаточно было иметь сетевой доступ к устройству и отправить специально сформированный HTTP-запрос. После этого он мог выполнять команды операционной системы коммутатора. О проблеме сообщает BleepingComputer.
Под угрозой оказались десять моделей GS1900. Наблюдения GreyNoise показывают, что примерно с 17 августа их эксплуатировала группировка Kapibala, которую исследователи считают китайскоязычной. После удалённого выполнения команд атакующие загружали скрипт для сбора конфигурации устройства, хешей пароля root и сведений о сети. Для сетевой команды это не локальный инцидент на одном железном ящике: такие данные могут помочь атакующему быстро разобраться в сегментации, соседних системах и дальнейших целях.
Изначально кампанию связали с CVE-2026-7273 — другой pre-auth уязвимостью переполнения буфера в тех же коммутаторах. Zyxel выпустила обновления для неё 16 июня, а 21 сентября CISA добавило проблему в каталог Known Exploited Vulnerabilities. Казалось бы, обычный сценарий: ставим июньскую прошивку и закрываем вопрос. Но позднее выяснилось, что эксплойт бил по другой, на тот момент неизвестной ошибке.
Патч был установлен, но атака всё равно проходила
Исследователи Binarly нашли в инфраструктуре, связанной с кампанией Red Heron, открытый архив с обфусцированным Python-эксплойтом для GS1900. Red Heron ранее связывали с бэкдором JITTERLY, руткитом SIXZUT и атаками на критическую уязвимость в self-hosted-сервисе Git. Анализ показал важную деталь: эксплойт проверял, что на цели уже установлена версия прошивки с исправлением CVE-2026-7273. Это не случайная атака на забытые устройства, а работа с учётом реакции вендора.
28 сентября Binarly подтвердили, что техника остаётся рабочей на всех десяти версиях прошивки, выпущенных для устранения июньской уязвимости. Предыдущее обновление добавило проверки против переполнения буфера, однако атакующий мог повредить счётчик параметров до его проверки. В результате механизм защиты обходился, память перезаписывалась, а команды выполнялись без учётной записи. Дополнительно эксплойт использовал отсутствие должной проверки длины HTTP-параметров.
29 сентября Binarly передала результаты Zyxel. Компания подтвердила новую проблему 11 октября, выделила ей отдельный идентификатор CVE-2026-107441 и 22 октября выложила новые версии прошивок. Они ограничивают размер параметров и проверяют их количество до копирования данных в память. Консультативное сообщение Zyxel опубликовала 3 ноября. Остаётся неясным, был ли эксплойт специально написан для обхода июньского исправления или злоумышленники нашли близкую по механике ошибку, которую тот патч не затронул.
Практический вывод для администраторов довольно приземлённый: нужно установить именно актуальную прошивку, а не считать июньское обновление достаточным. Заодно стоит проверить, какие интерфейсы управления коммутаторами доступны из пользовательских сегментов, через VPN или тем более из интернета; просмотреть журналы на необычные HTTP-запросы и возможные обращения к конфигурационным файлам. Смена административных паролей после подозрений на компрометацию выглядит разумнее, чем надежда на то, что хеш root-пароля никому не пригодится.
Случай с GS1900 показывает неприятный класс риска: сетевое устройство может быть полностью обновлено по прежнему бюллетеню и всё равно оставаться удобной точкой входа. Уязвимость Zyxel GS1900 уже использовалась в реальных атаках, поэтому обновление здесь не плановая гигиена, а работа с потенциально скомпрометированным периметром. Главный вопрос теперь не в том, сколько компаний успеют поставить новую прошивку, а в том, сколько из них уже должны искать следы доступа в своих сетях.
