A critical authentication bypass, a maintainer nobody could reach, and a remediation system with no state for it

On 28 September the CERT Coordination Center published vulnerability note VU#762428 for CVE-2026-96760 in Authlib, a widely used Python library for building OAuth and OpenID Connect clients and servers ^[1][6]. The defect is in JsonWebSignature.deserialize_json(), which accepts a JWS object with an empty signatures array and treats the payload as successfully verified ^[1]. CERT/CC states the consequence plainly: an attacker can forge arbitrary authenticated payloads without any signing key or credentials ^[1].

The note then records something more unusual than the bug. The vendor status is Unknown, because the vendor could not be reached to coordinate this vulnerability and an official patch has not been made available at the time of this writing ^[1]. The recommended remediation is to monitor the project’s repository and install a fix once one is released ^[1].

That is not a remediation. It is a description of waiting, and the rest of the ecosystem has no better answer.

What the flaw is, and why the specification helped

Authlib describes itself as a library for building OAuth 1.0, OAuth 2.0 and OpenID Connect clients and providers, including JWS, JWK, JWA and JWT implementations, with integrations for Requests, HTTPX, Flask, Django, Starlette and FastAPI ^[6]. It is the kind of dependency that sits under an authentication path rather than beside it.

The failure is a verification routine that returns success when there is nothing to verify. CERT/CC lists the downstream effects as authentication bypass through forged identity or privilege-escalation claims, signed message injection between microservices, forged authorisation claims, and integrity compromise in systems relying on signed JWS data ^[1].

The specification deserves a mention, because it is part of the explanation rather than an excuse. RFC 7515 section 7.2.1 states that the signatures member value must be an array of JSON objects ^[5]. It does not, in that text, require the array to be non-empty ^[5]. An implementation that checks the type of the member and iterates it will verify nothing at all when the array is empty, and an implementation that treats iterating zero failures as zero problems will return success. Underspecified requirements produce exactly this class of defect, and the lesson for anyone writing cryptographic verification is that an empty collection is a case, not an absence of cases.

This is also not Authlib’s first verification failure this year. GitHub’s advisory database lists, among others, CVE-2026-27962 as a critical JWS JWK header injection signature-verification bypass and CVE-2026-28802 as an alg none and blank signature bypass, both in March 2026, alongside a fail-open cryptographic verification issue in OIDC hash binding and an older algorithm-confusion flaw ^[3]. The pattern is relevant context for a risk decision. It is not the point of this article.

The point is that nothing downstream can process this

Follow what each part of the remediation chain did with a critical authentication bypass whose maintainer could not be reached.

• CERT/CC published, assigned the CVE, and told users to watch the repository, because with no vendor contact there was nothing else to offer ^[1].
• NVD has the record Awaiting Analysis, so there is no authoritative severity score, no CVSS vector and no CWE mapping to feed into anyone’s prioritisation ^[2].
• GitHub’s advisory database, which is what most dependency scanners and Dependabot consume, does not list this CVE for Authlib as read on 2 October, while listing twelve other Authlib advisories ^[3].
• Ubuntu records it against python-authlib at Medium priority with 22.04, 24.04 and 26.04 LTS all marked Needs evaluation, and no fix released ^[8].
• The Debian tracker has an entry whose note field says only check, with no per-release status ^[9].
• NixOS has an automated tracker issue opened on 29 September against python313Packages.authlib and python314Packages.authlib, assigned to a maintainer, with no response recorded ^[7].

Every one of those is a reasonable institutional behaviour and the aggregate is a null result. A defender who does the correct thing – wait for the vendor, prioritise on the score, trust the scanner feed, apply the distribution update – gets no action from any of it. The remediation system is built on the assumption that a vendor exists at the other end of the disclosure.

There is also a live disagreement about what is affected, and it should not be smoothed over. CERT/CC records the affected range as up to and including 1.7.2 ^[1]. The current release on PyPI is 1.8.0, published 30 August 2026 ^[6]. On 1 October the maintainer of a payments SDK removed Authlib from it, writing that a customer’s scanner flagged authlib 1.8.0 as a critical JWS signature-verification bypass with no upstream patch ^[10]. The 1.8.0 release notes read for this article do not mention the flaw or the affected function ^[4]. Whether 1.8.0 remediates the defect is therefore not established by any source here, and teams are receiving a scanner verdict that contradicts the advisory’s version range.

What to do

• Find out whether you ship it, including transitively. The SDK case is the normal case: Authlib arrived as a dependency of something else and was used for one token request ^[10].
• Do not wait for a scanner to tell you. The CVE is absent from the advisory feed most scanners consume, so a clean dependency report is not evidence of absence here ^[3].
• Treat the version range as unsettled. Do not conclude you are safe on 1.8.0 on the strength of the advisory’s range while a maintainer reports scanners flagging it and the release notes are silent ^[1][6][10].
• If you call deserialize_json() on attacker-reachable input, the path, not the library, is the exposure to reason about. Verification that returns a payload without consuming a key is the behaviour to look for in your own wrappers too ^[1][5].
• Amputation is a legitimate fix and sometimes the fastest one. Replacing a whole OAuth library with a direct token request was proportionate for a single client-credentials call, and it removed an entire unpatched advisory surface from that SDK’s dependency tree ^[10].

The R3KONX view

Offensive security spends most of its attention on the window between disclosure and patch. This case has no such window, because there is no patch and no one to ship it. The interesting failure is not in Authlib’s code; it is that an open-source dependency can be simultaneously critical, confirmed, catalogued and unfixable, and every institution in the chain will correctly record that it is waiting for someone else.

For teams in this region the practical read is about dependency governance rather than this one library. Malaysian and ASEAN engineering teams building on Flask, Django or FastAPI inherit JOSE implementations without choosing them, and the control that matters is knowing which authentication-critical dependencies have a maintainer who answers. That is an inventory question nobody enjoys, and it is cheaper to answer now than during the next unreachable-vendor advisory.