В Laravel, одном из самых распространённых PHP-фреймворков, нашлась уязвимость в компоненте TokenGuard, который отвечает за вход в приложение по API-токенам. Специально сформированный запрос проходит проверку подлинности, хотя не должен, и злоумышленник получает доступ к чужой учётной записи. Затронуты ветки 12.x и 13.x до версий 12.68.0 и 13.29.0. Исправления вышли, но рабочий пример эксплуатации уже лежит в открытом доступе.
CVE-2026-114509 в Laravel обход аутентификации через TokenGuard
Уязвимость описали сразу двумя категориями ошибок. Первая - неправильная аутентификация, вторая - недостаточная проверка заданного типа входных данных. По классификации Common Weakness Enumeration (CWE, открытый перечень типов ошибок в коде) это CWE-287 и CWE-1287. Проще говоря, код принимает значение не того типа, которое ожидает, и на этом основании считает пользователя тем, за кого он себя выдаёт.
TokenGuard в Laravel нужен для аутентификации по токену: клиент присылает строку в заголовке запроса, приложение ищет её владельца и открывает сессию. Если проверка типа хромает, обработчик может принять за токен конструкцию, которая валидным токеном не является. Дальше подстановка чужого идентификатора открывает доступ к учётной записи, а вместе с ней - к данным и действиям, доступным её владельцу.
Оценки опасности высокие по всем трём шкалам. CVSS 3.1 даёт 9,8 балла, CVSS 4.0 - 9,2, устаревшая CVSS 2.0 - максимальные 10. Вендор и Банк данных угроз безопасности информации (BDU) относят проблему к критическому уровню. Вектор сетевой: атакующему не нужен физический доступ к серверу, не нужны учётные данные и не требуется участие пользователя. Всё, что требуется, - дотянуться до уязвимого приложения по сети.
Публичный эксплойт меняет расклад
Стандартная оговорка про "теоретическую возможность" здесь не работает. Пример эксплуатации опубликован на GitHub, то есть проверить приложение на уязвимость может любой, у кого есть базовые навыки работы с HTTP-запросами. Порог входа низкий, и это главный фактор риска: между публикацией эксплойта и массовым сканированием адресного пространства обычно проходят считаные дни.
Масштаб последствий зависит от того, что именно закрывает TokenGuard. В типовой конфигурации Laravel это API - мобильные клиенты, интеграции с внешними сервисами, внутренние микросервисы. Через API проходит обмен данными между системами, и подмена пользователя в таком канале означает доступ к информации, которую приложение считает защищённой. Для одностраничных приложений с сессионной аутентификацией риск ниже, но полагаться на это не стоит: конфигурации часто совмещают несколько механизмов входа.
Отдельный повод для беспокойства - обновления. Фреймворк обновляют редко и неохотно, особенно в проектах, которые давно в эксплуатации. Многие команды фиксируют версию зависимостей, чтобы избежать неожиданностей, и пропускают исправления безопасности. Такая практика удобна до первого серьёзного случая.
Что исправлено и что делать
Разработчики закрыли проблему в версиях 12.68.0 и 13.29.0. Обе ветки поддерживаются, поэтому выбор зависит от того, на какой ветке стоит проект. Обновление отмечено как подтверждённое производителем, статус уязвимости - подтверждена.
Переход на исправленную версию - основной и самый надёжный шаг. После обновления нужно пересмотреть выпущенные ранее токены: если злоумышленник успел воспользоваться уязвимостью, старые токены остаются действующими ключами. Отзыв и перевыпуск токенов для API-клиентов закрывает этот риск. Заодно имеет смысл просмотреть журналы обращений к API за последние недели: аномалии вроде запросов с необычными типами значений или обращений к методам, недоступным для конкретной роли, дают повод для более глубокой проверки.
Если обновление по каким-то причинам откладывается, стоит ограничить доступ к уязвимым эндпоинтам на периметре. Помогают списки разрешённых адресов для API, отдельный сегмент сети для сервисов, которым нужен внешний доступ, и включённое журналирование всех запросов к аутентификации. Это не устраняет уязвимость, но снижает вероятность, что ей воспользуются вслепую.
Уязвимости в популярных фреймворках бьют по широкому кругу организаций сразу. Один и тот же код лежит в тысячах проектов, и одно исправление закрывает дыру везде, где его установили. Проблема в том, что устанавливают его не везде и не сразу. CVE-2026-114509 относится к той категории, где промедление измеряется не удобством, а доступом к данным.
Ссылки
- https://bdu.fstec.ru/vul/2026-17775
- https://www.cve.org/CVERecord?id=CVE-2026-114509
- https://github.com/laravel/framework/releases/tag/v12.68.0
- https://github.com/laravel/framework/releases/tag/v13.29.0
- https://github.com/laravel/framework/security/advisories/GHSA-f9x3-7vq9-cph6
- https://github.com/laravel/framework/commit/8dbb08bccac1be095dba4a9d259a419620f1e8a5
- https://github.com/laravel/framework/commit/9b21ce0a9bb2b2599978bc0b0df4abea952ad31c
- https://github.com/ArioVeisa/cve-2026-114509-laravel-tokenguard
