yaal/escut
yaal/escut
Watch
7
0
Fork
You've already forked escut
 0
Code Issues 13 Pull requests Projects 3 Releases Activity Actions

chore(deps): update dependency authlib to v1.6.12 [security] #82

Merged
eloi merged 1 commit from renovate/pypi-authlib-vulnerability into main 2026-08-01 13:45:47 +02:00
Conversation 0 Commits 1 Files changed 1 +38 -37
renovate commented 2026-08-01 06:03:27 +02:00
Member
Copy link

This PR contains the following updates:

Package Change Age Confidence
authlib 1.6.9 → 1.6.12 age confidence

Authlib OAuth 2.0 has Open Redirect in Authorization API that allows attacker-controlled redirect_uri through unsupported response_type

CVE-2026-41479 / GHSA-w8p2-r796-3vmq / PYSEC-2026-2119

More information

Details

Summary

Authlib's OAuth 2.0 authorization endpoint can be turned into an unauthenticated open redirect when a request uses an unsupported response_type and supplies an attacker-controlled redirect_uri.

The vulnerable behavior happens before client lookup and before any redirect URI validation. As a result, an attacker does not need a valid client registration, an authenticated user, or any prior state. A single request to the authorization endpoint is enough to obtain a 302 Location response to an arbitrary attacker-controlled URL.

It was confirmed that the vulnerable code is present in tag v1.6.6 and in the current HEAD under test (68e6ab3fdfc71a328b1966bad5c6aba0f7d0c2e1, git describe: v1.6.6-104-g68e6ab3f). The issue was dynamically reproduced locally on the current HEAD.

Details

The root cause is that AuthorizationServer.get_authorization_grant() copies the raw request
redirect_uri into an UnsupportedResponseTypeError before any client has been resolved and
before any redirect URI validation has happened:

# authlib/oauth2/rfc6749/authorization_server.py
raise UnsupportedResponseTypeError(
    f"The response type '{request.payload.response_type}' is not supported by the server.",
    request.payload.response_type,
    redirect_uri=request.payload.redirect_uri,
)

That error object is later rendered by OAuth2Error.__call__(). If redirect_uri is set, Authlib
automatically returns a redirect response to that URI:

# authlib/oauth2/base.py
def __call__(self, uri=None):
    if self.redirect_uri:
        params = self.get_body()
        loc = add_params_to_uri(self.redirect_uri, params, self.redirect_fragment)
        return 302, "", [("Location", loc)]
    return super().__call__(uri=uri)

This means an unsupported response_type request can force the authorization server to redirect
to an attacker-controlled URL even when:

1. no valid client exists,
2. no grant matched the request,
3. no registered redirect_uri was ever checked.

This is not a contrived code path. It is reachable through the normal Authlib authorization
endpoint flow documented for Flask and Django integrations, where applications are told to call
server.get_consent_grant(...) and then server.handle_error_response(...) on OAuth2Error.

Relevant source and documentation references:

- authlib/oauth2/rfc6749/authorization_server.py
- authlib/oauth2/base.py
- docs/flask/2/authorization-server.rst
- docs/django/2/authorization-server.rst

### PoC

Local test environment:

- Repository checkout: 68e6ab3fdfc71a328b1966bad5c6aba0f7d0c2e1
- git describe: v1.6.6-104-g68e6ab3f
- Python virtualenv: ./.venv
- Environment variable: AUTHLIB_INSECURE_TRANSPORT=true

Note: AUTHLIB_INSECURE_TRANSPORT=true was only used to allow local loopback HTTP reproduction.
It does not create the vulnerable behavior. In a real deployment the same logic is reachable
over HTTPS.

Run this exact PoC from the repository root:

export AUTHLIB_INSECURE_TRANSPORT=true
./.venv/bin/python - <<'PY'
import os, json
from flask import Flask, request
from authlib.integrations.flask_oauth2 import AuthorizationServer
from authlib.oauth2 import OAuth2Error
from authlib.oauth2.rfc6749.grants import AuthorizationCodeGrant as _AuthorizationCodeGrant

os.environ["AUTHLIB_INSECURE_TRANSPORT"] = "true"

class AuthorizationCodeGrant(_AuthorizationCodeGrant):
    def save_authorization_code(self, code, request):
        raise RuntimeError("not reached")
    def query_authorization_code(self, code, client):
        return None
    def delete_authorization_code(self, authorization_code):
        pass
    def authenticate_user(self, authorization_code):
        return None

app = Flask(__name__)
app.secret_key = "testing"

server = AuthorizationServer(
    app,
    query_client=lambda client_id: None,
    save_token=lambda token, request: None,
)
server.register_grant(AuthorizationCodeGrant)

@app.route("/oauth/authorize", methods=["GET", "POST"])
def authorize():
    try:
        grant = server.get_consent_grant(end_user=None)
    except OAuth2Error as error:
        return server.handle_error_response(request, error)
    return server.create_authorization_response(grant=grant, grant_user=None)

with app.test_client() as c:
    cases = {
        "without_redirect_uri": "/oauth/authorize?response_type=totally-unsupported&state=s1",
        "with_attacker_redirect_uri": "/oauth/authorize?response_type=totally-
unsupported&redirect_uri=https%3A%2F%2Fevil.example%2Flanding&state=s1",
    }
    out = {}
    for name, url in cases.items():
        r = c.get(url)
        out[name] = {
            "status": r.status_code,
            "location": r.headers.get("Location"),
            "body": r.get_data(as_text=True),
        }
    print(json.dumps(out, indent=2))
PY

Observed result:

{
  "without_redirect_uri": {
    "status": 400,
    "location": null,
    "body": "{\"error\": \"unsupported_response_type\", \"error_description\": \"totally-
unsupported\", \"state\": \"s1\"}"
  },
  "with_attacker_redirect_uri": {
    "status": 302,
    "location":
"https://evil.example/landing?error=unsupported_response_type&error_description=totally-unsupported&state=s1",                                                                                    
    "body": ""
  }
}

