Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
OAuth RFC 8252 says https://www.rfc-editor.org/rfc/rfc8252#section-8.6 the authorization server SHOULD NOT process authorization requests automatically without user consent or interaction, except when the identity of the client can be assured. This includes the case where the user has previously approved an authorization request for a given client id But Doorkeeper automatically processes authorization requests without user consent for public clients that have been previously approved. Public clients are inherently vulnerable to impersonation, their identity cannot be assured. Issue https://github.com/doorkeeper-gem/doorkeeper/issues/1589 Fix https://github.com/doorkeeper-gem/doorkeeper/pull/1646
Recommended action: Upgrade to 5.6.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Information disclosure vulnerability. Allows an attacker to see all Doorkeeper::Application model attribute values (including secrets) using authorized applications controller if it's enabled (GET /oauth/authorizedapplications.json). Patches These versions have the fix: 5.0.3 5.1.1 5.2.5 5.3.2 Workarounds Patch Doorkeeper::Application model #asjson(options = {}) method and define only those attributes you want to expose. Additional recommended hardening is to enable application secrets hashing (guide), available since Doorkeeper 5.1. This would render the exposed secret useless. References - Commit with fix: https://github.com/doorkeeper-gem/doorkeeper/commit/25d038022c2fcad45af5b73f9d003cf38ff491f6 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10187
Recommended action: Upgrade to 5.3.2, 5.2.5, 5.1.1 or 5.0.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Cross-site request forgery (CSRF) vulnerability in doorkeeper before 1.4.1 allows remote attackers to hijack the authentication of unspecified victims for requests that read a user OAuth authorization code via unknown vectors.
Recommended action: Upgrade to 1.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 4.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Doorkeeper version 2.1.0 through 4.2.5 contains a Cross Site Scripting (XSS) vulnerability in web view's OAuth app form, user authorization prompt web view that can result in Stored XSS on the OAuth Client's name will cause users interacting with it will execute payload. This attack appear to be exploitable via The victim must be tricked to click an opaque link to the web view that runs the XSS payload. A malicious version virtually indistinguishable from a normal link. This vulnerability appears to have been fixed in 4.2.6, 4.3.0.
Recommended action: Upgrade to 4.2.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Doorkeeper gem before 4.2.0 for Ruby might allow remote attackers to conduct replay attacks or revoke arbitrary tokens by leveraging failure to implement the OAuth 2.0 Token Revocation specification.
Recommended action: Upgrade to 4.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.