OAuthLib: Bearer token can be retrieved as long as client knows a valid client ID for device workflow
CVSS Skor
8.5
EPSS İhtimal
—
Risk Skoru
0.8
Yayın
2 sa önce
Resmî kaynaklarda yeterli kanıt bulunamadı. Bu sonuç “yama yok” anlamına gelmez.
Envanterimdeki Etkisi
Yalnızca hesabınıza eklediğiniz kişisel ürünler değerlendirilir; kurumsal envanter burada görünmez.
Oturum kontrol ediliyor…
Zafiyet Açıklaması
DayBreach AI Açıklaması
Kaynakla doğrulandıOkunan kaynak
1
Kaynak uyumu
Tam uyum
Kanıt güveni
%53
Kısa açıklama
OAuthLib içerisinde bulunan CVE-2026-49272 zaafiyeti, cihaz iş akışı sırasında geçersiz bir cihaz kodu kullanılsa bile geçerli bir client ID bilinmesi durumunda bearer token alınabilmesine olanak tanır.
RFC 8628 cihaz iş akışını kullanan uygulamalarda cihaz kodunun doğrulanmaması, kimlik doğrulama süreçlerinin atlanmasına ve yetkisiz token erişimine yol açabilir.
Ne yapılmalı?
- Satıcı danışma ve duyurularını takip edin
- İlgili güncellemeleri inceleyin
- İstek doğrulama mekanizmalarını gözden geçirin
Kaynaklar bazı teknik koşulları sınırlı ayrıntıyla sunuyor. Uygulama kararından önce aşağıdaki kanıt zincirini inceleyin.
Kanıt zinciri ve kaynaklar
OAuthLib cihaz iş akışında device_code parametresi doğrulanmamaktadır.
Geçerli bir client ID bilindiğinde sahte cihaz koduyla bearer token alınabilmektedir.
Kaynaklardaki teknik metni göster
### 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.
CVSS vektörü: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N
CWE: CWE-287
Açıklama kaynak kayıtlardan otomatik derlendi. Puanlar, aktif sömürü, yama ve exploit durumları doğrudan kaynaklardan gelir.
IMPACT — Etkilenen Ürünler ve Yazılımlar
Affected Products
The following products are affected by CVE-2026-49272 vulnerability. Even if our threat engine is aware of the exact versions of the products that are affected, the information is represented below.
| ID | VENDOR | PRODUCT | ACTION |
|---|---|---|---|
| 1 | pypi | oauthlib | İncele |
RED HAT CSAF/VEX — Ürün Etki Kontrolü
SCORING — CVSS Çoklu Kaynak Skoru
CVSS Scores
The Common Vulnerability Scoring System is a standardized framework for assessing the severity of vulnerabilities in software and systems. We collect and display CVSS scores from various sources for each CVE.
| SCORE | VERSION | SEVERITY | VECTOR | SOURCE |
|---|---|---|---|---|
| 8.5 | CVSS 3.x | — | Vektör yayımlanmadı | GitHub Advisory |
| 0.0 | CVSS 4.0 | — | Vektör yayımlanmadı | GitHub Advisory |
Yama ve İyileştirme Rehberi (Solution)
Solution & Remediation Advisory
İncelenen resmî kaynaklarda yama durumu doğrulanamadı. Bu sonuç “yama yok” anlamına gelmez.
Public exploit ve aktif sömürü durumu
Doğrulanmış exploit istihbaratı
Bu CVE için henüz doğrulanmış public PoC, exploit repository’si veya Metasploit modülü bulunamadı.
Zafiyet Dağılımı ve Saldırı Kalıpları (CWE & CAPEC)
CWE - Common Weakness Enumeration
While CVE identifies specific instances of vulnerabilities, CWE categorizes the common flaws or weaknesses that can lead to vulnerabilities. CVE-2026-49272 is associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification (CAPEC) stores attack patterns, which are descriptions of the common attributes and approaches employed by adversaries to exploit the CVE-2026-49272 weaknesses.
Saldırı Vektörü ve Erişilebilirlik Karakteristiği
Resmi Kaynaklar ve Danışma Bültenleri
İlgili Benzer Açıklar
Bu açığı API ile alın
Etkilenen ürünler, sürüm aralıkları, istismar durumu ve yama bilgisi tek istekte; ücretsiz anahtarla.
curl -H "x-api-key: $DAYBREACH_API_KEY" \ "https://api.daybreach.dev/api/v1/intel/cves/CVE-2026-49272"