В сфере веб-безопасности вновь выявлена критическая уязвимость, затрагивающая популярную библиотеку для обработки токенов. Эксперты предупреждают о проблеме в компоненте pac4j-jwt, которая позволяет удалённым злоумышленникам полностью обходить проверку подлинности пользователей. Данная уязвимость, получившая идентификатор CVE-2026-29000, классифицируется как ошибка неправильной проверки криптографической подписи (CWE-347) и оценивается как критическая по шкале CVSS с максимальным баллом 10.0. Её опасность усугубляется тем, что код для эксплуатации (Proof of Concept) уже опубликован в открытом доступе, что значительно упрощает работу киберпреступников.
Уязвимость CVE-2026-29000
Суть проблемы кроется в модуле JwtAuthenticator библиотеки pac4j-jwt, который используется множеством Java-приложений для проверки JSON Web Tokens (JWT) - стандартного формата токенов для безопасной передачи данных. В уязвимых версиях, а именно во всех релизах начиная с 4.0 до 4.5.9, с 5.0 до 5.7.9 и с 6.0 до 6.3.3, существует изъян в обработке зашифрованных токенов формата JWE (JSON Web Encryption). Злоумышленник, которому удалось получить публичный RSA-ключ сервера (часто не являющийся секретом), может сформировать специальный токен. Этот токен представляет собой незашифрованный PlainJWT, произвольно задав в нём любые утверждения (claims), например, идентификатор пользователя и его роль, который затем оборачивается в шифрованную JWE-оболочку. Ключевая ошибка заключается в том, что система, обнаружив внешнюю JWE-оболочку, расшифровывает её, но затем некорректно пропускает внутренний токен без обязательной проверки его цифровой подписи.
Таким образом, механизм безопасности, полагающийся на криптографическую верификацию, полностью игнорируется. В результате атакующий может создать токен, в котором он объявит себя любым пользователем, включая учётную запись с правами администратора, и успешно пройти аутентификацию в защищённом приложении. Это классический пример обхода контроля доступа, ведущий к полной компрометации системы. Необходимо подчеркнуть, что для успешной атаки не требуется знания секретного ключа для подписи, достаточно лишь публичного, что делает угрозу весьма вероятной.
Последствия эксплуатации данной уязвимости могут быть катастрофическими. Получив административные привилегии в веб-приложении, злоумышленник получает полный контроль над функционалом. В зависимости от типа системы это может привести к массовой утечке конфиденциальных пользовательских данных (PII), финансовой информации или коммерческой тайны. В корпоративных системах атакующий может изменять настройки, удалять или подменять контент, а также использовать скомпрометированный сервер в качестве плацдарма для дальнейших атак во внутреннюю сеть организации. Для интернет-магазинов или банковских сервисов это прямой путь к хищению средств и мошенническим операциям.
Учитывая публичность эксплойта и широкое распространение библиотеки pac4j в экосистеме Java, можно ожидать всплеска попыток сканирования и атак в ближайшее время. В первую очередь под удар попадают разработчики, которые используют pac4j-jwt для аутентификации в своих веб-сервисах и API. Риск также высок для компаний, чьи приложения развёрнуты в публичном доступе в интернете, так как для атаки не требуется никаких предварительных условий на стороне пользователя (UI:N) или особых привилегий (PR:N).
К счастью, разработчики проекта pac4j оперативно отреагировали на обнаруженную проблему. Уязвимость была устранена в выпущенных патчах. Чтобы обезопасить свои системы, всем пользователям библиотеки необходимо немедленно обновить pac4j-jwt до безопасных версий: 4.5.9, 5.7.9 или 6.3.3 в зависимости от используемой мажорной ветки. Простое обновление зависимостей в файле конфигурации проекта (например, pom.xml для Maven или build.gradle для Gradle) и пересборка приложения полностью закрывает данную брешь. Пока обновление не применено, рекомендуется усилить мониторинг журналов аутентификации на предмет подозрительных успешных входов, особенно с присвоением высоких привилегий. Кроме того, в качестве дополнительной меры безопасности стоит рассмотреть регламентную ротацию ключевых пар, используемых для подписи и шифрования JWT, хотя это и не заменяет установки фикса.
Данный инцидент служит важным напоминанием для архитекторов и разработчиков о критической важности корректной реализации криптографических механизмов. Даже использование проверенных библиотек не гарантирует абсолютной безопасности, если в них сохраняются логические ошибки обработки. Регулярный аудит зависимостей, отслеживание выпусков обновлений безопасности и своевременное применение патчей должны стать неотъемлемой частью жизненного цикла любого современного программного продукта.
Ссылки
- https://www.cve.org/CVERecord?id=CVE-2026-29000
- https://www.pac4j.org/blog/security-advisory-pac4j-jwt-jwtauthenticator.html
- https://www.codeant.ai/security-research/pac4j-jwt-authentication-bypass-public-key
- https://www.vulncheck.com/advisories/pac4j-jwt-jwtauthenticator-authentication-bypass
