https://db.gcve.eu/rss/recent/all/10 Most recent entries from all 2026-11-11T23:09:38.879383+00:00 Vulnerability-Lookup info@gcve.eu python-feedgen Contains only the most 10 recent entries. https://db.gcve.eu/vuln/brew-ansible-cve-2026-49272 BREW-ansible-CVE-2026-49272 — OAuthLib: Bearer token can be retrieved as long as client knows a valid client ID for device workflow 2026-11-11T23:09:38.896598+00:00

Affected: Homebrew: ansible

### Summary A call to the token endpoint with a grant type of `"urn:ietf:params:oauth:grant-type:device_code"` 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.

### Details

[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).

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`.

### PoC Create an implementation of `RequestValidation.authenticate_client` that returns `True` if the client's `client_type` is `"public"`. You would find yourself in this scenario because there's another issue with `DeviceCodeGrant.validate_…

 https://db.gcve.eu/vuln/cleanstart-2026-tp84091 CLEANSTART-2026-TP84091 — Security fix for CVE-2026-49272 applied in: airflow-3 3.3.2-r1 2026-11-11T23:09:38.896709+00:00

Affected: CleanStart: airflow-3

Security vulnerability affects the airflow-3 package. This issue is resolved in later releases. See references for vulnerability details.

 https://db.gcve.eu/vuln/fkie_cve-2026-49272 fkie_cve-2026-49272 2026-11-11T23:09:38.896734+00:00

OAuthLib is an implementation of the OAuth request-signing logic for Python 3.6+. From 3.3.0 until 4.0.1, OAuthLib'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.

 https://db.gcve.eu/vuln/ghsa-3jp2-3mrg-2vxc GHSA-3jp2-3mrg-2vxc — OAuthLib: Bearer token can be retrieved as long as client knows a valid client ID for device workflow 2026-11-11T23:09:38.896772+00:00

Affected: PyPI: oauthlib

### Summary A call to the token endpoint with a grant type of `"urn:ietf:params:oauth:grant-type:device_code"` 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.

### Details

[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).

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`.

### PoC Create an implementation of `RequestValidation.authenticate_client` that returns `True` if the client's `client_type` is `"public"`. You would find yourself in this scenario because there's another issue with `DeviceCodeGrant.validate_…

 https://db.gcve.eu/vuln/opensuse-su-2026:12520-1 openSUSE-SU-2026:12520-1 — python313-oauthlib-4.0.1-1.1 on GA media 2026-11-11T23:09:38.896807+00:00

python313-oauthlib-4.0.1-1.1 on GA media

 https://db.gcve.eu/vuln/ubuntu-cve-2026-49272 UBUNTU-CVE-2026-49272 2026-11-11T23:09:38.896829+00:00

Affected: 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

OAuthLib is an implementation of the OAuth request-signing logic for Python 3.6+. From 3.3.0 until 4.0.1, OAuthLib'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.