[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
oauthlib (changelog)	4.0.0 → 4.0.1

---

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

CVE-2026-49272 / GHSA-3jp2-3mrg-2vxc

More information

Details

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 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 and here.

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.

Severity

• CVSS Score: 8.5 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N

References

• https://github.com/oauthlib/oauthlib/security/advisories/GHSA-3jp2-3mrg-2vxc
• https://github.com/oauthlib/oauthlib/pull/954
• https://github.com/oauthlib/oauthlib/commit/77a5f1c8ce00da2b0b8c5f6e9cc129920085f114
• https://github.com/oauthlib/oauthlib/releases/tag/v4.0.1
• https://github.com/advisories/GHSA-3jp2-3mrg-2vxc

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Release Notes

oauthlib/oauthlib (oauthlib)

v4.0.1: 4.0.1

Compare Source

Security

• CVE-2026-49272 / GHSA-3jp2-3mrg-2vxc: The device code flow token endpoint did not validate the device_code parameter. A request with a known client_id and a bogus device_code could obtain a bearer token. DeviceCodeGrant.validate_token_request now calls DeviceCodeGrant.validate_device_code(), which rejects missing or unknown device codes (invalid_request / invalid_grant) and delegates the code's authorization status to the new RequestValidator.validate_device_code() hook, per RFC 8628 Section 3.5. (cherry-picked from #​954)

Upgrade note for device flow integrators

Custom RequestValidator implementations using the device flow must now implement validate_device_code(client_id, code, request). Return one of the DeviceCodeGrant.DEVICE_CODE_* statuses for known codes, or None for an unknown code. When returning AUTHORIZED, the validator must also populate request.user and request.scopes from the stored authorization.

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.