https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 11 Nov 2026 22:38:48 +0000 https://db.gcve.eu/vuln/brew-ansible-cve-2026-49272 <p><strong>Affected:</strong> Homebrew: ansible</p> <p>### Summary A call to the token endpoint with a grant type of `&#34;urn:ietf:params:oauth:grant-type:device_code&#34;` and a bogus `device_code` is able to get a bearer token as long as they know a valid client ID enabled for the device workflow.</p> <p>### Details</p> <p>[Section 3.4 of the RFC 8628 spec](https://datatracker.ietf.org/doc/html/rfc8628#section-3.4) says that the token endpoint should take in `device_code` as a required parameter.`DeviceCodeGrant.validate_token_request` does not perform any validation of `device_code`. `DeviceCodeGrant.validate_token_request` should be validating that `device_code` was passed in as a parameter and that it is valid, similar to how `AuthorizationCodeGrant.validate_token_request` does the checks [here](https://github.com/oauthlib/oauthlib/blob/a015b446622f2b925517501fe484c10eff7a83c0/oauthlib/oauth2/rfc6749/grant_types/authorization_code.py#L446) and [here](https://github.com/oauthlib/oauthlib/blob/a015b446622f2b925517501fe484c10eff7a83c0/oauthlib/oauth2/rfc6749/grant_types/authorization_code.py#L483).</p> <p>I would like to propose a new method be added to `RequestValidator` called `validate_device_code` that is similar to the `validate_code` method and is called inside of `DeviceCodeGrant.validate_token_request`.</p> <p>### PoC Create an implementation of `RequestValidation.authenticate_client` that returns `True` if the client&#39;s `client_type` is `&#34;public&#34;`. You would find yourself in this scenario because there&#39;s another issue with `DeviceCodeGrant.validate_…</p> <p><strong>Affected:</strong> Homebrew: ansible</p> <p>### Summary A call to the token endpoint with a grant type of `&#34;urn:ietf:params:oauth:grant-type:device_code&#34;` and a bogus `device_code` is able to get a bearer token as long as they know a valid client ID enabled for the device workflow.</p> <p>### Details</p> <p>[Section 3.4 of the RFC 8628 spec](https://datatracker.ietf.org/doc/html/rfc8628#section-3.4) says that the token endpoint should take in `device_code` as a required parameter.`DeviceCodeGrant.validate_token_request` does not perform any validation of `device_code`. `DeviceCodeGrant.validate_token_request` should be validating that `device_code` was passed in as a parameter and that it is valid, similar to how `AuthorizationCodeGrant.validate_token_request` does the checks [here](https://github.com/oauthlib/oauthlib/blob/a015b446622f2b925517501fe484c10eff7a83c0/oauthlib/oauth2/rfc6749/grant_types/authorization_code.py#L446) and [here](https://github.com/oauthlib/oauthlib/blob/a015b446622f2b925517501fe484c10eff7a83c0/oauthlib/oauth2/rfc6749/grant_types/authorization_code.py#L483).</p> <p>I would like to propose a new method be added to `RequestValidator` called `validate_device_code` that is similar to the `validate_code` method and is called inside of `DeviceCodeGrant.validate_token_request`.</p> <p>### PoC Create an implementation of `RequestValidation.authenticate_client` that returns `True` if the client&#39;s `client_type` is `&#34;public&#34;`. You would find yourself in this scenario because there&#39;s another issue with `DeviceCodeGrant.validate_…</p> https://db.gcve.eu/vuln/brew-ansible-cve-2026-49272 https://db.gcve.eu/vuln/cleanstart-2026-tp84091 <p><strong>Affected:</strong> CleanStart: airflow-3</p> <p>Security vulnerability affects the airflow-3 package. This issue is resolved in later releases. See references for vulnerability details.</p> <p><strong>Affected:</strong> CleanStart: airflow-3</p> <p>Security vulnerability affects the airflow-3 package. This issue is resolved in later releases. See references for vulnerability details.</p> https://db.gcve.eu/vuln/cleanstart-2026-tp84091 https://db.gcve.eu/vuln/fkie_cve-2026-49272 <p>OAuthLib is an implementation of the OAuth request-signing logic for Python 3.6+. From 3.3.0 until 4.0.1, OAuthLib&#39;s RFC 8628 device workflow does not require DeviceCodeGrant.validate_token_request to check that the device_code parameter is present and valid. A caller whose client request is accepted by the configured validator and who knows a valid client ID enabled for the device workflow can submit a missing or bogus device code to the token endpoint and obtain a bearer token without completing device authorization. This issue is fixed in version 4.0.1.</p> <p>OAuthLib is an implementation of the OAuth request-signing logic for Python 3.6+. From 3.3.0 until 4.0.1, OAuthLib&#39;s RFC 8628 device workflow does not require DeviceCodeGrant.validate_token_request to check that the device_code parameter is present and valid. A caller whose client request is accepted by the configured validator and who knows a valid client ID enabled for the device workflow can submit a missing or bogus device code to the token endpoint and obtain a bearer token without completing device authorization. This issue is fixed in version 4.0.1.</p> https://db.gcve.eu/vuln/fkie_cve-2026-49272 https://db.gcve.eu/vuln/ghsa-3jp2-3mrg-2vxc <p><strong>Affected:</strong> PyPI: oauthlib</p> <p>### Summary A call to the token endpoint with a grant type of `&#34;urn:ietf:params:oauth:grant-type:device_code&#34;` and a bogus `device_code` is able to get a bearer token as long as they know a valid client ID enabled for the device workflow.</p> <p>### Details</p> <p>[Section 3.4 of the RFC 8628 spec](https://datatracker.ietf.org/doc/html/rfc8628#section-3.4) says that the token endpoint should take in `device_code` as a required parameter.`DeviceCodeGrant.validate_token_request` does not perform any validation of `device_code`. `DeviceCodeGrant.validate_token_request` should be validating that `device_code` was passed in as a parameter and that it is valid, similar to how `AuthorizationCodeGrant.validate_token_request` does the checks [here](https://github.com/oauthlib/oauthlib/blob/a015b446622f2b925517501fe484c10eff7a83c0/oauthlib/oauth2/rfc6749/grant_types/authorization_code.py#L446) and [here](https://github.com/oauthlib/oauthlib/blob/a015b446622f2b925517501fe484c10eff7a83c0/oauthlib/oauth2/rfc6749/grant_types/authorization_code.py#L483).</p> <p>I would like to propose a new method be added to `RequestValidator` called `validate_device_code` that is similar to the `validate_code` method and is called inside of `DeviceCodeGrant.validate_token_request`.</p> <p>### PoC Create an implementation of `RequestValidation.authenticate_client` that returns `True` if the client&#39;s `client_type` is `&#34;public&#34;`. You would find yourself in this scenario because there&#39;s another issue with `DeviceCodeGrant.validate_…</p> <p><strong>Affected:</strong> PyPI: oauthlib</p> <p>### Summary A call to the token endpoint with a grant type of `&#34;urn:ietf:params:oauth:grant-type:device_code&#34;` and a bogus `device_code` is able to get a bearer token as long as they know a valid client ID enabled for the device workflow.</p> <p>### Details</p> <p>[Section 3.4 of the RFC 8628 spec](https://datatracker.ietf.org/doc/html/rfc8628#section-3.4) says that the token endpoint should take in `device_code` as a required parameter.`DeviceCodeGrant.validate_token_request` does not perform any validation of `device_code`. `DeviceCodeGrant.validate_token_request` should be validating that `device_code` was passed in as a parameter and that it is valid, similar to how `AuthorizationCodeGrant.validate_token_request` does the checks [here](https://github.com/oauthlib/oauthlib/blob/a015b446622f2b925517501fe484c10eff7a83c0/oauthlib/oauth2/rfc6749/grant_types/authorization_code.py#L446) and [here](https://github.com/oauthlib/oauthlib/blob/a015b446622f2b925517501fe484c10eff7a83c0/oauthlib/oauth2/rfc6749/grant_types/authorization_code.py#L483).</p> <p>I would like to propose a new method be added to `RequestValidator` called `validate_device_code` that is similar to the `validate_code` method and is called inside of `DeviceCodeGrant.validate_token_request`.</p> <p>### PoC Create an implementation of `RequestValidation.authenticate_client` that returns `True` if the client&#39;s `client_type` is `&#34;public&#34;`. You would find yourself in this scenario because there&#39;s another issue with `DeviceCodeGrant.validate_…</p> https://db.gcve.eu/vuln/ghsa-3jp2-3mrg-2vxc https://db.gcve.eu/vuln/opensuse-su-2026:12520-1 <p>python313-oauthlib-4.0.1-1.1 on GA media</p> <p>python313-oauthlib-4.0.1-1.1 on GA media</p> https://db.gcve.eu/vuln/opensuse-su-2026:12520-1 https://db.gcve.eu/vuln/ubuntu-cve-2026-49272 <p><strong>Affected:</strong> 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</p> <p>OAuthLib is an implementation of the OAuth request-signing logic for Python 3.6+. From 3.3.0 until 4.0.1, OAuthLib&#39;s RFC 8628 device workflow does not require DeviceCodeGrant.validate_token_request to check that the device_code parameter is present and valid. A caller whose client request is accepted by the configured validator and who knows a valid client ID enabled for the device workflow can submit a missing or bogus device code to the token endpoint and obtain a bearer token without completing device authorization. This issue is fixed in version 4.0.1.</p> <p><strong>Affected:</strong> 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</p> <p>OAuthLib is an implementation of the OAuth request-signing logic for Python 3.6+. From 3.3.0 until 4.0.1, OAuthLib&#39;s RFC 8628 device workflow does not require DeviceCodeGrant.validate_token_request to check that the device_code parameter is present and valid. A caller whose client request is accepted by the configured validator and who knows a valid client ID enabled for the device workflow can submit a missing or bogus device code to the token endpoint and obtain a bearer token without completing device authorization. This issue is fixed in version 4.0.1.</p> https://db.gcve.eu/vuln/ubuntu-cve-2026-49272