CVE-2026-32113: Discourse CSRF Vulnerability

CVE-2026-32113 Overview

CVE-2026-32113 is an open redirect vulnerability (CWE-601) affecting Discourse, a popular open-source discussion platform. The vulnerability exists in the StaticController's enter action, which reads the sso_destination_url cookie and redirects users to the specified URL without proper validation. While this cookie is normally set during legitimate DiscourseConnect Provider flows with cryptographically validated SSO payloads, cookies are client-controlled and can be manipulated by attackers to redirect users to malicious external sites.

Critical Impact

Attackers can craft malicious URLs that exploit the open redirect to phish users or steal credentials by redirecting them to attacker-controlled domains that mimic legitimate Discourse instances.

Affected Products

• Discourse versions 2026.1.0-latest to before 2026.1.3
• Discourse versions 2026.2.0-latest to before 2026.2.2
• Discourse versions 2026.3.0-latest to before 2026.3.0

Discovery Timeline

• 2026-03-31 - CVE-2026-32113 published to NVD
• 2026-04-01 - Last updated in NVD database

Technical Details for CVE-2026-32113

Vulnerability Analysis

This open redirect vulnerability stems from insufficient validation of the sso_destination_url cookie in Discourse's StaticController. The enter action is designed to redirect users back to their original destination after authentication through DiscourseConnect Provider flows. However, the implementation trusts the cookie value without verifying that the destination URL belongs to an authorized domain.

The vulnerability requires network access and user interaction, as an attacker must convince a victim to visit a crafted URL or inject the malicious cookie value. The primary security impact is on downstream systems rather than Discourse itself, as users can be redirected to phishing sites or malicious domains that appear to be part of the legitimate authentication flow.

Root Cause

The root cause is the unconditional trust placed in the sso_destination_url cookie value. The original implementation set allow_other_host: true for any redirect destination stored in this cookie without validating whether the URI belongs to an authorized SSO provider domain. Since cookies are client-controlled data, an attacker can set this cookie to any arbitrary URL, bypassing the cryptographic validation that normally occurs during legitimate DiscourseConnect flows.

Attack Vector

The attack leverages the network-accessible StaticController endpoint combined with social engineering. An attacker can:

1. Set the sso_destination_url cookie to an attacker-controlled domain via a separate vulnerability or by tricking the user
2. Direct the victim to the Discourse enter action endpoint
3. Discourse reads the malicious cookie and redirects the user to the attacker's site with allow_other_host: true
4. The victim may unknowingly provide credentials or sensitive information to the phishing site

The vulnerability is mitigated by the requirement for user interaction and the attack complexity involved in setting the cookie value.

# Vulnerable code pattern (before patch):
if cookies[:sso_destination_url]
  destination = cookies.delete(:sso_destination_url)
  allow_other_host = true
end

# Patched code in app/controllers/static_controller.rb:
# We need this to redirect the user back when Discourse Connect Provider is used.
if cookies[:sso_destination_url]
  sso_url = cookies.delete(:sso_destination_url)

  begin
    uri = URI(sso_url)
    if valid_sso_redirect_uri?(uri)
      destination = sso_url
      allow_other_host = true
    end
  rescue URI::Error, ArgumentError
    # Invalid URI, ignore and use default destination
  end
end

Source: GitHub Commit Update

Detection Methods for CVE-2026-32113

Indicators of Compromise

• Unusual redirect patterns in web server logs showing the enter action redirecting to external domains
• sso_destination_url cookie values containing domains not associated with legitimate SSO providers
• User reports of unexpected redirects during or after authentication flows
• Phishing attempts that leverage Discourse URLs as the initial entry point

Detection Strategies

• Monitor HTTP response headers for 302/301 redirects from the StaticController enter endpoint to external hosts
• Implement web application firewall (WAF) rules to detect manipulation of the sso_destination_url cookie
• Analyze server access logs for patterns indicating redirect abuse, such as unusual referrer chains
• Deploy anomaly detection for authentication flow deviations in user behavior analytics

Monitoring Recommendations

• Enable detailed logging for the StaticController and DiscourseConnect Provider flows
• Set up alerts for redirects to domains outside the configured SSO provider whitelist
• Monitor for bulk cookie manipulation attempts across user sessions
• Implement real-time threat detection for open redirect exploitation patterns

How to Mitigate CVE-2026-32113

Immediate Actions Required

• Upgrade Discourse to patched versions 2026.1.3, 2026.2.2, or 2026.3.0 immediately
• Review server logs for any historical exploitation attempts
• Notify users if any suspicious redirect activity was detected
• Temporarily disable DiscourseConnect Provider functionality if immediate patching is not possible

Patch Information

Discourse has released security patches addressing this vulnerability in versions 2026.1.3, 2026.2.2, and 2026.3.0. The fix introduces proper URI validation through a new valid_sso_redirect_uri? method that verifies the destination URL before allowing cross-host redirects. The patch also adds error handling for malformed URIs, falling back to the default destination when validation fails.

For detailed patch information, see the GitHub Commit Update and the GitHub Security Advisory.

Workarounds

• If immediate upgrade is not possible, disable the DiscourseConnect Provider feature until patching can be completed
• Implement a reverse proxy or WAF rule to validate or strip the sso_destination_url cookie before requests reach Discourse
• Restrict SSO functionality to a whitelist of known, trusted domains at the network level
• Consider implementing Content Security Policy headers to limit redirect destinations

# Example nginx configuration to block suspicious sso_destination_url cookies
# Add to your Discourse server block
location / {
    # Block requests with suspicious sso_destination_url cookies
    if ($http_cookie ~* "sso_destination_url=.*(?:http|https)://(?!trusted-domain\.com)") {
        return 403;
    }
    proxy_pass http://discourse_upstream;
}