F5 предупреди, че атакуващи активно експлоатират критична zero-day уязвимост в внедряванията на BIG-IP Access Policy Manager (APM) за отдалечено изпълнение на код без автентикация.

Уязвимостта се проследява като CVE-2026-94127 и засяга виртуални сървъри, конфигурирани с политика за достъп на APM и OAuth профил, по-конкретно когато APM действа като OAuth сървър за авторизация. F5 публикува бюлетин за сигурност K000162605 на 22 септември 2026 г., след като научи, че атакуващите вече използват проблема за атаки.

Уязвимостта представлява препълване на буфера в динамичната памет (heap-based buffer overflow), категоризирана като CWE-122 и с вътрешен номер за проследяване 2524777. Специално проектиран мрежов трафик може да повреди паметта и да позволи изпълнението на произволен зловреден код в системата BIG-IP.

Тя има критична оценка CVSS v3.1 от 9.8 и CVSS v4.0 от 9.3, което отразява ниска сложност на атаката, мрежова достъпност, липса на необходимост от привилегии или потребителско взаимодействие и потенциално тежки последствия за поверителността, целостта и наличността.

F5 BIG-IP OAuth Server 0-day Flaw

Важно е да се отбележи, че уязвимостта зависи от конфигурацията, а не от самото наличие на APM. Внедрявания, използващи APM само като OAuth клиент или ресурсни сървъри, без профили за OAuth сървър за авторизация, не са засегнати. Системите в режим appliance-mode остават уязвими.

F5 съобщи, че уязвимостта се намира в слоя за данни (data plane), който обработва трафика на приложенията, и не излага слоя за управление (control plane). В резултат на това ограничаването само на интерфейса за управление няма да блокира експлоатацията, достигаща до засегнат виртуален сървър.

Известните уязвими версии включват BIG-IP APM 21.1.0, версии от 17.5.0 до 17.5.1 и версии от 17.1.0 до 17.1.3. Други модули на BIG-IP, BIG-IQ Centralized Management, BIG-IP Next, F5 Distributed Cloud services, продуктите NGINX, F5OS вариантите и F5 AI Gateway са оценени като незасегнати.

F5 предупреждава, че версиите извън края на техническата поддръжка (End of Technical Support) не се оценяват, така че администраторите не трябва да тълкуват липсата им в списъка със засегнати версии като доказателство за безопасност.

Инженерни извънредни корекции за сигурност са налични като Hotfix-BIGIP-21.1.0.2.0.30.22-ENG.iso, Hotfix-BIGIP-17.5.1.9.0.160.12-ENG.iso и Hotfix-BIGIP-17.1.3.5.0.41.14-ENG.iso за съответните клонове.

Организациите трябва да инвентаризират виртуалните сървъри BIG-IP APM, да идентифицират уязвимата комбинация от политика за достъп и OAuth профил и незабавно да инсталират съответната корекция за сигурност. Когато спешното отстраняване на уязвимостта е оперативно невъзможно, клиентите могат да се свържат с поддръжката на F5 за iRule, който временно да смекчи атаките срещу засегнатия виртуален сървър.

Защитниците трябва също да търсят доказателства за опити за експлоатация или успешна такава. F5 съветва да се разследват три събития, случващи се близко едно до друго: повторени неуспехи при OAuth автентикация, съмнително изпълнение на команди и последващо събитие Traffic Management Microkernel (TMM) SIGABRT.

Десет или повече съобщения за невалиден токен в /var/log/apm заслужават преглед, особено когато произхождат от един IP адрес. Анализаторите могат да проверят броя на неуспехите с tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed и да съпоставят времевите печати с записите в /var/log/audit.

Основен файл на TMM (TMM core file) може да се появи, когато TMM влезе в цикъл и SOD демонът издаде SIGABRT, но нито основният файл, нито неуспехът при автентикация самостоятелно доказват компрометиране. Тяхната честота и времева връзка са от значение.

CISA добави CVE-2026-94127 към своя каталог с известни експлоатирани уязвимости (Known Exploited Vulnerabilities) след доказателства за атаки в реална среда, подсилвайки необходимостта от спешни мерки.

F5 откри уязвимостта вътрешно, докато публичните доклади все още не са установили самоличността на атакуващите, мащаба на експлоатацията или потвърдени цели след компрометирането.

Екипите по сигурност трябва да запазят логовете, да прегледат съмнителната активност около наблюдаваните грешки и да дадат приоритет на изложените конфигурации на OAuth сървъри за авторизация при реагиране на инциденти. Тази несигурност прави ретроспективното търсене на заплахи толкова важно, колкото и незабавното отстраняване на уязвимостта.