<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-31T22:14:36.064946+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/cve-2026-116672</id>
    <title>CVE-2026-116672 — Authlib RFC 7592 examples omit registration-access-token client binding</title>
    <updated>2026-10-31T22:14:36.066284+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> authlib</p>
<p>Authlib is a Python library which builds OAuth and OpenID Connect servers. From 0.15 until 1.9.1, the documented ClientConfigurationEndpoint.authenticate_client and ClientConfigurationEndpoint.check_permission reference implementations look up a target client from request-controlled client_id data and check only whether that target is editable, without verifying that request.credential belongs to the target client. Deployments following both examples can allow a client holding any valid registration access token to read, modify, or delete another client's registration. Changing redirect_uris can enable authorization code or token interception, while deleting registrations can deny service to affected clients. This issue is fixed in version 1.9.1.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/cve-2026-116672"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-c73q-w75p-j82v</id>
    <title>GHSA-c73q-w75p-j82v — Authlib RFC 7592 examples omit registration-access-token client binding</title>
    <updated>2026-10-31T22:14:36.066351+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: Authlib</p>
<p>## Description</p>
<p>### Summary</p>
<p>RFC 7592 (OAuth 2.0 Dynamic Client Registration Management Protocol) lets a previously registered client read, update, or delete its own registration, authenticated by a `registration_access_token` issued specifically to that client at registration time. The entire security model of this protocol depends on the server verifying that the token presented in the request actually belongs to the client identified in the request, not merely that the token is valid for some client.</p>
<p>Authlib's `ClientConfigurationEndpoint` implements the control flow correctly in structure, calling `authenticate_token`, then `authenticate_client`, then `check_permission`, and treats all three as abstract methods that "Developers MUST implement in subclass." The problem is that the documented example implementations for these methods, taken together exactly as written, never perform the one check that matters: binding the authenticated token to the specific client being accessed. A developer who implements these methods by following the provided examples ends up with a complete authorization bypass on this endpoint.</p>
<p>### Details</p>
<p>`authenticate_client`'s documented example (`authlib/oauth2/rfc7592/endpoint.py`):</p>
<p>```python
def authenticate_client(self, request):
    """Read a client from the request payload.
    Developers MUST implement this method in subclass::</p>
<p>def authenticate_client(self, request):
            client_id = request.payload.data.get("client_id")…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-c73q-w75p-j82v"/>
  </entry>
</feed>
