Координаційний центр CERT (CERT/CC) опублікував бюлетень VU#762428, у якому описано вразливість обходу перевірки підпису в популярній бібліотеці Python Authlib. Згідно з бюлетенем, вразливість CVE-2026-96760 зачіпає всі версії Authlib включно до 1.7.2 та дає змогу зловмиснику передати довільні дані без будь-якого криптографічного підпису, які бібліотека прийме як автентичні. На момент публікації бюлетеня 28 вересня 2026 року офіційний патч відсутній, а зв’язатися з розробником для скоординованого розкриття не вдалося. Вразливість становить серйозну загрозу для застосунків, які використовують Authlib для перевірки JSON Web Signature (JWS) — механізму, що забезпечує цілісність та автентичність даних у протоколах OAuth, OpenID Connect і під час міжсервісної взаємодії.
Технічна суть вразливості
Authlib — широко використовувана бібліотека для реалізації OAuth, OpenID Connect, JWT, JWS і JWE в Python-застосунках. Її застосовують у вебзастосунках і мікросервісах для створення та криптографічної валідації токенів.
Згідно з бюлетенем CERT/CC, проблема полягає у функції JsonWebSignature.deserialize_json(). Під час обробки об’єкта JWS у форматі загальної JSON-серіалізації ця функція приймає об’єкт із порожнім масивом \"signatures\": [] і вважає корисне навантаження (payload) успішно верифікованим. Логіка роботи функції за замовчуванням передбачає чинність підписів, а за порожнього масиву перевірка просто не виконується — жодної ітерації циклу не відбувається, і дані проходять як підписані.
За даними бюлетеня, зачеплено обидва шляхи десеріалізації:
jws.deserialize_json({\"payload\":\"...\", \"signatures\":[]}, key=None)jws.deserialize('{\"payload\":\"...\",\"signatures\":[]}', key=None)
Це класичний випадок вразливості типу CWE-347 (Improper Verification of Cryptographic Signature) — неналежна перевірка криптографічного підпису. Зловмиснику не потрібно знати чи підбирати ключовий матеріал: достатньо сформувати JWS-об’єкт із порожнім списком підписів і довільним вмістом payload.
Оцінка впливу
Бюлетень CERT/CC описує такі потенційні сценарії експлуатації:
- Обхід автентифікації — підробка тверджень щодо ідентичності або підвищення привілеїв (наприклад,
sub=admin) - Ін’єкція підписаних повідомлень між мікросервісами, які використовують JWS для забезпечення цілісності
- Підробка авторизаційних тверджень — області доступу (scopes), ролі, дозволи
- Порушення цілісності у системах, що покладаються на підписані JWS-дані
Важливо наголосити: це опис потенційних наслідків, а не підтверджених інцидентів. Наразі немає свідчень активної експлуатації вразливості, публічного PoC-коду чи присвоєної оцінки CVSS. Втім, сам характер вразливості — повний обхід криптографічної верифікації без необхідності у ключовому матеріалі — робить її потенційно критичною для будь-якого застосунку, що приймає JWS-токени з недовірених джерел через Authlib.
Найбільшому ризику піддаються системи, у яких JWS-токени надходять із зовнішніх або частково довірених джерел: публічні API з OAuth-автентифікацією, мікросервісні архітектури з міжсервісною перевіркою підписів, а також системи, що використовують підписані конфігураційні дані.
Статус виправлення та координації
Згідно з бюлетенем CERT/CC, зв’язатися з розробником Authlib для скоординованого розкриття вразливості не вдалося. Офіційний патч на момент публікації бюлетеня (28 вересня 2026 року) відсутній, і заяву від вендора не було отримано. Це означає, що вразливість розкрита за відсутності готового виправлення.
Рекомендації
До виходу офіційного патча доцільно розглянути такі заходи:
- Моніторинг репозиторію: відстежуйте оновлення в GitHub-репозиторії Authlib і на сторінці релізів для оперативного встановлення виправлення
- Валідація на рівні застосунку: додайте перевірку вхідних JWS-об’єктів до передання їх в Authlib — переконайтеся, що масив
\"signatures\"не порожній і містить принаймні один підпис - Аудит використання: визначте, чи використовуються у вашому коді виклики
deserialize_json()абоdeserialize()із даними, що надходять з недовірених джерел - Обмеження поверхні атаки: якщо JWS-верифікація через Authlib застосовується на межі довіри (публічні API, міжсервісна взаємодія), розгляньте тимчасове додавання проміжного шару валідації або перехід на альтернативну бібліотеку для критичних шляхів
Вразливість виявили дослідники Tong Hoang Gia та Nguyen Minh Tuan, про що повідомляється в бюлетені CERT/CC.
З огляду на відсутність патча та неможливість зв’язатися з розробником, організаціям, які використовують Authlib для перевірки JWS-підписів, слід негайно провести аудит своїх застосунків щодо обробки JWS-об’єктів з недовірених джерел і впровадити додаткову валідацію масиву підписів до появи офіційного виправлення.
