Authlib CVE-2026-96760: when a missing signature passes verification

CERT/CC published vulnerability note VU#762428 on 28 September for CVE-2026-96760. It identifies Authlib through version 1.7.2: its general JSON JWS handling can accept an empty signature list as verified data. Exposure concerns applications that trust the result of that path.

Finding Authlib in a dependency list does not establish that a particular service is vulnerable. Determine which module the application uses, which formats it accepts and whether untrusted input reaches the identified function. This requires the application owner’s involvement, alongside whoever maintains dependencies.

Verify data before granting permissions

JWS is a format defined in RFC 7515. In a use case requiring authentication, the recipient should accept content only after its policy for signatures, algorithms and trusted keys is satisfied. Successfully parsing JSON does not make its contents trustworthy.

Consider a conceptual example: a service reads a user identifier and role from a message. If it grants the permission before confirming the required signature, parsing becomes a security decision. The same principle applies to messages between services and signed configuration. A validation failure should terminate processing rather than trigger a fallback that grants greater trust.

Advisory scope and release status are separate questions

The 28 September note reported that no official patch was available when it was written. The project’s repository also contains version 1.8.0, released on 30 August. That does not establish a fix for this CVE; neither do we extend the advisory’s scope to every later version.

Breachroad’s conclusion is that closing the finding should require evidence that the deployed code does not exhibit the reported behaviour. Explicit vendor confirmation, combined with verification of the application’s actual path, can provide that evidence. A scanner reporting “latest version” does not answer the question on its own.

What the team should review now

We propose the following assessment sequence:

1. Identify the actual version and module in the running application, including container images and supplier-operated services.
2. Locate entry points accepting JSON JWS, including deserialize_json() and functions that automatically detect the input format.
3. Confirm that signature failure prevents creation of sessions, assignment of roles and permission grants. Include library wrappers and exception handling.
4. Until safety is established, restrict the exposed path or use independent, verified validation consistent with the application’s policy.
5. Record remediation evidence and recheck rejection of missing, invalid or untrusted signatures in a controlled environment.

Input-shape checks can provide an additional safeguard, but do not replace cryptographic verification. An application-edge control also does not automatically cover internal messages or other services using the same component.

Detection and response

Our recommendation is to correlate JWS rejection events with session creation and privilege changes. Review cases where the application granted access despite failed validation, as well as differences between claimed and verified identities. Retain correlation identifiers and control outcomes; full tokens may expose data and should not be written to ordinary logs.

If the assessment indicates that untrusted data was accepted as an identity, activate incident response. The scope of session invalidation and further investigation should follow the established impact, rather than the library’s presence alone.

Our guide to JWT and JWKS security explains the wider control model. Training for IT teams helps rehearse decisions about trust, escalation and remediation evidence.

Source facts and Breachroad conclusions

The warning’s scope comes from CERT/CC, release information from the project’s repository and the JWS model from RFC 7515. The checklist, application example, detection approach and closure criteria are Breachroad recommendations. This article reflects sources checked on 3 October 2026.