---
id: "CVE-2026-49272"
kind: "vulnerability"
aliases: ["CVE-2026-49272", "GHSA-3jp2-3mrg-2vxc"]
title: "OAuthLib: Bearer token can be retrieved as long as client knows a valid client ID for device workflow"
severity: "high"
cvss: 8.5
epss: null
exploited: false
status: "open"
category: "package"
products: [{"name": "oauthlib", "fixed": ["4.0.0"], "affected": ">= 3.3.0, < 4.0.0", "ecosystem": "pypi"}]
ecosystems: ["pypi"]
tags: ["cwe-287", "oauth", "oauthlib", "package", "python", "self-hosted"]
not_affected_if: ["device-code-grant-disabled", "oauthlib-4.0.0-or-later", "oauthlib-below-3.3.0"]
published_at: "2026-10-27T13:30:17+00:00"
first_seen_at: "2026-10-27T13:31:05+00:00"
updated_at: "2026-10-27T13:32:11+00:00"
sources: [{"source": "ghsa", "url": "https://github.com/advisories/GHSA-3jp2-3mrg-2vxc", "first_seen_at": "2026-10-27T13:31:05+00:00"}]
---

# OAuthLib: Bearer token can be retrieved as long as client knows a valid client ID for device workflow

OAuthLib's RFC 8628 device-code grant does not check the device_code parameter at the token endpoint. An attacker who knows a client ID enabled for the device workflow can request a bearer token without a valid device code.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- pypi:oauthlib affected >= 3.3.0, < 4.0.0 fixed 4.0.0

## How to check

- Check the installed version with `pip show oauthlib` and look for a version from `3.3.0` up to but not including `4.0.0`.
- Search the codebase for `DeviceCodeGrant` or `device_code` to see whether the device-code grant is enabled on a token endpoint.

## Fix

- Upgrade `oauthlib` to `4.0.0` or later.
- Until upgraded, disable the device-code grant type on token endpoints if it is not in use.

## Timeline

- 2026-10-27T13:31:05+00:00 ghsa https://github.com/advisories/GHSA-3jp2-3mrg-2vxc

## From the sources

### 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_token_request` where it doesn't properly handle public clients (see https://github.com/oauthlib/oauthlib/issues/919).

Create a client that has a `client_type` of `"public"` and set it's `grant_type` to `"urn:ietf:params:oauth:grant-type:device_code"`.

With this implementation of `RequestValidation.authenticate_client` done, use that validator for your token endpoint. Call the token endpoint with a body of 
```
{
  "client_id": <ID of the public client you made>,
  "grant_type": "urn:ietf:params:oauth:grant-type:device_code",
  "device_code": <anything you want since it's not validated>
}
```

You now have a bearer token for the client without a valid `device_code`.


### Impact
Anyone using the RFC 8628 device workflow in oauthlib that doesn't realize the `device_code` parameter is not being validated.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_