Laravel: обход авторизации API в TokenGuard, обновите фреймворк

19 октября 2026 года команда Laravel выпустила исправление критической уязвимости CVE-2026-114509 в встроенной авторизации API через TokenGuard. При работе с MySQL или MariaDB специально составленное значение учётных данных обрабатывается неверно, и запрос может совпасть с чужим пользователем. В итоге атакующий без токена входит под существующим пользователем на любом маршруте, защищённом этим механизмом. Оценка — 9,2 по CVSS 4.0. Исправлено в версиях 13.29.0 и 12.68.0.

Уязвимость нашёл внешний исследователь через программу поиска ошибок, подтверждённых атак на момент раскрытия не сообщалось.

Что произошло

Laravel — один из самых популярных PHP-фреймворков для сайтов, API и личных кабинетов. В нём есть встроенный способ авторизации запросов по токену — TokenGuard. Уязвимость в том, как он ищет пользователя в базе: при определённом виде значения, которое присылает клиент, запрос к MySQL или MariaDB может вернуть не того пользователя.

Для атаки не нужны ни токен, ни права, ни действия пользователя. Условие — стандартный защищённый токеном маршрут API и база MySQL или MariaDB, самое частое сочетание в проектах на Laravel.

Важно понимать разницу: уязвимость не позволяет войти под любым пользователем по выбору, но даёт войти под неким существующим пользователем без его токена. Для API, где у пользователей есть доступ к своим данным, этого достаточно, чтобы увидеть чужую информацию или выполнить действия от чужого имени.

Кого касается

Всех, у кого на Laravel работает API или личный кабинет с авторизацией по токену и база MySQL либо MariaDB. Это типичная связка: мобильное приложение ходит в API, личный кабинет на фронтенде обращается к бэкенду, партнёрские интеграции работают по токенам.

PostgreSQL в описании не упомянут как уязвимый, но это не повод откладывать обновление: фреймворк обновляют целиком.

Отдельно отметим личные кабинеты. Если на Laravel сделан кабинет клиента (заказы, документы, баланс), и он обращается к бэкенду по токену, уязвимость напрямую затрагивает доступ к персональным данным. Это повод не только обновиться, но и проверить, что доступ к чужим данным невозможен и после обновления.

Что делать

1. Узнайте версию Laravel: команда `php artisan --version` в каталоге проекта или строка в `composer.lock`.
2. Обновите `laravel/framework` до 13.29.0 или 12.68.0 и новее через `composer update laravel/framework`.
3. Прогоните тесты и проверьте вход и защищённые маршруты API.
4. Выкатите обновление на боевой сервер. Обновлённый composer.lock без деплоя ничего не меняет.
5. Просмотрите журналы API на необычные входы: обращения к защищённым маршрутам без корректного токена, доступ к чужим данным.
6. При подозрении на использование уязвимости отзовите и перевыпустите токены доступа пользователей.

Наше мнение

Авторизация — самый чувствительный код в приложении. Ошибка в нём не ломает сайт заметно: он продолжает работать, а дыра видна только тому, кто её ищет. Поэтому уязвимости вроде этой особенно коварны: без обновления о ней можно не узнать, пока не случится инцидент.

Мы советуем командам, которые ведут проекты на Laravel, держать фреймворк в актуальной версии и подписаться на бюллетени безопасности Laravel. Для заказчика это повод спросить у подрядчика, какая версия фреймворка сейчас в проекте и как быстро ставятся критические обновления. Отдельно стоит проверить, что токены доступа можно быстро отозвать и перевыпустить: это нужно не только при этой уязвимости, но и при любой утечке.

Как снизить риск на будущее

Эта история — аргумент за несколько практик, которые полезны независимо от конкретной уязвимости.

• Разделяйте права: токен приложения не должен иметь доступ к данным всех пользователей сразу.
• Логируйте доступ к чувствительным данным, чтобы аномалию можно было заметить.
• Держите в проекте автоматическую проверку зависимостей, которая откроет запрос на обновление в день выхода исправления.
• Пишите тесты на авторизацию: они ловят часть таких ошибок до релиза.
• Разделяйте окружения: ключи и токены боевого сервера не должны совпадать с тестовыми.

Почему уязвимости в авторизации опаснее обычных

Обычная ошибка в коде либо ломает функцию, либо нет — её видно. Ошибка в авторизации ведёт себя иначе: приложение работает нормально для обычного пользователя, и проблема проявляется только когда её целенаправленно ищут. Поэтому такие уязвимости живут в проектах годами и всплывают при аудите или, хуже, при инциденте.

Для бизнеса вывод практический: безопасность входа нельзя проверить «на глаз». Нужны тесты, которые проверяют, что под одним пользователем нельзя получить данные другого, и регулярное обновление фреймворка, где подобные ошибки находят и закрывают разработчики.