Authlib должна отличать доверенные данные от подделки, но специально сформированный JWS позволяет пройти проверку вообще без криптографической подписи.
Уязвимость CVE-2026-96760 затрагивает Authlib 1.7.2 и более ранние версии. Python-библиотека помогает разработчикам работать с OAuth, OpenID Connect, JWT, JWS и JWE, а также создавать и проверять токены в веб-приложениях и микросервисах.
Проблема скрывается в обработке общей JSON-сериализации JWS функцией JsonWebSignature.deserialize_json(). Обычно JWS содержит полезную нагрузку и одну или несколько подписей, по которым получатель проверяет происхождение и целостность данных. Authlib, однако, принимает объект с пустым массивом "signatures":[].
В таком случае библиотека не проверяет ни одной подписи, но всё равно возвращает содержимое как успешно подтверждённое. Атакующему не нужен закрытый ключ или другой секрет. Достаточно передать произвольную полезную нагрузку и оставить список подписей пустым. В результате приложение может довериться поддельным идентификаторам пользователя, ролям, областям доступа и другим данным. Принцип работы JWT как раз строится на том, что подпись не позволяет незаметно менять защищённое содержимое.
Последствия зависят от того, как конкретный проект применяет Authlib. Сервис может принять поддельную личность, выдать повышенные права, обработать сфальсифицированное сообщение между микросервисами или довериться изменённой конфигурации. Дефект не означает автоматический взлом любого приложения с Authlib. Уязвимый путь должен обрабатывать JWS в JSON-представлении через затронутые функции.
На момент раскрытия проблемы готового исправления для Authlib не было. CERT/CC пытался связаться с разработчиком, но не получил заявления и рекомендовал следить за обновлениями проекта. Ситуация выглядит особенно примечательно на фоне отдельного пакета joserfc из той же экосистемы: в версии 1.7.4 разработчики уже добавили отказ от JWS с пустым массивом подписей, тогда как старый модуль authlib.jose постепенно выводят из эксплуатации.
В бюллетене VU#762428 CERT/CC прямо указывает, что злоумышленник способен передать произвольные неподписанные данные без какого-либо ключевого материала. Пока исправленная версия Authlib не доступна, разработчикам приложений имеет смысл отдельно отбрасывать JWS без подписи и проверить, где используется JSON-сериализация JWS.
Похожая ошибка весной обнаружилась в Java-библиотеке pac4j-jwt. Там неподписанный токен тоже мог миновать криптографическую проверку и передать приложению произвольные данные, включая роль администратора.
Проблемы на границе между подписанными и фактически используемыми данными встречаются не только в JWT. В августе сразу несколько реализаций SAML позволяли обходить аутентификацию из-за расхождений в обработке XML и цифровых подписей.