<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sat, 07 Nov 2026 15:03:39 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-118669 — OAuthLib: Token grants can use attacker-supplied client_id for authorization after authenticating a different client</title>
      <link>https://db.gcve.eu/vuln/cve-2026-118669</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; oauthlib&lt;/p&gt;
&lt;p&gt;OAuthLib is an implementation of the OAuth request-signing logic for Python 3.6+. Prior to 4.0.0, the client_credentials and Resource Owner Password Credentials token grant handlers can authenticate request.client as one confidential client while retaining an attacker-supplied request.client_id for validate_grant_type and validate_scopes. A lower-privilege authenticated client can therefore cause grant and scope authorization to use another client&amp;#39;s identity when an application validator relies on the documented client_id argument, potentially issuing tokens with unauthorized grants or scopes. Validators that authorize exclusively from request.client may not be affected. This issue is fixed in version 4.0.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; oauthlib&lt;/p&gt;
&lt;p&gt;OAuthLib is an implementation of the OAuth request-signing logic for Python 3.6+. Prior to 4.0.0, the client_credentials and Resource Owner Password Credentials token grant handlers can authenticate request.client as one confidential client while retaining an attacker-supplied request.client_id for validate_grant_type and validate_scopes. A lower-privilege authenticated client can therefore cause grant and scope authorization to use another client&amp;#39;s identity when an application validator relies on the documented client_id argument, potentially issuing tokens with unauthorized grants or scopes. Validators that authorize exclusively from request.client may not be affected. This issue is fixed in version 4.0.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-118669</guid>
    </item>
    <item>
      <title>GHSA-7984-qgvg-3j9c — OAuthLib: Token grants can use attacker-supplied client_id for authorization after authenticating a different client</title>
      <link>https://db.gcve.eu/vuln/ghsa-7984-qgvg-3j9c</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: oauthlib&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;OAuthlib&amp;#39;s token grant handlers can authenticate one client while authorizing the grant type and requested scopes using a different, attacker-supplied `client_id` from the request body.&lt;/p&gt;
&lt;p&gt;In affected token grant flows, `authenticate_client(request)` sets `request.client` to the authenticated client object, but OAuthlib does not require `request.client_id` to match `request.client.client_id`. If the request body already contains `client_id=...`, OAuthlib keeps that value and passes it to `validate_grant_type()` and `validate_scopes()`.&lt;/p&gt;
&lt;p&gt;As a result, an authenticated low-privilege confidential client can authenticate as itself, submit another client&amp;#39;s `client_id` in the token request body, and cause grant and scope validation to run under that other client identity.&lt;/p&gt;
&lt;p&gt;## Affected Surface&lt;/p&gt;
&lt;p&gt;The affected public surface is the OAuth2 token endpoint handling for:&lt;/p&gt;
&lt;p&gt;- `client_credentials`
- `password` / Resource Owner Password Credentials&lt;/p&gt;
&lt;p&gt;The issue is relevant to OAuthlib provider deployments where:&lt;/p&gt;
&lt;p&gt;- the attacker has credentials for one valid lower-privilege confidential client;
- another client has broader grants or scopes;
- the application validator uses the `client_id` argument passed by OAuthlib in `validate_grant_type()` or `validate_scopes()`, as the `RequestValidator` API is designed to support.&lt;/p&gt;
&lt;p&gt;Deployments whose validators ignore the `client_id` argument and authorize only from `request.client` may not be affected.&lt;/p&gt;
&lt;p&gt;## Details&lt;/p&gt;
&lt;p&gt;`Request` parses query and body p…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: oauthlib&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;OAuthlib&amp;#39;s token grant handlers can authenticate one client while authorizing the grant type and requested scopes using a different, attacker-supplied `client_id` from the request body.&lt;/p&gt;
&lt;p&gt;In affected token grant flows, `authenticate_client(request)` sets `request.client` to the authenticated client object, but OAuthlib does not require `request.client_id` to match `request.client.client_id`. If the request body already contains `client_id=...`, OAuthlib keeps that value and passes it to `validate_grant_type()` and `validate_scopes()`.&lt;/p&gt;
&lt;p&gt;As a result, an authenticated low-privilege confidential client can authenticate as itself, submit another client&amp;#39;s `client_id` in the token request body, and cause grant and scope validation to run under that other client identity.&lt;/p&gt;
&lt;p&gt;## Affected Surface&lt;/p&gt;
&lt;p&gt;The affected public surface is the OAuth2 token endpoint handling for:&lt;/p&gt;
&lt;p&gt;- `client_credentials`
- `password` / Resource Owner Password Credentials&lt;/p&gt;
&lt;p&gt;The issue is relevant to OAuthlib provider deployments where:&lt;/p&gt;
&lt;p&gt;- the attacker has credentials for one valid lower-privilege confidential client;
- another client has broader grants or scopes;
- the application validator uses the `client_id` argument passed by OAuthlib in `validate_grant_type()` or `validate_scopes()`, as the `RequestValidator` API is designed to support.&lt;/p&gt;
&lt;p&gt;Deployments whose validators ignore the `client_id` argument and authorize only from `request.client` may not be affected.&lt;/p&gt;
&lt;p&gt;## Details&lt;/p&gt;
&lt;p&gt;`Request` parses query and body p…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-7984-qgvg-3j9c</guid>
    </item>
  </channel>
</rss>
