Authlib
Monthly
Authlib 0.15 through 1.9.0 can let a party holding any valid RFC 7592 registration access token read, modify, or delete a different client's registration record, because the library's documented example implementations of ClientConfigurationEndpoint.authenticate_client and check_permission never bind the presented token to the target client. The exposure is conditional: it applies to deployments that expose the ClientConfigurationEndpoint and implemented those two methods by copying the shipped docstring examples, which resolve the target from the request-supplied client_id and check only client.editable. Exploitation is authenticated (CVSS PR:L - a valid registration_access_token is required) and also needs the victim's client_id, but under the common open/anonymous RFC 7591 self-registration model an attacker can self-issue a qualifying token for free, after which redirect_uri rewriting enables authorization code or token interception and deletion causes denial of service. Authlib 1.9.1 fixes the flaw; no public exploit was identified at time of analysis, and the overall signal is a conditional this-week remediation priority rather than a mass-exploitation emergency.
Token forgery in the Authlib Python library before 1.9.1 lets a remote, unauthenticated attacker mint HS256, HS384 or HS512 tokens carrying arbitrary claims that Authlib accepts as genuinely signed, whenever the deploying application's HMAC verification key resolves to an empty string or empty bytes (for example an unset environment variable defaulted to '', a config column defaulting to '', or a key-resolver returning '' on a lookup miss). The exposure is strongly gated by that deployment precondition: applications that always supply a non-empty secret are not exploitable, and asymmetric RS/ES verification paths are unaffected, which is why the vector carries AC:H rather than a universally applicable rating. No public exploit code has been identified at time of analysis (the advisory supplies a prose reproduction description rather than weaponized code), CISA KEV does not list this issue, and the vendor has released 1.9.1 as the fix.
Authentication bypass in Authlib's deprecated-but-still-shipped authlib.jose module (1.3.1 through 1.8.0, fixed in 1.9.0) lets an unauthenticated remote attacker forge HS256 JSON Web Tokens with arbitrary subject and role claims using nothing but the issuer's public key, because the OctKey.import_key() guard tests for PEM armour only at byte zero while the PEM loaders skip leading whitespace, comment lines or a BOM. Two non-default deployment properties are required: the relying party uses the documented module-level jwt object (whose registry mixes HS* with RS*/ES*/PS*/EdDSA and whose decode exposes no algorithms parameter), and the verification key is stored as PEM or X.509 certificate text that does not begin at offset 0 with '-----BEGIN ' - a canonical PEM is still blocked, and pinning the algorithm (e.g. JsonWebToken(['RS256'])) is confirmed to reject the forgery. Rated CVSS 7.4 (AV:N/AC:H/PR:N/UI:N, C:H/I:H) and not listed in CISA KEV; the upstream advisory includes an end-to-end proof-of-concept reproduction against 1.8.0.
Authentication bypass in the joserfc Python library before 1.7.4 lets remote, unauthenticated attackers submit a JWS General JSON Serialization whose "signatures" array is empty and have joserfc.jws.deserialize_json() accept it as authenticated, so relying applications can be fooled into treating an arbitrary attacker-chosen payload as a signed, trustworthy message. Exposure is scoped: only the General JSON Serialization code path is affected - compact JWS, JWT decoding, Flattened JSON serialization, and JWE JSON processing do not reach the vulnerable logic - but where the vulnerable API is used and its success is treated as proof of authenticity, the integrity impact is high (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N per the independent assessment; the published base score is 9.1). No public exploit code or confirmed active exploitation has been identified at time of analysis; the fix commit, tests, and security advisory are publicly available.
Poisoned OAuth/OIDC discovery metadata in Authlib 1.7.2 and earlier allows an attacker who controls or intercepts the metadata fetch to replace every cached endpoint - authorization, token, JWKS and userinfo URLs - with attacker-controlled values, enabling token theft, credential interception and authentication bypass in applications built on the library. Publicly available exploit code exists (SSVC exploitation: poc) and the flaw is rated fully automatable with total technical impact, although it is not listed in CISA KEV; EPSS is low at 0.10% (1st percentile). The supplied CVSS of 9.8 overstates realistic reachability versus our assessed 8.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N), because exploitation requires a privileged network position on the discovery fetch or a compromised/malicious issuer endpoint, and TLS-validated metadata from a trusted issuer is not exploitable without first defeating that channel.
Signature verification bypass in Authlib 1.7.2 and earlier allows unauthenticated remote attackers to have crafted JWS JSON Serialization payloads accepted as valid, because JsonWebSignature.deserialize_json() returns the payload without checking for a signature or requiring a cryptographic key. The flaw affects applications that use that method to process incoming tokens and then trust the returned payload for authentication, authorization, or integrity decisions; applications using only compact JWS or independently verifying signatures are not exposed. No public exploit code has been identified at time of analysis, and EPSS is low at 0.12% (2nd percentile), but the issue is remotely exploitable with no authentication or user interaction and is assessed as high severity.
Authentication bypass in Authlib (Python OAuth/OpenID Connect library) versions 1.6.5 through 1.6.6 allows remote attackers to forge JWTs by supplying a token with 'alg: none' and an empty signature, which the library accepts as valid during signature verification. Because the integrity check is silently bypassed, an attacker can craft tokens with arbitrary claims and impersonate any identity. Publicly available exploit code exists (regression-test based, via the GitHub Security Advisory), but EPSS is only 0.02% (6th percentile) and the issue is not in CISA KEV - no public exploit identified as actively used at time of analysis.
Server-side request forgery in Authlib's RFC 9101 JWTAuthenticationRequest (JAR) extension lets unauthenticated remote attackers who know any valid public client_id drive the authorization server's outgoing fetch of an attacker-chosen request_uri. The flaw only materialises in deployments that implemented the abstract get_request_object() hook as an unrestricted outbound fetch, exactly as Authlib's own docstrings demonstrated; the library itself performs no network request, so installations whose override already enforces a scheme/destination allowlist and retrieval limits are unaffected. Affected releases are 1.6.0 through 1.8.x, fixed in 1.9.0, and a public PoC reference exists (demonstrating the unvalidated URI reaching the hook with no network egress); it is not verified as working exploit code, and there is no KEV or active-exploitation signal. Impact is a blind primitive: fetched bodies are consumed as a JWT and never reflected, so attackers get an error-type and timing oracle for internal host and port discovery rather than direct data exfiltration.
Authlib's OpenID Connect implicit grant (OpenIDImplicitGrant) before 1.9.0 validates the openid scope against the raw, client-supplied request.payload.scope instead of the client-filtered request.scope, so a registered client that is permitted an id_token response type but is explicitly denied the openid scope can still obtain a signed ID token. The attacker must already be a registered client (PR:L) and a user must log in and consent (UI:R); the resulting token carries the user's subject and allowed profile claims but its audience is the attacking client, giving limited confidentiality impact. Deployments using only the OIDC authorization-code flow, or where every client permitted an id_token response type is also allowed openid, are unaffected. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the priority signal is a measured this-month fix rather than an emergency.
Authlib's default RFC 7523 JWT bearer grant, in all releases prior to 1.9.0, fails to bind an incoming JWT assertion to the authorization server that receives it, because JWTBearerGrant.get_audiences() returns an empty list and verify_claims() therefore only checks that an aud claim is present rather than that it matches the server's token endpoint. An attacker who already holds a legitimately issued assertion for a different audience (obtained as a low-privilege principal) can replay it against a second authorization server that uses the default grant and shares the same JWT signing key, and receive an access token across that trust boundary. Exploitation requires all three conditions to hold - default grant without a get_audiences() override, shared signing key material, and a valid assertion for some other audience - so implementations that override get_audiences() with their own audience identifiers are explicitly not affected; the issue is not listed in CISA KEV and no in-the-wild exploitation is reported, although the vendor advisory includes a proof-of-concept script that demonstrates the bypass against Authlib's own Flask test fixtures.
Authlib's OpenID Connect client integrations accept an ID token that disables its own nonce check: OpenIDMixin.parse_id_token() reads the nonce_supported claim from the untrusted token payload and, when it is the JSON boolean false, sets the expected nonce to None so both the nonce presence and equality checks are skipped. This lets an attacker who holds a captured, validly signed victim ID token that itself carries nonce_supported:false replay it into an attacker-controlled session and be authenticated as the victim at the relying party; only implicit/hybrid-flow relying parties or applications calling parse_id_token() directly on externally supplied tokens are exposed, while plain authorization code flow is unaffected because the ID token is fetched over TLS after a state lookup. The vendor rates it moderate (assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N, 6.8); exploitation is unauthenticated from the attacker's side but requires user interaction and is gated by the strong precondition that the captured token was originally issued with a literal boolean nonce_supported:false claim, which the attacker cannot add without breaking the signature. The upstream security advisory includes a proof-of-concept script reproducing acceptance of a mismatched nonce on 1.8.0, and no public exploitation activity is indicated.
Authlib's is_secure_transport() TLS guard can be satisfied by a plain-HTTP URL whose userinfo component merely looks like a loopback host, so crafted values such as http://localhost:80@attacker.example/cb are treated as secure even though the parsed host is an external system. The flaw affects authlib versions 0.13 through 1.7.2 and matters where the check is trusted to reject externally supplied URLs - notably OIDC dynamic client registration combined with RP-Initiated Logout (where a public client can register a cleartext non-loopback post_logout_redirect_uris target) and relying parties that call AuthorizationServerMetadata.validate() on an attacker-influenced discovery document. Per the assessed vector (AV:N/AC:H/PR:L/UI:R) the outcome is limited to cleartext redirection and acceptance of cleartext endpoints with low confidentiality impact, requires configured features and end-user logout interaction, and does not bypass OAuth redirect-URI exact matching or forge tokens; a public PoC reference exists in the project's advisory, but it is not verified as working end-to-end exploit code, and there is no CISA KEV entry - the decision label is monitor.
JWT malleability in joserfc versions 1.7.1 and prior allows a low-privileged user holding a valid token to craft alternate byte-distinct representations by exploiting the library's acceptance of non-conforming trailing Base64 padding (==), which violates the JOSE specification. Applications using deny-list-based token revocation or anti-replay protection are at risk of bypass, since a padding-modified token hashes to a different value that will not match the stored revoked-token record. No public exploit code has been identified and this vulnerability is not listed in CISA KEV; the vendor-released fix is joserfc 1.7.2.
Resource exhaustion in joserfc (versions 1.3.4-1.6.5) is possible because the RFC7797 unencoded-payload (b64=false) JWS code path skips the configured JWSRegistry.max_payload_length check, while the standard compact and flattened JSON paths correctly raise ExceededSizeError. Remotely submitted, cryptographically valid b64=false JWS tokens with arbitrarily large payloads are deserialized without size enforcement, consuming memory or CPU on the verifying server. No public exploit has been identified and the vulnerability is not in the CISA KEV catalog; a vendor-released fix is available in version 1.6.7.
Cross-site request forgery (CSRF) in Authlib's Starlette OAuth client cache feature (versions prior to 1.6.11) allows unauthenticated remote attackers to forge requests that manipulate cached OAuth state, potentially leading to session hijacking or token theft. The vulnerability requires user interaction (UI:R) and affects confidentiality and integrity. Vendor-released patch: version 1.6.11.
Authlib is a Python library which builds OAuth and OpenID Connect servers. [CVSS 5.7 MEDIUM]
Unbounded DEFLATE decompression in Authlib's JWE zip=DEF handling (authlib/jose/rfc7518/jwe_zips.py) lets a small, valid ciphertext expand into hundreds of megabytes during decrypt, exhausting memory and CPU on services running versions prior to 1.6.5. Attackers must be able to supply a JWE the application will actually decrypt - typically through possession of key material or an endpoint accepting externally-supplied encrypted tokens - and the impact is availability-only with no disclosure or modification (CVSS 6.5, PR:L, A:H). A public proof-of-concept and a hardened comparison implementation exist, but exploitation requires the application to accept zip=DEF tokens; no confirmed active exploitation is reported, and EPSS is low at 0.46% (38th percentile).
Authlib's JOSE/JWS verification path (through 1.6.4, with 1.6.5 as the fix) decodes attacker-supplied JWT/JWS header and signature segments without any size bound, so a single malicious token with a hundreds-of-megabytes base64url segment can exhaust CPU and memory and knock an OAuth/OIDC or JWT-authenticating service offline. Any application that hands untrusted tokens to Authlib's deserialize_compact / extract_segment routines is exposed, with no authentication or user interaction needed. Publicly available exploit code exists (the advisory ships a working PoC that consumed ~4 GB RSS and ~9 s CPU on a 500 MB header), and the risk is real but bounded: it is availability-only, and it disappears if a proxy, WAF, or application layer rejects oversized tokens before Authlib sees them.
Authlib is a Python library which builds OAuth and OpenID Connect servers. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
lepture Authlib before 1.3.1 has algorithm confusion with asymmetric public keys. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Authlib 0.15 through 1.9.0 can let a party holding any valid RFC 7592 registration access token read, modify, or delete a different client's registration record, because the library's documented example implementations of ClientConfigurationEndpoint.authenticate_client and check_permission never bind the presented token to the target client. The exposure is conditional: it applies to deployments that expose the ClientConfigurationEndpoint and implemented those two methods by copying the shipped docstring examples, which resolve the target from the request-supplied client_id and check only client.editable. Exploitation is authenticated (CVSS PR:L - a valid registration_access_token is required) and also needs the victim's client_id, but under the common open/anonymous RFC 7591 self-registration model an attacker can self-issue a qualifying token for free, after which redirect_uri rewriting enables authorization code or token interception and deletion causes denial of service. Authlib 1.9.1 fixes the flaw; no public exploit was identified at time of analysis, and the overall signal is a conditional this-week remediation priority rather than a mass-exploitation emergency.
Token forgery in the Authlib Python library before 1.9.1 lets a remote, unauthenticated attacker mint HS256, HS384 or HS512 tokens carrying arbitrary claims that Authlib accepts as genuinely signed, whenever the deploying application's HMAC verification key resolves to an empty string or empty bytes (for example an unset environment variable defaulted to '', a config column defaulting to '', or a key-resolver returning '' on a lookup miss). The exposure is strongly gated by that deployment precondition: applications that always supply a non-empty secret are not exploitable, and asymmetric RS/ES verification paths are unaffected, which is why the vector carries AC:H rather than a universally applicable rating. No public exploit code has been identified at time of analysis (the advisory supplies a prose reproduction description rather than weaponized code), CISA KEV does not list this issue, and the vendor has released 1.9.1 as the fix.
Authentication bypass in Authlib's deprecated-but-still-shipped authlib.jose module (1.3.1 through 1.8.0, fixed in 1.9.0) lets an unauthenticated remote attacker forge HS256 JSON Web Tokens with arbitrary subject and role claims using nothing but the issuer's public key, because the OctKey.import_key() guard tests for PEM armour only at byte zero while the PEM loaders skip leading whitespace, comment lines or a BOM. Two non-default deployment properties are required: the relying party uses the documented module-level jwt object (whose registry mixes HS* with RS*/ES*/PS*/EdDSA and whose decode exposes no algorithms parameter), and the verification key is stored as PEM or X.509 certificate text that does not begin at offset 0 with '-----BEGIN ' - a canonical PEM is still blocked, and pinning the algorithm (e.g. JsonWebToken(['RS256'])) is confirmed to reject the forgery. Rated CVSS 7.4 (AV:N/AC:H/PR:N/UI:N, C:H/I:H) and not listed in CISA KEV; the upstream advisory includes an end-to-end proof-of-concept reproduction against 1.8.0.
Authentication bypass in the joserfc Python library before 1.7.4 lets remote, unauthenticated attackers submit a JWS General JSON Serialization whose "signatures" array is empty and have joserfc.jws.deserialize_json() accept it as authenticated, so relying applications can be fooled into treating an arbitrary attacker-chosen payload as a signed, trustworthy message. Exposure is scoped: only the General JSON Serialization code path is affected - compact JWS, JWT decoding, Flattened JSON serialization, and JWE JSON processing do not reach the vulnerable logic - but where the vulnerable API is used and its success is treated as proof of authenticity, the integrity impact is high (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N per the independent assessment; the published base score is 9.1). No public exploit code or confirmed active exploitation has been identified at time of analysis; the fix commit, tests, and security advisory are publicly available.
Poisoned OAuth/OIDC discovery metadata in Authlib 1.7.2 and earlier allows an attacker who controls or intercepts the metadata fetch to replace every cached endpoint - authorization, token, JWKS and userinfo URLs - with attacker-controlled values, enabling token theft, credential interception and authentication bypass in applications built on the library. Publicly available exploit code exists (SSVC exploitation: poc) and the flaw is rated fully automatable with total technical impact, although it is not listed in CISA KEV; EPSS is low at 0.10% (1st percentile). The supplied CVSS of 9.8 overstates realistic reachability versus our assessed 8.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N), because exploitation requires a privileged network position on the discovery fetch or a compromised/malicious issuer endpoint, and TLS-validated metadata from a trusted issuer is not exploitable without first defeating that channel.
Signature verification bypass in Authlib 1.7.2 and earlier allows unauthenticated remote attackers to have crafted JWS JSON Serialization payloads accepted as valid, because JsonWebSignature.deserialize_json() returns the payload without checking for a signature or requiring a cryptographic key. The flaw affects applications that use that method to process incoming tokens and then trust the returned payload for authentication, authorization, or integrity decisions; applications using only compact JWS or independently verifying signatures are not exposed. No public exploit code has been identified at time of analysis, and EPSS is low at 0.12% (2nd percentile), but the issue is remotely exploitable with no authentication or user interaction and is assessed as high severity.
Authentication bypass in Authlib (Python OAuth/OpenID Connect library) versions 1.6.5 through 1.6.6 allows remote attackers to forge JWTs by supplying a token with 'alg: none' and an empty signature, which the library accepts as valid during signature verification. Because the integrity check is silently bypassed, an attacker can craft tokens with arbitrary claims and impersonate any identity. Publicly available exploit code exists (regression-test based, via the GitHub Security Advisory), but EPSS is only 0.02% (6th percentile) and the issue is not in CISA KEV - no public exploit identified as actively used at time of analysis.
Server-side request forgery in Authlib's RFC 9101 JWTAuthenticationRequest (JAR) extension lets unauthenticated remote attackers who know any valid public client_id drive the authorization server's outgoing fetch of an attacker-chosen request_uri. The flaw only materialises in deployments that implemented the abstract get_request_object() hook as an unrestricted outbound fetch, exactly as Authlib's own docstrings demonstrated; the library itself performs no network request, so installations whose override already enforces a scheme/destination allowlist and retrieval limits are unaffected. Affected releases are 1.6.0 through 1.8.x, fixed in 1.9.0, and a public PoC reference exists (demonstrating the unvalidated URI reaching the hook with no network egress); it is not verified as working exploit code, and there is no KEV or active-exploitation signal. Impact is a blind primitive: fetched bodies are consumed as a JWT and never reflected, so attackers get an error-type and timing oracle for internal host and port discovery rather than direct data exfiltration.
Authlib's OpenID Connect implicit grant (OpenIDImplicitGrant) before 1.9.0 validates the openid scope against the raw, client-supplied request.payload.scope instead of the client-filtered request.scope, so a registered client that is permitted an id_token response type but is explicitly denied the openid scope can still obtain a signed ID token. The attacker must already be a registered client (PR:L) and a user must log in and consent (UI:R); the resulting token carries the user's subject and allowed profile claims but its audience is the attacking client, giving limited confidentiality impact. Deployments using only the OIDC authorization-code flow, or where every client permitted an id_token response type is also allowed openid, are unaffected. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the priority signal is a measured this-month fix rather than an emergency.
Authlib's default RFC 7523 JWT bearer grant, in all releases prior to 1.9.0, fails to bind an incoming JWT assertion to the authorization server that receives it, because JWTBearerGrant.get_audiences() returns an empty list and verify_claims() therefore only checks that an aud claim is present rather than that it matches the server's token endpoint. An attacker who already holds a legitimately issued assertion for a different audience (obtained as a low-privilege principal) can replay it against a second authorization server that uses the default grant and shares the same JWT signing key, and receive an access token across that trust boundary. Exploitation requires all three conditions to hold - default grant without a get_audiences() override, shared signing key material, and a valid assertion for some other audience - so implementations that override get_audiences() with their own audience identifiers are explicitly not affected; the issue is not listed in CISA KEV and no in-the-wild exploitation is reported, although the vendor advisory includes a proof-of-concept script that demonstrates the bypass against Authlib's own Flask test fixtures.
Authlib's OpenID Connect client integrations accept an ID token that disables its own nonce check: OpenIDMixin.parse_id_token() reads the nonce_supported claim from the untrusted token payload and, when it is the JSON boolean false, sets the expected nonce to None so both the nonce presence and equality checks are skipped. This lets an attacker who holds a captured, validly signed victim ID token that itself carries nonce_supported:false replay it into an attacker-controlled session and be authenticated as the victim at the relying party; only implicit/hybrid-flow relying parties or applications calling parse_id_token() directly on externally supplied tokens are exposed, while plain authorization code flow is unaffected because the ID token is fetched over TLS after a state lookup. The vendor rates it moderate (assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N, 6.8); exploitation is unauthenticated from the attacker's side but requires user interaction and is gated by the strong precondition that the captured token was originally issued with a literal boolean nonce_supported:false claim, which the attacker cannot add without breaking the signature. The upstream security advisory includes a proof-of-concept script reproducing acceptance of a mismatched nonce on 1.8.0, and no public exploitation activity is indicated.
Authlib's is_secure_transport() TLS guard can be satisfied by a plain-HTTP URL whose userinfo component merely looks like a loopback host, so crafted values such as http://localhost:80@attacker.example/cb are treated as secure even though the parsed host is an external system. The flaw affects authlib versions 0.13 through 1.7.2 and matters where the check is trusted to reject externally supplied URLs - notably OIDC dynamic client registration combined with RP-Initiated Logout (where a public client can register a cleartext non-loopback post_logout_redirect_uris target) and relying parties that call AuthorizationServerMetadata.validate() on an attacker-influenced discovery document. Per the assessed vector (AV:N/AC:H/PR:L/UI:R) the outcome is limited to cleartext redirection and acceptance of cleartext endpoints with low confidentiality impact, requires configured features and end-user logout interaction, and does not bypass OAuth redirect-URI exact matching or forge tokens; a public PoC reference exists in the project's advisory, but it is not verified as working end-to-end exploit code, and there is no CISA KEV entry - the decision label is monitor.
JWT malleability in joserfc versions 1.7.1 and prior allows a low-privileged user holding a valid token to craft alternate byte-distinct representations by exploiting the library's acceptance of non-conforming trailing Base64 padding (==), which violates the JOSE specification. Applications using deny-list-based token revocation or anti-replay protection are at risk of bypass, since a padding-modified token hashes to a different value that will not match the stored revoked-token record. No public exploit code has been identified and this vulnerability is not listed in CISA KEV; the vendor-released fix is joserfc 1.7.2.
Resource exhaustion in joserfc (versions 1.3.4-1.6.5) is possible because the RFC7797 unencoded-payload (b64=false) JWS code path skips the configured JWSRegistry.max_payload_length check, while the standard compact and flattened JSON paths correctly raise ExceededSizeError. Remotely submitted, cryptographically valid b64=false JWS tokens with arbitrarily large payloads are deserialized without size enforcement, consuming memory or CPU on the verifying server. No public exploit has been identified and the vulnerability is not in the CISA KEV catalog; a vendor-released fix is available in version 1.6.7.
Cross-site request forgery (CSRF) in Authlib's Starlette OAuth client cache feature (versions prior to 1.6.11) allows unauthenticated remote attackers to forge requests that manipulate cached OAuth state, potentially leading to session hijacking or token theft. The vulnerability requires user interaction (UI:R) and affects confidentiality and integrity. Vendor-released patch: version 1.6.11.
Authlib is a Python library which builds OAuth and OpenID Connect servers. [CVSS 5.7 MEDIUM]
Unbounded DEFLATE decompression in Authlib's JWE zip=DEF handling (authlib/jose/rfc7518/jwe_zips.py) lets a small, valid ciphertext expand into hundreds of megabytes during decrypt, exhausting memory and CPU on services running versions prior to 1.6.5. Attackers must be able to supply a JWE the application will actually decrypt - typically through possession of key material or an endpoint accepting externally-supplied encrypted tokens - and the impact is availability-only with no disclosure or modification (CVSS 6.5, PR:L, A:H). A public proof-of-concept and a hardened comparison implementation exist, but exploitation requires the application to accept zip=DEF tokens; no confirmed active exploitation is reported, and EPSS is low at 0.46% (38th percentile).
Authlib's JOSE/JWS verification path (through 1.6.4, with 1.6.5 as the fix) decodes attacker-supplied JWT/JWS header and signature segments without any size bound, so a single malicious token with a hundreds-of-megabytes base64url segment can exhaust CPU and memory and knock an OAuth/OIDC or JWT-authenticating service offline. Any application that hands untrusted tokens to Authlib's deserialize_compact / extract_segment routines is exposed, with no authentication or user interaction needed. Publicly available exploit code exists (the advisory ships a working PoC that consumed ~4 GB RSS and ~9 s CPU on a 500 MB header), and the risk is real but bounded: it is availability-only, and it disappears if a proxy, WAF, or application layer rejects oversized tokens before Authlib sees them.
Authlib is a Python library which builds OAuth and OpenID Connect servers. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
lepture Authlib before 1.3.1 has algorithm confusion with asymmetric public keys. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.