This demonstrates that the only difference between a local error and an external redirect is
whether the attacker supplies redirect_uri.

The same behavior was locally reproduced with the Django integration using RequestFactory; it
returned:

{
  "status": 302,
  "location":
"https://evil.example/landing?error=unsupported_response_type&error_description=totally-unsupported&state=s1",                                                                                    
  "body": ""
}

##### Impact
This is an unauthenticated open redirect in an internet-facing authorization endpoint.

Who is impacted:

- Any deployment using Authlib's OAuth 2.0 authorization server and the documented authorization
  endpoint flow.
- No special feature flag is required beyond running the authorization endpoint itself.

Attacker prerequisites:

- None beyond the ability to send a victim to a crafted authorization URL.

Practical harm:

- Phishing and credential theft by abusing a trusted authorization server domain as a
  redirector.
- Bypass of domain-based allowlists that trust the authorization server's host.
- SSO / OAuth confusion in ecosystems where trusted authorization endpoints are expected to
  reject unregistered redirect URIs before redirecting.

The issue is especially concerning because the redirect happens before client existence and
redirect URI legitimacy are established.

#### Severity
- CVSS Score: 5.4 / 10 (Medium)
- Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N`

#### References
- [https://github.com/authlib/authlib/security/advisories/GHSA-w8p2-r796-3vmq](https://github.com/authlib/authlib/security/advisories/GHSA-w8p2-r796-3vmq)
- [https://nvd.nist.gov/vuln/detail/CVE-2026-41479](https://nvd.nist.gov/vuln/detail/CVE-2026-41479)
- [https://github.com/authlib/authlib/commit/3be08468201a7766a93012ce149ea12822cab096](https://github.com/authlib/authlib/commit/3be08468201a7766a93012ce149ea12822cab096)
- [https://github.com/authlib/authlib](https://github.com/authlib/authlib)
- [https://github.com/pypa/advisory-database/tree/main/vulns/authlib/PYSEC-2026-2119.yaml](https://github.com/pypa/advisory-database/tree/main/vulns/authlib/PYSEC-2026-2119.yaml)

This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-w8p2-r796-3vmq) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)).
</details>

---

### [CVE-2026-41479](https://nvd.nist.gov/vuln/detail/CVE-2026-41479) / [GHSA-w8p2-r796-3vmq](https://github.com/advisories/GHSA-w8p2-r796-3vmq) / PYSEC-2026-2119

<details>
<summary>More information</summary>

#### Details
Authlib is a Python library which builds OAuth and OpenID Connect servers. Prior to 1.6.10 and 1.7.1, Authlib's OAuth 2.0 authorization endpoint can be turned into an unauthenticated open redirect when a request uses an unsupported response_type and supplies an attacker-controlled redirect_uri. The vulnerable behavior happens before client lookup and before any redirect URI validation. As a result, an attacker does not need a valid client registration, an authenticated user, or any prior state. A single request to the authorization endpoint is enough to obtain a 302 Location response to an arbitrary attacker-controlled URL. This vulnerability is fixed in 1.6.10 and 1.7.1.

#### Severity
- CVSS Score: 5.4 / 10 (Medium)
- Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N`

#### References
- [https://github.com/authlib/authlib/commit/3be08468201a7766a93012ce149ea12822cab096](https://github.com/authlib/authlib/commit/3be08468201a7766a93012ce149ea12822cab096)
- [https://github.com/authlib/authlib/security/advisories/GHSA-w8p2-r796-3vmq](https://github.com/authlib/authlib/security/advisories/GHSA-w8p2-r796-3vmq)

This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-2119) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)).
</details>

---

### Authlib: Cross-site request forging when using cache
[CVE-2026-41425](https://nvd.nist.gov/vuln/detail/CVE-2026-41425) / [GHSA-jj8c-mmj3-mmgv](https://github.com/advisories/GHSA-jj8c-mmj3-mmgv) / PYSEC-2026-25

<details>
<summary>More information</summary>

#### Details
##### Summary

There is no CSRF protection on the cache feature on most integrations clients.

##### Details
In `authlib.integrations.starlette_client.OAuth`, no CSRF protection is set up when using the cache parameter. When _not_ using the cache parameter, the use of SessionMiddleware ties the client to the auth state, preventing CSRF attacks. With the cache, there is no such mechanism. Other integratons have the same issue, it's not just starlette.

The state parameter is taken from the callback URL and the state is fetched from the cache without checking that it is the same client calling the redirect endpoint as was the one that initiated the auth flow.

This issue is documented in RFC 6749 section 10.12:
https://datatracker.ietf.org/doc/html/rfc6749#section-10.12

##### PoC
- Set up a Starlette integration with a cache
- The attacker starts the auth flow up until before the callback URL is followed.
- The attacked sends the redirect URL to the victim
- The victim now completes the authorisation

##### Impact
This impacts all users that use the cache to store auth state.

All users will be vulnerable to CSRF attacks and may have an attacker's account tied to their own.

#### Severity
- CVSS Score: 5.4 / 10 (Medium)
- Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N`

#### References
- [https://github.com/authlib/authlib/security/advisories/GHSA-jj8c-mmj3-mmgv](https://github.com/authlib/authlib/security/advisories/GHSA-jj8c-mmj3-mmgv)
- [https://nvd.nist.gov/vuln/detail/CVE-2026-41425](https://nvd.nist.gov/vuln/detail/CVE-2026-41425)
- [https://github.com/authlib/authlib](https://github.com/authlib/authlib)
- [https://github.com/pypa/advisory-database/tree/main/vulns/authlib/PYSEC-2026-25.yaml](https://github.com/pypa/advisory-database/tree/main/vulns/authlib/PYSEC-2026-25.yaml)

This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-jj8c-mmj3-mmgv) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)).
</details>

---

### [CVE-2026-41425](https://nvd.nist.gov/vuln/detail/CVE-2026-41425) / [GHSA-jj8c-mmj3-mmgv](https://github.com/advisories/GHSA-jj8c-mmj3-mmgv) / PYSEC-2026-25

<details>
<summary>More information</summary>

#### Details
Authlib is a Python library which builds OAuth and OpenID Connect servers. Prior to 1.6.11, there is no CSRF protection on the cache feature in authlib.integrations.starlette_client.OAuth.  This vulnerability is fixed in 1.6.11.

#### Severity
- CVSS Score: 5.4 / 10 (Medium)
- Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N`

#### References
- [https://github.com/authlib/authlib/security/advisories/GHSA-jj8c-mmj3-mmgv](https://github.com/authlib/authlib/security/advisories/GHSA-jj8c-mmj3-mmgv)

This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-25) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)).
</details>

