CVE-2020-8166

What it actually does

The flaw is a cross-site request forgery weakness in Ruby on Rails versions before 5.2.5 and before 6.0.4. When an attacker obtains a global CSRF token, such as one exposed in an authenticity_token or csrf-token meta tag, vulnerable Rails CSRF logic can allow that token to be transformed or reused to forge a per-form CSRF token for a protected state-changing request. The result is an integrity-impacting vulnerability: an attacker can potentially cause an authenticated user’s browser to submit unauthorized actions that the application accepts as if they were legitimate user-initiated requests.

Why it matters to the business

Successful exploitation can allow unauthorized changes to user or application state, such as changing settings, submitting forms, modifying records, or triggering business workflows under the victim’s session. The impact depends heavily on which Rails actions are reachable and what privileges the victim has. This is not known to be in CISA KEV and has a relatively low EPSS score, but public exploit knowledge exists and Rails is widely deployed, so internet-facing applications that rely on affected Rails CSRF protections should still be upgraded during normal security patch cycles, with higher priority for administrative or high-value workflows.

How an attack unfolds

An attacker first identifies a Rails application running a vulnerable version and studies the state-changing endpoints that rely on Rails CSRF protection. The attacker then obtains or predicts use of a global CSRF token exposed by the application, such as a token rendered into a page meta tag. Using the weakness, the attacker crafts a request containing a forged per-form CSRF token for a targeted endpoint. The attacker then lures an authenticated victim to a malicious page, email link, embedded form, or other web content that causes the victim’s browser to send the forged request to the vulnerable application. Because the browser automatically includes the victim’s cookies, the application may process the request as the victim if the forged token is accepted. No named ransomware use or CISA KEV exploitation is currently indicated for this CVE, and the provided threat-actor context does not identify a reliable named actor campaign for this issue.

How to fix it

Upgrade Rails to a fixed release: use Rails 5.2.5 or later for the 5.2 branch, Rails 6.0.4 or later for the 6.0 branch, or a newer supported Rails release. For source builds of rails/rails, ensure the fix commit 7b5cc5a5dfcf38522be0a4b5daa97c5b2ba26c20 or a later commit containing the patch is present. After upgrading, rebuild and redeploy affected applications and verify dependency lockfiles, container images, and packaged artifacts no longer include vulnerable Rails versions. As defense in depth, keep SameSite cookie protections enabled where compatible, restrict sensitive state-changing actions to POST/PATCH/PUT/DELETE with CSRF validation, require reauthentication or step-up confirmation for high-risk actions, avoid exposing unnecessary tokens, and review custom CSRF handling or disabled protect_from_forgery settings.

How to confirm the fix worked

Confirm the deployed Rails version is 5.2.5 or later, 6.0.4 or later, or includes commit 7b5cc5a5dfcf38522be0a4b5daa97c5b2ba26c20. Check Gemfile.lock, gem inventory, container image SBOMs, CI dependency reports, and runtime version output rather than relying only on source manifests. Exercise representative state-changing forms after patching to confirm legitimate CSRF-protected workflows still function. Where practical, run a targeted security test that attempts to submit a cross-site request using a global token-derived per-form token and confirm the application rejects the request. Also verify that custom controllers have CSRF protection enabled and that exceptions are intentional and documented.

Typical attack path

1. Identify a Rails application running a vulnerable Rails version before 5.2.5 or before 6.0.4.
2. Map state-changing routes such as POST, PATCH, PUT, or DELETE actions that rely on Rails CSRF validation.
3. Obtain a global CSRF token rendered by the application, commonly from an authenticity_token or csrf-token meta tag in application HTML.
4. Forge a per-form CSRF token for the targeted action using the vulnerable Rails behavior.
5. Create a malicious page, form, script-assisted submission, or link that sends the forged request to the target application.
6. Convince an authenticated user to visit the attacker-controlled content or otherwise trigger the cross-site request.
7. The victim’s browser submits the request with the victim’s session cookies, and the vulnerable application may accept the request as authorized.

How to detect it

Detection is difficult because successful CSRF actions often look like legitimate requests from the victim’s browser and IP address. Review web access logs, Rails application logs, reverse proxy logs, WAF logs, and audit logs for state-changing POST, PATCH, PUT, or DELETE requests that have unexpected external Referer or Origin headers, missing or unusual navigation patterns, or actions performed by users who report not initiating them. Focus on privileged users and sensitive actions such as account changes, password or email updates, administrative changes, transactions, and workflow approvals. Look for clusters of failed CSRF validation events followed by successful requests to the same endpoint, which may indicate attacker testing. Rails logs may contain CSRF-related errors such as invalid authenticity token exceptions, although exploitation of this issue may not generate obvious errors if the forged token is accepted. Forensic review should correlate timestamps of suspicious state changes with browser history, email clicks, referrer domains, and any externally hosted pages that could have triggered form submissions.

• Can't verify CSRF token authenticity
• ActionController::InvalidAuthenticityToken
• InvalidAuthenticityToken
• authenticity_token
• csrf-token

What your security team should do

• Inventory Rails applications and prioritize internet-facing, authenticated, administrative, and workflow-critical applications running Rails before 5.2.5 or before 6.0.4.
• Upgrade affected applications to Rails 5.2.5, Rails 6.0.4, or a newer supported version; for source deployments, confirm inclusion of commit 7b5cc5a5dfcf38522be0a4b5daa97c5b2ba26c20 or later.
• Review high-impact state-changing endpoints for CSRF coverage, especially account changes, privilege changes, payment or order actions, configuration updates, and administrative functions.
• Search logs for suspicious state-changing requests with unusual external Referer or Origin values, especially requests executed by privileged users shortly after visiting external sites.
• Ensure session cookies use secure attributes such as Secure, HttpOnly, and SameSite where compatible, recognizing that these reduce CSRF risk but do not replace the Rails patch.
• Add regression tests for CSRF-protected actions so future Rails upgrades or controller changes do not accidentally weaken CSRF enforcement.