Критическая уязвимость Progress Kemp в LoadMaster, получившая идентификатор CVE-2026-8037 и оценку 9,6 по CVSS, уже перешла из категории «надо срочно патчить» в категорию «по вам, возможно, уже стучатся». Речь о pre-auth RCE: атакующему не нужны учетные данные, чтобы попытаться выполнить произвольный код на балансировщике. Для российских команд это не академическая история про чужую железку, а знакомый сценарий: внешний сетевой узел, высокая привилегированность и минимальное окно на реакцию.
Об активных попытках эксплуатации сообщает The Hacker News со ссылкой на Threat Response Unit компании eSentire. По данным исследователей, атаки против CVE-2026-8037 начались 29 июня 2026 года. Уязвимость затрагивает Progress Kemp LoadMaster и описывается как OS command injection в API: при успешной эксплуатации злоумышленник может добиться удаленного выполнения команд на уязвимом устройстве. Ключевая деталь здесь даже не в высоком балле CVSS, а в том, что входной порог для атаки практически отсутствует: доступ до внешнего интерфейса потенциально важнее любого украденного пароля.
Сама Progress выпустила advisory еще в начале июня и прямо указала, что проблема позволяет неаутентифицированному атакующему с помощью несанитизированного ввода исполнять произвольные команды на appliance. На этой неделе технический разбор опубликовала watchTowr Labs, и после таких публикаций таймер обычно начинает тикать заметно громче. Исследователи привязали баг к функции escape_quotes() в приложении балансировщика: при обработке пользовательского ввода она некорректно завершала очищенную строку нулевым байтом. На практике это приводило к чтению данных за пределами буфера, в соседнюю область heap-памяти. Дальше схема уже знакома по учебнику эксплуатации memory corruption: специально сформированный запрос к эндпоинту /accessv2 позволяет повлиять на состояние heap и довести ситуацию до командной инъекции.
Именно поэтому CVE-2026-8037 выглядит особенно неприятно. Это не «условная» RCE, где для успеха нужны редкие настройки, заранее известный токен или сложная цепочка из нескольких ошибок. Если устройство доступно снаружи и не закрыто обновлением, злоумышленник может пытаться зайти напрямую через API. Для бизнеса это означает стандартный, но оттого не менее болезненный набор последствий: компрометация пограничного узла, закрепление в инфраструктуре, возможный обход сегментации и дальнейшее развитие атаки уже внутри сети. Балансировщики, ADC и подобные устройства любят жить на стыке «критично для продакшена» и «редко попадают в привычный цикл DevSecOps», а это плохое сочетание в любой год.
Есть и сдерживающий фактор: eSentire пишет, что зафиксированные ею попытки эксплуатации закончились неудачей, поэтому посткомпрометационной активности после них не было. Но это слабое утешение. Во-первых, неудачная попытка сегодня не означает неудачную попытку завтра: публичный PoC и подробное техническое описание обычно быстро повышают качество атак. Во-вторых, сама телеметрия уже показывает интерес злоумышленников к уязвимости, а значит, речь идет не о гипотетической угрозе, а о начавшемся цикле массовой проверки внешних сервисов. eSentire отдельно перечислила IP-адреса, откуда шли наблюдавшиеся запросы: 192.42.116.58, 192.42.116.105 и 146.70.139.154. Полагаться только на блокировку этих адресов, разумеется, бессмысленно: IOC полезны как индикатор и повод проверить логи, а не как стратегия защиты.
Для LoadMaster это уже не первый такой эпизод. The Hacker News напоминает, что ранее активность злоумышленников уже сопровождала CVE-2024-1212 с максимальной оценкой 10,0 по CVSS — еще одну критическую OS command injection уязвимость, позволявшую выполнять системные команды. И это важный контекст. Когда один и тот же класс багов повторяется в сетевом продукте, рынок делает вполне прозаичный вывод: внешне доступные компоненты этой категории нужно рассматривать как зону постоянного риска, даже если они годами считались «просто инфраструктурой». Для ИТ-директоров и CISO здесь нет интриги, но есть неприятная экономика: любое устройство на периметре начинает требовать того же уровня дисциплины, что и интернет-facing приложение, хотя организационно к нему часто относятся как к коробке, которую один раз настроили и забыли.
Что это значит на практике для технических команд. Во-первых, патчить нужно в приоритетном порядке, без попыток отложить обновление «до окна на следующей неделе». Во-вторых, стоит проверить, опубликован ли интерфейс управления или связанный API наружу, и если да, сократить поверхность атаки хотя бы временными мерами: ограничением доступа, ACL, VPN, сегментацией, фильтрацией на уровне WAF или upstream-узла, если это возможно без поломки продакшена. В-третьих, полезно пройтись по логам с 29 июня 2026 года и поискать обращения к /accessv2, аномальные запросы и любые попытки выполнить нетипичные системные команды на appliance. Наконец, это хороший повод сверить реестр внешних инфраструктурных сервисов с реальностью: у многих компаний проблема начинается не с эксплойта, а с того, что никто до конца не знает, какие именно управляющие интерфейсы светятся в интернет.
История с CVE-2026-8037 хорошо показывает, как быстро меняется судьба сетевой уязвимости после публикации технического разбора. Пока баг живет в advisory, его можно обсуждать в формате риска. Как только появляется понятный маршрут эксплуатации, он превращается в операционную задачу с дедлайном «вчера». И если 2024-й и 2026-й подряд приносят Progress Kemp критические command injection-бреши, то вопрос уже не только в конкретном патче, а в том, насколько компании готовы считать сетевые appliance полноценной частью своей attack surface, а не чем-то вроде дорогой и потому якобы надежной черной коробки.