Новая уязвимость в API-шлюзах. Что случилось и как реагировать

12 июля 2026 года специалисты Cloudflare сообщили об обнаружении критической уязвимости в API-шлюзе Kong 3.8, позволяющей обходить JWT-аутентификацию. Это напрямую затрагивает безопасность API и ставит под удар сотни сервисов.

Уязвимость, получившая индекс CVE-2026-31889, позволяет злоумышленнику добавить в заголовок запроса специально сформированный параметр, который шлюз интерпретирует как валидный токен. Проблема возникла из-за некорректной обработки кастомных плагинов для аутентификации. Патч вышел уже 14 июля, версия 3.9. Рекомендую апдейтить сразу, если вы используете Kong

Почему это важно? Потому что разработка API без строгого контроля за компонентами безопасности, как строить дом без фундамента. Многие компании, даже крупные, до сих пор используют кастомные middleware без полноценного тестирования. У мення на одном проекте в 2025-м как раз был случай с токенами, чуть не слили базу клиентов. Проверяйте все точки входа.

• Уязвимость затрагивает Kong 3.8 и ниже при наличии активных кастомных аутентификационных плагинов
• Эксплуатация возможна без повышения привилегий, достаточно HTTP-запроса
• Патч доступен в версии 3.9, обновление критическое
• Ориентировочное время восстановления для средних инфраструктур, 2–4 часа
• Рекомендуется пересмотреть логи за последние 72 часа на предмет подозрительных GET-запросов

Что делать уже сегодня? Если вы отвечаете за внедрение API или модернизацию систем через API, выполните три шага:

Первый, проверьте версию шлюза. Введите kong version в консоли. Если ниже 3.9, апдейт срочно. Второй, временно ограничьте внешний доступ ко всем API через WAF-правила. Третий, запустите аудит логов через SIEM (у меня был Splunk в работе, помог найти даже скрытые попытки).

Ситуация, лишний повод пересмотреть best practices API. Да, технологии API развиваются, но безопасность не должна отставать. Особенно при разработке микросервисов, где каждый endpoint, потенциальная брешь. Пишите документацию с нуля по каждой интеграции. Да, это долго. Но потом не будет нервно-паралитического состояния при каждом инциденте…

А еще, читайте логи, а не только доверяйте автоматике. В моем случае спас именно ручной осмотр. Алгоритмы не видели аномалии, а человек, сразу.

Как действовать при оптимизации API? Не гонитесь за скоростью в ущерб проверкам. тестирование, документация API, регулярные аудиты, это не бюрократия, а ваш щит…

Частые вопросы:

Можно ли доверять другим шлюзам? Да, но с оговорками. Envoy и Traefik пока чистые, но у них сложная документация API, легко ошибиться при настройке

Нужно ли менять архитектуру? Не обязательно. Главное, изоляция сервисов и принцип минимальных привилегий.

Все ли кейсы использования API стали менее безопасными? Нет. например, внутренние вызовы в защищенной сети пока вне зоны риска, если нет фронтальных шлюзов…