CVE-2018-1000211
Description
Doorkeeper version 4.2.0 and later contains a Incorrect Access Control vulnerability in Token revocation API's authorized method that can result in Access tokens are not revoked for public OAuth apps, leaking access until expiry.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Doorkeeper 4.2.0+ has incorrect access control in token revocation, preventing revocation for public OAuth apps and causing prolonged token validity.
Vulnerability
Doorkeeper versions 4.2.0 and later contain an Incorrect Access Control vulnerability in the token revocation API's authorized? method [1]. This affects public OAuth clients that use implicit grant flows, where the access token record includes the application ID, causing the revocation controller to incorrectly treat them as confidential clients [4]. Consequently, the revocation endpoint enforces client authentication, which public apps cannot provide, and revocation fails [2]. As a result, access tokens for public apps cannot be revoked and remain valid until their natural expiration [1].
Exploitation
An attacker with network access to the Doorkeeper token revocation endpoint can attempt to revoke any valid access token from a public OAuth app. No additional authentication is required beyond the token itself. However, due to the bug, the revocation request fails silently or returns an error, and the token remains active [2]. This can be exploited to maintain persistent access if an attacker has obtained such a token (e.g., through interception or storage compromise) [4].
Impact
The primary impact is that access tokens for public OAuth clients are effectively non-revocable, violating the OAuth 2.0 security model [1]. This prolongs the window of opportunity for attackers who have stolen such tokens, leading to unauthorized access to protected resources (confidentiality breach) and potential data manipulation (integrity impact) [2]. The availability of resource access may also be compromised if token revocation is relied upon for access control.
Mitigation
The fix is to upgrade to a patched version of Doorkeeper (e.g., 4.2.6 or later, as referenced in the security release associated with PR #1119) [2]. After upgrading, run rails generate doorkeeper:add_client_confidentiality to add a confidential column to OAuth applications, and set confidential to false for apps using public grant flows (e.g., implicit) [2]. No workarounds exist; the vulnerability is inherent in the authorization logic. Users should apply the migration and update application settings as instructed.
AI Insight generated on May 22, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected packages
Versions sourced from the GitHub Security Advisory.
| Package | Affected versions | Patched versions |
|---|---|---|
doorkeeperRubyGems | >= 4.2.0, < 4.4.0 | 4.4.0 |
Affected products
1Patches
0No patches discovered yet.
Vulnerability mechanics
AI mechanics synthesis has not run for this CVE yet.
References
4- github.com/advisories/GHSA-694m-jhr9-pf77ghsaADVISORY
- nvd.nist.gov/vuln/detail/CVE-2018-1000211ghsaADVISORY
- github.com/doorkeeper-gem/doorkeeper/issues/891ghsax_refsource_CONFIRMWEB
- github.com/doorkeeper-gem/doorkeeper/pull/1119ghsax_refsource_CONFIRMWEB
News mentions
0No linked articles in our index yet.