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