<?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 09:52:17 +0000</lastBuildDate>
    <item>
      <title>BREW-ansible-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/brew-ansible-cve-2026-118669</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: ansible&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; Homebrew: ansible&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/brew-ansible-cve-2026-118669</guid>
    </item>
    <item>
      <title>fkie_cve-2026-118669</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-118669</link>
      <description>&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;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/fkie_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>
    <item>
      <title>msrc_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/msrc_cve-2026-118669</link>
      <description>msrc_CVE-2026-118669</description>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/msrc_cve-2026-118669</guid>
    </item>
    <item>
      <title>RHSA-2026:94802 — Red Hat Security Advisory: A Subscription Management tool for finding and reporting Red Hat product usage</title>
      <link>https://db.gcve.eu/vuln/rhsa-2026:94802</link>
      <description>&lt;p&gt;libcurl: libcurl: Security feature bypass due to improper mTLS connection reuse python: python: Arbitrary file deletion via race condition during temporary directory cleanup python: Use-after-free of a server-side SSLContext when sni_callback switches contexts python: python: Certificate verification bypass via missing server_hostname validation in SSLContext.wrap_bio() xz: XZ Utils: Denial of Service via buffer overflow in index decoding openssh: OpenSSH: SFTP security bypass due to command-line argument parsing flaw openssh: OpenSSH: Undocumented GSSAPIStrictAcceptorCheck behavior impacts security in Windows Active Directory openssh: OpenSSH: Denial of Service via excessive GSSAPI authentication attempts expat: expat: Information disclosure via heap buffer over-read in XML_ParseBuffer libX11: libX11: Heap-based buffer overflow via malicious X server urllib3: urllib3: Traffic interception via HTTPS proxy TLS configuration override urllib3: urllib3: Denial of Service via unbounded memory allocation in chunk parser expat: expat: Denial of Service via integer overflow in expat_realloc brotli: Out-of-Bounds Write in Google Brotli Decoder djangorestframework: djangorestframework: Denial of Service via improper charset handling in JSON parser djangorestframework: djangorestframework: Unauthorized access via improper token revocation in TokenProxy djangorestframework: djangorestframework: Denial of Service via unbounded Accept header parsing ca-certificates: Distrust eMudhra inter…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;libcurl: libcurl: Security feature bypass due to improper mTLS connection reuse python: python: Arbitrary file deletion via race condition during temporary directory cleanup python: Use-after-free of a server-side SSLContext when sni_callback switches contexts python: python: Certificate verification bypass via missing server_hostname validation in SSLContext.wrap_bio() xz: XZ Utils: Denial of Service via buffer overflow in index decoding openssh: OpenSSH: SFTP security bypass due to command-line argument parsing flaw openssh: OpenSSH: Undocumented GSSAPIStrictAcceptorCheck behavior impacts security in Windows Active Directory openssh: OpenSSH: Denial of Service via excessive GSSAPI authentication attempts expat: expat: Information disclosure via heap buffer over-read in XML_ParseBuffer libX11: libX11: Heap-based buffer overflow via malicious X server urllib3: urllib3: Traffic interception via HTTPS proxy TLS configuration override urllib3: urllib3: Denial of Service via unbounded memory allocation in chunk parser expat: expat: Denial of Service via integer overflow in expat_realloc brotli: Out-of-Bounds Write in Google Brotli Decoder djangorestframework: djangorestframework: Denial of Service via improper charset handling in JSON parser djangorestframework: djangorestframework: Unauthorized access via improper token revocation in TokenProxy djangorestframework: djangorestframework: Denial of Service via unbounded Accept header parsing ca-certificates: Distrust eMudhra inter…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/rhsa-2026:94802</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-118669</title>
      <link>https://db.gcve.eu/vuln/ubuntu-cve-2026-118669</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: python-oauthlib, Ubuntu:18.04:LTS: python-oauthlib, Ubuntu:20.04:LTS: python-oauthlib, Ubuntu:22.04:LTS: python-oauthlib, Ubuntu:24.04:LTS: python-oauthlib, Ubuntu:26.10: python-oauthlib, Ubuntu:26.04:LTS: python-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; Ubuntu:16.04:LTS: python-oauthlib, Ubuntu:18.04:LTS: python-oauthlib, Ubuntu:20.04:LTS: python-oauthlib, Ubuntu:22.04:LTS: python-oauthlib, Ubuntu:24.04:LTS: python-oauthlib, Ubuntu:26.10: python-oauthlib, Ubuntu:26.04:LTS: python-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/ubuntu-cve-2026-118669</guid>
    </item>
  </channel>
</rss>