---

### Authlib OIDC Implicit/Hybrid Authorization Vulnerable to Open Redirect
[CVE-2026-44681](https://nvd.nist.gov/vuln/detail/CVE-2026-44681) / [GHSA-r95x-qfjj-fjj2](https://github.com/advisories/GHSA-r95x-qfjj-fjj2) / PYSEC-2026-188

<details>
<summary>More information</summary>

#### Details
##### Summary

An unauthenticated open redirect in Authlib's `OpenIDImplicitGrant` and `OpenIDHybridGrant` authorization endpoint lets a remote attacker cause the authorization server to issue an HTTP 302 to an attacker-chosen URL by submitting an authorization request that omits the `openid` scope.

##### Details

##### Vulnerable code

`OpenIDImplicitGrant.validate_authorization_request` in `authlib/oidc/core/grants/implicit.py`:

```python
def validate_authorization_request(self):
  if not is_openid_scope(self.request.payload.scope):
      raise InvalidScopeError(
          "Missing 'openid' scope",
          redirect_uri=self.request.payload.redirect_uri,  # ← raw, unvalidated
          redirect_fragment=True,
      )
  redirect_uri = super().validate_authorization_request()
  ...

OpenIDHybridGrant.validate_authorization_request in authlib/oidc/core/grants/hybrid.py shares the same pattern.

Root cause

Both methods perform the openid scope presence check before delegating to super().validate_authorization_request(), which is where AuthorizationEndpointMixin.validate_authorization_redirect_uri validates the requested redirect_uri against the client's check_redirect_uri(...). The InvalidScopeError thrown by the scope check therefore carries attacker-controlled self.request.payload.redirect_uri.

OAuth2Error.__call__ in authlib/oauth2/base.py renders any error with a non-empty redirect_uri as an HTTP 302:

def __call__(self, uri=None):
    if self.redirect_uri:
        params = self.get_body()
        loc = add_params_to_uri(self.redirect_uri, params, self.redirect_fragment)
        return 302, "", [("Location", loc)]
    return super().__call__(uri=uri)

A malformed authorization request that selects OpenIDImplicitGrant or OpenIDHybridGrant and omits the openid scope is therefore redirected to a fully attacker-chosen URL.

This is a variant of the issue fixed in commit 3be08468 ("fix: redirecting to unvalidated redirect_uri on UnsupportedResponseTypeError") that was missed in the OIDC Implicit and Hybrid grants.

Preconditions
  1. The server registers OpenIDImplicitGrant or OpenIDHybridGrant (standard OIDC Implicit or Hybrid flow support).
  2. The attacker's request uses a response_type that matches either grant: id_token, id_token token, code id_token, code token, or code id_token token.
  3. scope does not contain openid.
  4. Any redirect_uri value.

No user authentication, no consent, no valid session, no CSRF token, and — notably — no valid client_id are required. The scope check runs before any client lookup, so any client_id value (including nonexistent ones) reaches the vulnerable code path.

PoC

The following unauthenticated GET is sufficient to induce the authorization server to redirect a victim's browser to an attacker-controlled URL:

GET /oauth/authorize
    ?response_type=id_token
    &client_id=anything
    &scope=profile
    &redirect_uri=https%3A%2F%2Fevil.example.com%2Fphish
    &state=s&nonce=n  HTTP/1.1
Host: victim-op.example

Server response:

HTTP/1.1 302 Found
Location: https://evil.example.com/phish#error=invalid_scope&error_description=Missing+%27openid%27+scope&state=s
Impact
  • Open redirect from a trusted authorization server origin. Victims receiving a phishing link see the legitimate OIDC provider's domain in the URL bar at the moment they click. The authorization server itself issues the 302 to the attacker's page, lending the attacker's landing page the OP's reputation and potentially satisfying domain-allow-list controls that trust the OP.
  • Phishing / credential harvesting leverage. The attacker's page can mimic the legitimate OP's consent screen or a relying-party error page to solicit credentials, MFA codes, or to continue a downstream confused-deputy attack.
  • RFC violation. RFC 6749 §4.1.2.1 and RFC 9700 (OAuth 2.0 Security BCP) §4.11 both state that an authorization server MUST NOT perform redirection to a redirect_uri that has not been validated against the client's registered URIs, even in error responses. The state parameter is echoed back, giving the attacker site a stable correlator.
  • No direct token/code leak. This flaw fires before any authorization decision, so no authorization codes, ID tokens, or access tokens are disclosed. The impact is limited to open-redirect phishing leverage. Combined with other issues (e.g., downstream SSO trust chains) it may contribute to account-takeover chains; on its own it is a Medium-severity open redirect.
Affected deployments

Any application using Authlib as an OIDC provider that registers OpenIDImplicitGrant and/or OpenIDHybridGrant — i.e. anyone supporting the Implicit flow or the Hybrid flow (response_type=code id_token, etc.) — is affected. Clients of an Authlib-based OP are not directly affected; this is a server-side issue.

Authorization servers that only register the plain AuthorizationCodeGrant (code flow, with or without PKCE and the OpenIDCode extension) are not affected by this specific variant: the code-flow grant validates redirect_uri before raising scope errors. If you were affected by the sibling issue fixed in 3be08468 (UnsupportedResponseTypeError), you should already be on 1.6.10 or later; this advisory is independent of that fix.

Suggested fix

The attached fix-oidc-open-redirect.patch reorders each method to delegate to its super (or call validate_code_authorization_request for Hybrid) first, and then performs the openid-scope check with the validated redirect_uri variable.


##### authlib/oidc/core/grants/implicit.py
def validate_authorization_request(self):
    redirect_uri = super().validate_authorization_request()   # runs client + redirect_uri validation
    if not is_openid_scope(self.request.payload.scope):
        raise InvalidScopeError(
            "Missing 'openid' scope",
            redirect_uri=redirect_uri,                         # validated
            redirect_fragment=True,
        )
    try:
        validate_nonce(self.request, self.exists_nonce, required=True)
    except OAuth2Error as error:
        error.redirect_uri = redirect_uri
        error.redirect_fragment = True
        raise error
    return redirect_uri

An equivalent transform is applied to OpenIDHybridGrant.validate_authorization_request, invoking validate_code_authorization_request first and only then checking is_openid_scope.

Alternatively, inline a client = query_client(request.payload.client_id) + client.check_redirect_uri(request.payload.redirect_uri) guard before populating redirect_uri on the error — the pattern used in 3be08468.

The patch also adds regression tests analogous to test_unsupported_response_type_does_not_redirect from commit 3be08468, asserting rv.status_code == 400 and rv.headers.get("Location") is None for an unregistered redirect_uri with a non-openid scope.

Workarounds

No clean server-side workaround exists short of patching. Partial mitigations:

  • Unregister OpenIDImplicitGrant and OpenIDHybridGrant if the Implicit and Hybrid flows are not required. (RFC 9700 deprecates the Implicit flow and discourages Hybrid flows, so this is recommended anyway.)
  • Front the /authorize endpoint with a reverse proxy rule that rejects requests containing both a redirect_uri parameter and a scope that does not include openid when response_type matches the vulnerable set. This is fragile and not recommended as a primary control.
References
  • RFC 6749, §4.1.2.1 — Error Response (OAuth 2.0 authorization endpoint)
  • RFC 9700, §4.11 — Redirect URI validation
  • OpenID Connect Core 1.0, §3.2.2.6 / §3.3.2.6 — Authentication Error Response
  • Authlib commit 3be08468 — prior fix for the same class of issue in UnsupportedResponseTypeError (Authlib 1.6.10)
  • Authlib source (by symbol; verified in commit 5d2e603e):
    • OpenIDImplicitGrant.validate_authorization_request — authlib/oidc/core/grants/implicit.py
    • OpenIDHybridGrant.validate_authorization_request — authlib/oidc/core/grants/hybrid.py
    • OAuth2Error.__call__ — authlib/oauth2/base.py (renders errors with redirect_uri as HTTP 302)
    • AuthorizationEndpointMixin.validate_authorization_redirect_uri — authlib/oauth2/rfc6749/grants/base.py (the validation that is bypassed)

Severity

  • CVSS Score: 6.1 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

CVE-2026-44681 / GHSA-r95x-qfjj-fjj2 / PYSEC-2026-188

More information

Details

Authlib is a Python library which builds OAuth and OpenID Connect servers. Prior to 1.6.12 and 1.7.1, an unauthenticated open redirect in Authlib's OpenIDImplicitGrant and OpenIDHybridGrant authorization endpoint lets a remote attacker cause the authorization server to issue an HTTP 302 to an attacker-chosen URL by submitting an authorization request that omits the openid scope. This vulnerability is fixed in 1.6.12 and 1.7.1.

Severity

  • CVSS Score: 6.1 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

Release Notes

authlib/authlib (authlib)

v1.6.12

Compare Source

v1.6.11

Compare Source

Full Changelog: https://github.com/authlib/authlib/compare/v1.6.10...v1.6.11

  • Fix CSRF issue with starlette client

v1.6.10

Compare Source

Full Changelog: https://github.com/authlib/authlib/compare/v1.6.9...v1.6.10

  • Fix redirecting to unvalidated redirect_uri on UnsupportedResponseTypeError.

Configuration

📅 Schedule: (in timezone Europe/Paris)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate CLI.

This PR contains the following updates: | Package | Change | [Age](https://docs.renovatebot.com/merge-confidence/) | [Confidence](https://docs.renovatebot.com/merge-confidence/) | |---|---|---|---| | [authlib](https://github.com/authlib/authlib) | `1.6.9` → `1.6.12` | ![age](https://developer.mend.io/api/mc/badges/age/pypi/authlib/1.6.12?slim=true) | ![confidence](https://developer.mend.io/api/mc/badges/confidence/pypi/authlib/1.6.9/1.6.12?slim=true) | --- ### Authlib OAuth 2.0 has Open Redirect in Authorization API that allows attacker-controlled redirect_uri through unsupported response_type [CVE-2026-41479](https://nvd.nist.gov/vuln/detail/CVE-2026-41479) / [GHSA-w8p2-r796-3vmq](https://github.com/advisories/GHSA-w8p2-r796-3vmq) / PYSEC-2026-2119 <details> <summary>More information</summary> #### Details ##### Summary Authlib's OAuth 2.0 authorization endpoint can be turned into an unauthenticated open redirect when a request uses an unsupported response_type and supplies an attacker-controlled redirect_uri. The vulnerable behavior happens before client lookup and before any redirect URI validation. As a result, an attacker does not need a valid client registration, an authenticated user, or any prior state. A single request to the authorization endpoint is enough to obtain a 302 Location response to an arbitrary attacker-controlled URL. It was confirmed that the vulnerable code is present in tag v1.6.6 and in the current HEAD under test (68e6ab3fdfc71a328b1966bad5c6aba0f7d0c2e1, git describe: v1.6.6-104-g68e6ab3f). The issue was dynamically reproduced locally on the current HEAD. ##### Details The root cause is that `AuthorizationServer.get_authorization_grant()` copies the raw request `redirect_uri` into an `UnsupportedResponseTypeError` before any client has been resolved and before any redirect URI validation has happened: ```python # authlib/oauth2/rfc6749/authorization_server.py raise UnsupportedResponseTypeError( f"The response type '{request.payload.response_type}' is not supported by the server.", request.payload.response_type, redirect_uri=request.payload.redirect_uri, ) That error object is later rendered by OAuth2Error.__call__(). If redirect_uri is set, Authlib automatically returns a redirect response to that URI: # authlib/oauth2/base.py def __call__(self, uri=None): if self.redirect_uri: params = self.get_body() loc = add_params_to_uri(self.redirect_uri, params, self.redirect_fragment) return 302, "", [("Location", loc)] return super().__call__(uri=uri) This means an unsupported response_type request can force the authorization server to redirect to an attacker-controlled URL even when: 1. no valid client exists, 2. no grant matched the request, 3. no registered redirect_uri was ever checked. This is not a contrived code path. It is reachable through the normal Authlib authorization endpoint flow documented for Flask and Django integrations, where applications are told to call server.get_consent_grant(...) and then server.handle_error_response(...) on OAuth2Error. Relevant source and documentation references: - authlib/oauth2/rfc6749/authorization_server.py - authlib/oauth2/base.py - docs/flask/2/authorization-server.rst - docs/django/2/authorization-server.rst ### PoC Local test environment: - Repository checkout: 68e6ab3fdfc71a328b1966bad5c6aba0f7d0c2e1 - git describe: v1.6.6-104-g68e6ab3f - Python virtualenv: ./.venv - Environment variable: AUTHLIB_INSECURE_TRANSPORT=true Note: AUTHLIB_INSECURE_TRANSPORT=true was only used to allow local loopback HTTP reproduction. It does not create the vulnerable behavior. In a real deployment the same logic is reachable over HTTPS. Run this exact PoC from the repository root: export AUTHLIB_INSECURE_TRANSPORT=true ./.venv/bin/python - <<'PY' import os, json from flask import Flask, request from authlib.integrations.flask_oauth2 import AuthorizationServer from authlib.oauth2 import OAuth2Error from authlib.oauth2.rfc6749.grants import AuthorizationCodeGrant as _AuthorizationCodeGrant os.environ["AUTHLIB_INSECURE_TRANSPORT"] = "true" class AuthorizationCodeGrant(_AuthorizationCodeGrant): def save_authorization_code(self, code, request): raise RuntimeError("not reached") def query_authorization_code(self, code, client): return None def delete_authorization_code(self, authorization_code): pass def authenticate_user(self, authorization_code): return None app = Flask(__name__) app.secret_key = "testing" server = AuthorizationServer( app, query_client=lambda client_id: None, save_token=lambda token, request: None, ) server.register_grant(AuthorizationCodeGrant) @app.route("/oauth/authorize", methods=["GET", "POST"]) def authorize(): try: grant = server.get_consent_grant(end_user=None) except OAuth2Error as error: return server.handle_error_response(request, error) return server.create_authorization_response(grant=grant, grant_user=None) with app.test_client() as c: cases = { "without_redirect_uri": "/oauth/authorize?response_type=totally-unsupported&state=s1", "with_attacker_redirect_uri": "/oauth/authorize?response_type=totally- unsupported&redirect_uri=https%3A%2F%2Fevil.example%2Flanding&state=s1", } out = {} for name, url in cases.items(): r = c.get(url) out[name] = { "status": r.status_code, "location": r.headers.get("Location"), "body": r.get_data(as_text=True), } print(json.dumps(out, indent=2)) PY Observed result: { "without_redirect_uri": { "status": 400, "location": null, "body": "{\"error\": \"unsupported_response_type\", \"error_description\": \"totally- unsupported\", \"state\": \"s1\"}" }, "with_attacker_redirect_uri": { "status": 302, "location": "https://evil.example/landing?error=unsupported_response_type&error_description=totally-unsupported&state=s1", "body": "" } } This demonstrates that the only difference between a local error and an external redirect is whether the attacker supplies redirect_uri. The same behavior was locally reproduced with the Django integration using RequestFactory; it returned: { "status": 302, "location": "https://evil.example/landing?error=unsupported_response_type&error_description=totally-unsupported&state=s1", "body": "" } ##### Impact This is an unauthenticated open redirect in an internet-facing authorization endpoint. Who is impacted: - Any deployment using Authlib's OAuth 2.0 authorization server and the documented authorization endpoint flow. - No special feature flag is required beyond running the authorization endpoint itself. Attacker prerequisites: - None beyond the ability to send a victim to a crafted authorization URL. Practical harm: - Phishing and credential theft by abusing a trusted authorization server domain as a redirector. - Bypass of domain-based allowlists that trust the authorization server's host. - SSO / OAuth confusion in ecosystems where trusted authorization endpoints are expected to reject unregistered redirect URIs before redirecting. The issue is especially concerning because the redirect happens before client existence and redirect URI legitimacy are established. #### Severity - CVSS Score: 5.4 / 10 (Medium) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N` #### References - [https://github.com/authlib/authlib/security/advisories/GHSA-w8p2-r796-3vmq](https://github.com/authlib/authlib/security/advisories/GHSA-w8p2-r796-3vmq) - [https://nvd.nist.gov/vuln/detail/CVE-2026-41479](https://nvd.nist.gov/vuln/detail/CVE-2026-41479) - [https://github.com/authlib/authlib/commit/3be08468201a7766a93012ce149ea12822cab096](https://github.com/authlib/authlib/commit/3be08468201a7766a93012ce149ea12822cab096) - [https://github.com/authlib/authlib](https://github.com/authlib/authlib) - [https://github.com/pypa/advisory-database/tree/main/vulns/authlib/PYSEC-2026-2119.yaml](https://github.com/pypa/advisory-database/tree/main/vulns/authlib/PYSEC-2026-2119.yaml) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-w8p2-r796-3vmq) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### [CVE-2026-41479](https://nvd.nist.gov/vuln/detail/CVE-2026-41479) / [GHSA-w8p2-r796-3vmq](https://github.com/advisories/GHSA-w8p2-r796-3vmq) / PYSEC-2026-2119 <details> <summary>More information</summary> #### Details Authlib is a Python library which builds OAuth and OpenID Connect servers. Prior to 1.6.10 and 1.7.1, Authlib's OAuth 2.0 authorization endpoint can be turned into an unauthenticated open redirect when a request uses an unsupported response_type and supplies an attacker-controlled redirect_uri. The vulnerable behavior happens before client lookup and before any redirect URI validation. As a result, an attacker does not need a valid client registration, an authenticated user, or any prior state. A single request to the authorization endpoint is enough to obtain a 302 Location response to an arbitrary attacker-controlled URL. This vulnerability is fixed in 1.6.10 and 1.7.1. #### Severity - CVSS Score: 5.4 / 10 (Medium) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N` #### References - [https://github.com/authlib/authlib/commit/3be08468201a7766a93012ce149ea12822cab096](https://github.com/authlib/authlib/commit/3be08468201a7766a93012ce149ea12822cab096) - [https://github.com/authlib/authlib/security/advisories/GHSA-w8p2-r796-3vmq](https://github.com/authlib/authlib/security/advisories/GHSA-w8p2-r796-3vmq) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-2119) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### Authlib: Cross-site request forging when using cache [CVE-2026-41425](https://nvd.nist.gov/vuln/detail/CVE-2026-41425) / [GHSA-jj8c-mmj3-mmgv](https://github.com/advisories/GHSA-jj8c-mmj3-mmgv) / PYSEC-2026-25 <details> <summary>More information</summary> #### Details ##### Summary There is no CSRF protection on the cache feature on most integrations clients. ##### Details In `authlib.integrations.starlette_client.OAuth`, no CSRF protection is set up when using the cache parameter. When _not_ using the cache parameter, the use of SessionMiddleware ties the client to the auth state, preventing CSRF attacks. With the cache, there is no such mechanism. Other integratons have the same issue, it's not just starlette. The state parameter is taken from the callback URL and the state is fetched from the cache without checking that it is the same client calling the redirect endpoint as was the one that initiated the auth flow. This issue is documented in RFC 6749 section 10.12: https://datatracker.ietf.org/doc/html/rfc6749#section-10.12 ##### PoC - Set up a Starlette integration with a cache - The attacker starts the auth flow up until before the callback URL is followed. - The attacked sends the redirect URL to the victim - The victim now completes the authorisation ##### Impact This impacts all users that use the cache to store auth state. All users will be vulnerable to CSRF attacks and may have an attacker's account tied to their own. #### Severity - CVSS Score: 5.4 / 10 (Medium) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N` #### References - [https://github.com/authlib/authlib/security/advisories/GHSA-jj8c-mmj3-mmgv](https://github.com/authlib/authlib/security/advisories/GHSA-jj8c-mmj3-mmgv) - [https://nvd.nist.gov/vuln/detail/CVE-2026-41425](https://nvd.nist.gov/vuln/detail/CVE-2026-41425) - [https://github.com/authlib/authlib](https://github.com/authlib/authlib) - [https://github.com/pypa/advisory-database/tree/main/vulns/authlib/PYSEC-2026-25.yaml](https://github.com/pypa/advisory-database/tree/main/vulns/authlib/PYSEC-2026-25.yaml) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-jj8c-mmj3-mmgv) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### [CVE-2026-41425](https://nvd.nist.gov/vuln/detail/CVE-2026-41425) / [GHSA-jj8c-mmj3-mmgv](https://github.com/advisories/GHSA-jj8c-mmj3-mmgv) / PYSEC-2026-25 <details> <summary>More information</summary> #### Details Authlib is a Python library which builds OAuth and OpenID Connect servers. Prior to 1.6.11, there is no CSRF protection on the cache feature in authlib.integrations.starlette_client.OAuth. This vulnerability is fixed in 1.6.11. #### Severity - CVSS Score: 5.4 / 10 (Medium) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N` #### References - [https://github.com/authlib/authlib/security/advisories/GHSA-jj8c-mmj3-mmgv](https://github.com/authlib/authlib/security/advisories/GHSA-jj8c-mmj3-mmgv) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-25) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### Authlib OIDC Implicit/Hybrid Authorization Vulnerable to Open Redirect [CVE-2026-44681](https://nvd.nist.gov/vuln/detail/CVE-2026-44681) / [GHSA-r95x-qfjj-fjj2](https://github.com/advisories/GHSA-r95x-qfjj-fjj2) / PYSEC-2026-188 <details> <summary>More information</summary> #### Details ##### Summary An unauthenticated open redirect in Authlib's `OpenIDImplicitGrant` and `OpenIDHybridGrant` authorization endpoint lets a remote attacker cause the authorization server to issue an HTTP 302 to an attacker-chosen URL by submitting an authorization request that omits the `openid` scope. ##### Details ##### Vulnerable code `OpenIDImplicitGrant.validate_authorization_request` in `authlib/oidc/core/grants/implicit.py`: ```python def validate_authorization_request(self): if not is_openid_scope(self.request.payload.scope): raise InvalidScopeError( "Missing 'openid' scope", redirect_uri=self.request.payload.redirect_uri, # ← raw, unvalidated redirect_fragment=True, ) redirect_uri = super().validate_authorization_request() ... ``` `OpenIDHybridGrant.validate_authorization_request` in `authlib/oidc/core/grants/hybrid.py` shares the same pattern. ##### Root cause Both methods perform the `openid` scope presence check before delegating to `super().validate_authorization_request()`, which is where `AuthorizationEndpointMixin.validate_authorization_redirect_uri` validates the requested `redirect_uri` against the client's `check_redirect_uri(...)`. The `InvalidScopeError` thrown by the scope check therefore carries attacker-controlled `self.request.payload.redirect_uri`. `OAuth2Error.__call__` in `authlib/oauth2/base.py` renders any error with a non-empty `redirect_uri` as an HTTP 302: ```python def __call__(self, uri=None): if self.redirect_uri: params = self.get_body() loc = add_params_to_uri(self.redirect_uri, params, self.redirect_fragment) return 302, "", [("Location", loc)] return super().__call__(uri=uri) ``` A malformed authorization request that selects `OpenIDImplicitGrant` or `OpenIDHybridGrant` and omits the `openid` scope is therefore redirected to a fully attacker-chosen URL. This is a variant of the issue fixed in commit [`3be08468`](https://github.com/authlib/authlib/commit/3be08468) ("fix: redirecting to unvalidated `redirect_uri` on `UnsupportedResponseTypeError`") that was missed in the OIDC Implicit and Hybrid grants. ##### Preconditions 1. The server registers `OpenIDImplicitGrant` or `OpenIDHybridGrant` (standard OIDC Implicit or Hybrid flow support). 2. The attacker's request uses a `response_type` that matches either grant: `id_token`, `id_token token`, `code id_token`, `code token`, or `code id_token token`. 3. `scope` does not contain `openid`. 4. Any `redirect_uri` value. No user authentication, no consent, no valid session, no CSRF token, and — notably — no valid `client_id` are required. The scope check runs before any client lookup, so any `client_id` value (including nonexistent ones) reaches the vulnerable code path. ##### PoC The following unauthenticated GET is sufficient to induce the authorization server to redirect a victim's browser to an attacker-controlled URL: ``` GET /oauth/authorize ?response_type=id_token &client_id=anything &scope=profile &redirect_uri=https%3A%2F%2Fevil.example.com%2Fphish &state=s&nonce=n HTTP/1.1 Host: victim-op.example ``` Server response: ``` HTTP/1.1 302 Found Location: https://evil.example.com/phish#error=invalid_scope&error_description=Missing+%27openid%27+scope&state=s ``` ##### Impact - Open redirect from a trusted authorization server origin. Victims receiving a phishing link see the legitimate OIDC provider's domain in the URL bar at the moment they click. The authorization server itself issues the 302 to the attacker's page, lending the attacker's landing page the OP's reputation and potentially satisfying domain-allow-list controls that trust the OP. - Phishing / credential harvesting leverage. The attacker's page can mimic the legitimate OP's consent screen or a relying-party error page to solicit credentials, MFA codes, or to continue a downstream confused-deputy attack. - RFC violation. RFC 6749 §4.1.2.1 and RFC 9700 (OAuth 2.0 Security BCP) §4.11 both state that an authorization server MUST NOT perform redirection to a `redirect_uri` that has not been validated against the client's registered URIs, even in error responses. The `state` parameter is echoed back, giving the attacker site a stable correlator. - No direct token/code leak. This flaw fires before any authorization decision, so no authorization codes, ID tokens, or access tokens are disclosed. The impact is limited to open-redirect phishing leverage. Combined with other issues (e.g., downstream SSO trust chains) it may contribute to account-takeover chains; on its own it is a Medium-severity open redirect. ##### Affected deployments Any application using Authlib as an OIDC provider that registers `OpenIDImplicitGrant` and/or `OpenIDHybridGrant` — i.e. anyone supporting the Implicit flow or the Hybrid flow (`response_type=code id_token`, etc.) — is affected. Clients of an Authlib-based OP are not directly affected; this is a server-side issue. Authorization servers that only register the plain `AuthorizationCodeGrant` (code flow, with or without PKCE and the `OpenIDCode` extension) are not affected by this specific variant: the code-flow grant validates `redirect_uri` before raising scope errors. If you were affected by the sibling issue fixed in `3be08468` (`UnsupportedResponseTypeError`), you should already be on `1.6.10` or later; this advisory is independent of that fix. ##### Suggested fix The attached `fix-oidc-open-redirect.patch` reorders each method to delegate to its super (or call `validate_code_authorization_request` for Hybrid) first, and then performs the `openid`-scope check with the validated `redirect_uri` variable. ```python ##### authlib/oidc/core/grants/implicit.py def validate_authorization_request(self): redirect_uri = super().validate_authorization_request() # runs client + redirect_uri validation if not is_openid_scope(self.request.payload.scope): raise InvalidScopeError( "Missing 'openid' scope", redirect_uri=redirect_uri, # validated redirect_fragment=True, ) try: validate_nonce(self.request, self.exists_nonce, required=True) except OAuth2Error as error: error.redirect_uri = redirect_uri error.redirect_fragment = True raise error return redirect_uri ``` An equivalent transform is applied to `OpenIDHybridGrant.validate_authorization_request`, invoking `validate_code_authorization_request` first and only then checking `is_openid_scope`. Alternatively, inline a `client = query_client(request.payload.client_id)` + `client.check_redirect_uri(request.payload.redirect_uri)` guard before populating `redirect_uri` on the error — the pattern used in `3be08468`. The patch also adds regression tests analogous to `test_unsupported_response_type_does_not_redirect` from commit `3be08468`, asserting `rv.status_code == 400` and `rv.headers.get("Location") is None` for an unregistered `redirect_uri` with a non-`openid` scope. ##### Workarounds No clean server-side workaround exists short of patching. Partial mitigations: - Unregister `OpenIDImplicitGrant` and `OpenIDHybridGrant` if the Implicit and Hybrid flows are not required. (RFC 9700 deprecates the Implicit flow and discourages Hybrid flows, so this is recommended anyway.) - Front the `/authorize` endpoint with a reverse proxy rule that rejects requests containing both a `redirect_uri` parameter and a `scope` that does not include `openid` when `response_type` matches the vulnerable set. This is fragile and not recommended as a primary control. ##### References - RFC 6749, §4.1.2.1 — Error Response (OAuth 2.0 authorization endpoint) - RFC 9700, §4.11 — Redirect URI validation - OpenID Connect Core 1.0, §3.2.2.6 / §3.3.2.6 — Authentication Error Response - Authlib commit [`3be08468`](https://github.com/authlib/authlib/commit/3be08468) — prior fix for the same class of issue in `UnsupportedResponseTypeError` (Authlib 1.6.10) - Authlib source (by symbol; verified in commit `5d2e603e`): - `OpenIDImplicitGrant.validate_authorization_request` — `authlib/oidc/core/grants/implicit.py` - `OpenIDHybridGrant.validate_authorization_request` — `authlib/oidc/core/grants/hybrid.py` - `OAuth2Error.__call__` — `authlib/oauth2/base.py` (renders errors with `redirect_uri` as HTTP 302) - `AuthorizationEndpointMixin.validate_authorization_redirect_uri` — `authlib/oauth2/rfc6749/grants/base.py` (the validation that is bypassed) #### Severity - CVSS Score: 6.1 / 10 (Medium) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N` #### References - [https://github.com/authlib/authlib/security/advisories/GHSA-r95x-qfjj-fjj2](https://github.com/authlib/authlib/security/advisories/GHSA-r95x-qfjj-fjj2) - [https://nvd.nist.gov/vuln/detail/CVE-2026-44681](https://nvd.nist.gov/vuln/detail/CVE-2026-44681) - [https://github.com/authlib/authlib](https://github.com/authlib/authlib) - [https://github.com/authlib/authlib/releases/tag/v1.6.12](https://github.com/authlib/authlib/releases/tag/v1.6.12) - [https://github.com/authlib/authlib/releases/tag/v1.7.1](https://github.com/authlib/authlib/releases/tag/v1.7.1) - [https://github.com/pypa/advisory-database/tree/main/vulns/authlib/PYSEC-2026-188.yaml](https://github.com/pypa/advisory-database/tree/main/vulns/authlib/PYSEC-2026-188.yaml) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-r95x-qfjj-fjj2) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### [CVE-2026-44681](https://nvd.nist.gov/vuln/detail/CVE-2026-44681) / [GHSA-r95x-qfjj-fjj2](https://github.com/advisories/GHSA-r95x-qfjj-fjj2) / PYSEC-2026-188 <details> <summary>More information</summary> #### Details Authlib is a Python library which builds OAuth and OpenID Connect servers. Prior to 1.6.12 and 1.7.1, an unauthenticated open redirect in Authlib's OpenIDImplicitGrant and OpenIDHybridGrant authorization endpoint lets a remote attacker cause the authorization server to issue an HTTP 302 to an attacker-chosen URL by submitting an authorization request that omits the openid scope. This vulnerability is fixed in 1.6.12 and 1.7.1. #### Severity - CVSS Score: 6.1 / 10 (Medium) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N` #### References - [https://github.com/authlib/authlib/security/advisories/GHSA-r95x-qfjj-fjj2](https://github.com/authlib/authlib/security/advisories/GHSA-r95x-qfjj-fjj2) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-188) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### Release Notes <details> <summary>authlib/authlib (authlib)</summary> ### [`v1.6.12`](https://github.com/authlib/authlib/releases/tag/v1.6.12) [Compare Source](https://github.com/authlib/authlib/compare/v1.6.11...1.6.12) - - Fix redirecting to unvalidated `redirect_uri` on `InvalidScopeError` in `OpenIDImplicitGrant` and `OpenIDHybridGrant`. **Full Changelog**: <https://github.com/authlib/authlib/compare/v1.6.11...v1.6.12> ### [`v1.6.11`](https://github.com/authlib/authlib/releases/tag/v1.6.11) [Compare Source](https://github.com/authlib/authlib/compare/v1.6.10...v1.6.11) **Full Changelog**: <https://github.com/authlib/authlib/compare/v1.6.10...v1.6.11> - Fix CSRF issue with starlette client ### [`v1.6.10`](https://github.com/authlib/authlib/releases/tag/v1.6.10) [Compare Source](https://github.com/authlib/authlib/compare/v1.6.9...v1.6.10) **Full Changelog**: <https://github.com/authlib/authlib/compare/v1.6.9...v1.6.10> - Fix redirecting to unvalidated `redirect_uri` on `UnsupportedResponseTypeError`. </details> --- ### Configuration 📅 **Schedule**: (in timezone Europe/Paris) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate CLI](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0NC40LjYiLCJ1cGRhdGVkSW5WZXIiOiI0NC40LjYiLCJ0YXJnZXRCcmFuY2giOiJtYWluIiwibGFiZWxzIjpbXX0=-->
eloi merged commit 724c6d00d4 into main 2026-08-01 13:45:47 +02:00
eloi deleted branch renovate/pypi-authlib-vulnerability 2026-08-01 13:47:52 +02:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
bug
Des choses qui ne fonctionnent pas comme prévu

  
documentation
En rapport avec la documentation

  
fonctionnalité
Nouvelles fonctionnalités ou améliorations

No labels
bug
documentation
fonctionnalité
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
yaal/escut!82
No description provided.