CVE-2015-9284

What it actually does

The flaw is a cross-site request forgery weakness in the OmniAuth request phase when OmniAuth 1.9.1 and earlier is used with Ruby on Rails. If an application allows authentication or account-linking flows to be initiated with an unprotected request, an attacker can cause a logged-in user’s browser to start an OAuth flow without the user intending to do so. In account-linking scenarios, this can bind an attacker-controlled external identity provider account to the victim’s existing application account, allowing the attacker to later authenticate through that linked identity and access the victim’s account. The primary impact is account takeover through unintended identity association, with potential confidentiality, integrity, and availability consequences for the affected account.

Why it matters to the business

Successful exploitation can let an attacker take over user accounts by silently linking their own third-party login identity to a victim’s account. This can lead to unauthorized access to personal data, transactions, administrative functions, or business workflows available to the compromised user. Although this issue is old, is not currently listed in CISA KEV, has no known ransomware association, and has a relatively low EPSS score, the CVSS severity is high because exploitation can result in full account compromise where vulnerable account-linking flows exist.

How an attack unfolds

An attacker first identifies a Rails application using a vulnerable OmniAuth integration where the authentication or account-linking request phase can be initiated without effective CSRF protection, commonly through a provider path such as /auth/<provider>. The attacker authenticates to the same identity provider using an account they control, prepares a crafted link or page that triggers the target application’s OmniAuth request phase for that provider, and causes a victim who is already logged in to the target application to visit it. The victim’s browser sends the request with the victim’s application session cookies, causing the target application to treat the OAuth flow as if the victim intentionally started it. If the callback completes using the attacker-controlled provider identity, the application may attach that external identity to the victim’s local account. The attacker can then sign in through the linked provider identity and gain access as the victim.

How to fix it

Upgrade OmniAuth and related Rails integration to a version/configuration that protects the request phase from CSRF. Prefer OmniAuth 2.x or later, which changes the default request method behavior and is designed to require POST for the request phase. For Rails applications that must remain on OmniAuth 1.x, add and correctly configure the omniauth-rails_csrf_protection gem and ensure Rails CSRF verification is enforced for OmniAuth request endpoints. Disable GET-based request phase initiation by configuring OmniAuth to allow only POST requests, for example by setting OmniAuth.config.allowed_request_methods = [:post], and update views/forms so login and account-linking buttons submit POST requests with valid authenticity tokens. Review all account-linking code to ensure an external identity cannot be attached to an existing account without an explicit user action and valid CSRF protection. Because no fixed version was provided in the input, remediation should be validated against the currently maintained OmniAuth and provider gem documentation used by the application.

How to confirm the fix worked

Confirm the deployed dependency tree no longer includes OmniAuth 1.9.1 or earlier without compensating Rails CSRF protection. Verify that OmniAuth request phase routes reject GET requests and accept only POST requests with a valid Rails authenticity token. Test authentication and account-linking flows from a logged-in session using a request without a CSRF token and confirm the application returns a CSRF failure or does not initiate linking. Review application routes and middleware configuration to ensure OmniAuth request endpoints are not exempted from CSRF checks. Validate that account-linking events require a deliberate user action and produce visible user feedback such as an audit event, notification, or linked-account confirmation.

Typical attack path

1. Identify a Rails application using OmniAuth 1.9.1 or earlier or a configuration that allows unprotected OmniAuth request initiation.
2. Find an authentication or account-linking route such as /auth/<provider> that can be triggered without a valid Rails CSRF token.
3. Create or use an attacker-controlled account at the supported external identity provider.
4. Send the victim a crafted link, embed a request in a web page, or otherwise cause the victim’s authenticated browser to initiate the vulnerable OmniAuth request phase.
5. Complete or drive the OAuth callback so the attacker-controlled provider identity is associated with the victim’s existing application account.
6. Authenticate to the application using the attacker-controlled provider identity and access the victim’s account.

How to detect it

To determine whether exploitation may have already occurred, review Rails application logs, reverse proxy logs, identity/account audit logs, and database-backed account-linking audit trails if available. Focus on OmniAuth request-phase endpoints, commonly /auth/<provider>, that were accessed with GET requests, missing or external referrers, or immediately before a new external identity was linked to an already logged-in account. Look for account-linking events where the linked provider identity has a different email address, subject identifier, or profile metadata than the existing account owner, especially when the event was not accompanied by an intentional user interface action. Correlate suspicious /auth/<provider> requests with OAuth callback requests, session identifiers, source IPs, user agents, and subsequent successful logins through the newly linked provider. In Rails logs, also look for CSRF warnings around OmniAuth routes, unexpected exemptions from forgery protection, and GET request entries for authentication initiation paths. Because there are no universal malware artifacts or fixed network signatures for this CSRF flaw, detection is primarily behavioral and application-specific.

• Started GET "/auth/
• method=GET path=/auth/
• GET /auth/
• Started GET "/users/auth/
• GET /users/auth/
• Started GET "/auth/developer"
• GET /auth/developer
• /auth/google_oauth2
• /auth/facebook
• /auth/github
• /auth/twitter
• /auth/saml
• /auth/openid_connect
• /auth/azure_activedirectory_v2
• /auth/cas
• OmniAuth.config.allowed_request_methods = [:get
• OmniAuth.config.allowed_request_methods = %i[get
• skip_before_action :verify_authenticity_token
• protect_from_forgery except:

What your security team should do

• Inventory Rails applications and services using the omniauth gem, especially versions 1.9.1 and earlier.
• Prioritize internet-facing applications that support third-party login, social login, SSO, or account-linking workflows.
• Upgrade to OmniAuth 2.x or later where feasible, or deploy omniauth-rails_csrf_protection with POST-only request phase enforcement for legacy applications.
• Search code repositories for configurations that allow GET-based OmniAuth request initiation or disable CSRF verification around authentication routes.
• Review recent account-linking events for unusual provider associations, unexpected identity changes, or links created shortly after suspicious /auth/<provider> requests.
• Add regression tests proving that OmniAuth request endpoints reject missing or invalid CSRF tokens.
• Notify support and fraud teams to watch for account takeover reports involving newly linked external login providers.