The CERT Coordination Center (CERT/CC) has published advisory VU#762428 describing a signature verification bypass vulnerability in the popular Python library Authlib. According to the advisory, the vulnerability CVE-2026-96760 affects all Authlib versions up to and including 1.7.2 and allows an attacker to submit arbitrary data without any cryptographic signature, which the library will accept as authentic. At the time the advisory was published on 28 September 2026, no official patch was available, and attempts to contact the developer for coordinated disclosure had failed. The vulnerability poses a serious threat to applications that use Authlib to verify JSON Web Signature (JWS) — a mechanism that ensures data integrity and authenticity in OAuth, OpenID Connect, and inter-service communication protocols.
Technical essence of the vulnerability
Authlib is a widely used library for implementing OAuth, OpenID Connect, JWT, JWS, and JWE in Python applications. It is used in web applications and microservices to create and cryptographically validate tokens.
According to the CERT/CC advisory, the problem lies in the JsonWebSignature.deserialize_json() function. When processing a JWS object in the general JSON serialization format, this function accepts an object with an empty \"signatures\": [] array and treats the payload as successfully verified. By default, the function’s logic assumes that signatures are valid, and when the array is empty, the check simply does not run — the loop never iterates, and the data passes through as if it were signed.
According to the advisory, both deserialization paths are affected:
jws.deserialize_json({\"payload\":\"...\", \"signatures\":[]}, key=None)jws.deserialize('{\"payload\":\"...\",\"signatures\":[]}', key=None)
This is a classic example of a CWE-347 (Improper Verification of Cryptographic Signature) vulnerability — improper verification of a cryptographic signature. The attacker does not need to know or brute-force any key material: it is enough to craft a JWS object with an empty signatures list and arbitrary payload content.
Impact assessment
The CERT/CC advisory describes the following potential exploitation scenarios:
- Authentication bypass — forging identity claims or performing privilege escalation (for example,
sub=admin) - Injection of signed messages between microservices that use JWS to ensure integrity
- Forgery of authorization claims — access scopes, roles, permissions
- Integrity violation in systems that rely on signed JWS data
It is important to emphasize that this is a description of potential consequences rather than confirmed incidents. At this time, there is no evidence of active exploitation of the vulnerability, no public PoC code, and no assigned CVSS score. Nevertheless, the very nature of the vulnerability — a complete bypass of cryptographic verification without the need for key material — makes it potentially critical for any application that accepts JWS tokens from untrusted sources via Authlib.
The highest risk is faced by systems in which JWS tokens come from external or partially trusted sources: public APIs with OAuth authentication, microservice architectures with inter-service signature verification, as well as systems that use signed configuration data.
Status of fixes and coordination
According to the CERT/CC advisory, attempts to contact the Authlib developer for coordinated disclosure of the vulnerability were unsuccessful. As of the advisory’s publication date (28 September 2026), no official patch was available and no vendor statement had been received. This means the vulnerability has been disclosed without a ready fix.
Recommendations
Until an official patch is released, it is advisable to consider the following measures:
- Repository monitoring: track updates in the Authlib GitHub repository and the releases page to promptly apply a fix
- Application-level validation: add validation of incoming JWS objects before passing them to Authlib — make sure the
\"signatures\"array is not empty and contains at least one signature - Usage audit: determine whether your code uses
deserialize_json()ordeserialize()calls with data coming from untrusted sources - Reducing the attack surface: if JWS verification via Authlib is used at a trust boundary (public APIs, inter-service communication), consider temporarily adding an intermediate validation layer or switching to an alternative library for critical paths
The vulnerability was discovered by researchers Tong Hoang Gia and Nguyen Minh Tuan, as reported in the CERT/CC advisory.
Given the lack of a patch and the inability to contact the developer, organizations using Authlib for JWS signature verification should immediately audit their applications for handling JWS objects from untrusted sources and implement additional validation of the signatures array until an official fix becomes available.
