F5 раскрыла уязвимость в модуле BIG-IP Access Policy Manager, которая позволяет выполнять код на устройстве без аутентификации, и подтвердила, что её уже используют в реальных атаках. Пометка об эксплуатации появилась 23 сентября, через сутки после публикации бюллетеня. Речь идёт о шлюзах доступа, через которые организации публикуют внутренние приложения в интернет, поэтому первыми в зоне риска оказались системы, открытые во внешнюю сеть. Уязвимость получила идентификатор CVE-2026-94127 и отнесена к классу переполнения буфера в динамически выделяемой памяти. По шкале CVSS v3.1 ей присвоили 9.8 балла, по CVSS v4.0 - 9.3.
Уязвимость CVE-2026-94127
Ошибка кроется в компоненте APM OAuth. Проявляется она при определённом наборе настроек: на одном виртуальном сервере одновременно заданы политика доступа и профиль OAuth, а сам APM выступает сервером авторизации. В таком режиме он выдаёт приложениям токены доступа к защищённым ресурсам. Подготовленный особым образом трафик переполняет буфер, и на устройстве выполняется чужой код. Аутентификация для этого не нужна, поэтому фильтрация по учётным записям здесь не помогает.
Уязвимы ветки BIG-IP APM 21.x, 17.5.x и 17.1.x. Вендор отдельно уточняет: если APM работает только как клиент OAuth или сервер ресурсов, проблема не возникает. То есть важен не сам факт использования OAuth, а роль, которую модуль играет в конкретной конфигурации. Проверить это можно по настройкам виртуальных серверов: уязвимы те, где профиль сервера авторизации включён.
F5 описывает проблему как уязвимость плоскости обработки трафика, или data plane. Плоскость управления, где хранятся административные настройки и конфигурация устройства, она не затрагивает. Однако апплаенс-режим BIG-IP защитой не служит: система остаётся уязвимой, если её настройки совпадают с описанными. Это заметно сужает круг потенциальных жертв, но не отменяет риска для тех, кто попал в него.
Не затронуты другие продукты вендора: BIG-IP Next, BIG-IQ Centralized Management, F5OS, сервисы Distributed Cloud, линейка NGINX и F5 AI Gateway. Атакующие целились именно в APM, а не в инфраструктуру F5 целиком.
Почему эксплуатация началась так быстро, объясняется ролью APM в инфраструктуре. Модуль стоит на входе в корпоративную сеть, через него проходят сессии сотрудников, проверки подлинности и правила доступа к приложениям. Устройство смотрит в интернет, обрабатывает чужой трафик и работает с широкими правами. Уязвимость, для которой не нужна учётная запись, даёт возможность выполнить код прямо на таком шлюзе. Дальше злоумышленник получает плацдарм для перемещения по внутренней сети.
F5 перечислила признаки, по которым администраторы могут найти следы эксплуатации. Единичная ошибка OAuth в журналах - обычное дело, значение имеет повторяемость. Десяток и больше однотипных событий в одном журнале, особенно с одного IP-адреса, вендор считает признаком средней достоверности, требующим проверки. Речь идёт о сообщениях об ошибке invalid_token при неудачном запросе UserInfo в журнале APM. Статистику отказов OAuth можно посмотреть командой:
| 1 | tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed |
Необъяснимый рост числа неудачных запросов, за которым следуют подозрительные записи в журнале аудита, - повод немедленно начинать разбор. Третий признак - аварийное завершение процесса TMM с сигналом SIGABRT. Само по себе наличие файла аварийного дампа ни о чём не говорит, но сочетание всех трёх событий, произошедших подряд, F5 считает достаточным основанием для ручной проверки системы.
Инженерные хотфиксы вышли для всех трёх уязвимых веток. Скачать их можно с сайта F5, и они же включены в защищённые сборки BIG-IP. Если установить исправление быстро не получается, вендор предлагает закрыть проблему правилом iRule на уязвимом виртуальном сервере. Правило выдают только по запросу в службу поддержки, готового файла в открытом доступе нет. Затягивать с обращением в такой ситуации рискованно.
Администраторам нужно сначала составить список виртуальных серверов, где APM работает сервером авторизации OAuth. Таких конфигураций обычно немного, и именно они определяют объём работ. Дальше - установка хотфикса, а до неё проверка журналов аутентификации, аудита и файлов аварийного завершения TMM на признаки эксплуатации. Системы, доступные из интернета, в этой очереди идут первыми.
Шлюзы доступа и системы единого входа давно входят в число приоритетных целей атакующих. Они стоят на границе сети, видны сканерам и часто обладают правами, которых нет у обычных приложений. Уязвимость без аутентификации в таком узле сокращает путь от внешнего сканирования до выполнения кода внутри инфраструктуры. Практический вывод для защитников простой: важно точно знать, какие конфигурации APM работают в режиме сервера авторизации, и держать журналы OAuth под постоянным наблюдением.
Ссылки
