CVE-2026-27491: Discourse Auth Bypass Vulnerability

CVE-2026-27491 Overview

CVE-2026-27491 is an authorization bypass vulnerability affecting Discourse, the popular open-source discussion platform. A type coercion issue in the post actions API endpoint allowed non-staff users to issue warnings to other users—a feature that should be restricted exclusively to staff members for moderation purposes.

The vulnerability exists due to improper handling of the is_warning parameter in the PostActionsController. By sending a specifically crafted request, an authenticated attacker could bypass the staff-only restriction and create unauthorized user warnings. While the impact is limited to creating illegitimate warnings without data exposure or further privilege escalation, this represents a violation of the platform's access control model.

Critical Impact

Authenticated non-staff users can bypass authorization controls to issue staff-only warnings to other users, potentially causing confusion and undermining trust in the moderation system.

Affected Products

• Discourse versions prior to 2026.3.0-latest.1
• Discourse versions prior to 2026.2.1
• Discourse versions prior to 2026.1.2

Discovery Timeline

• 2026-03-19 - CVE CVE-2026-27491 published to NVD
• 2026-03-19 - Last updated in NVD database

Technical Details for CVE-2026-27491

Vulnerability Analysis

This vulnerability falls under CWE-862 (Missing Authorization). The root cause lies in how the Discourse application handles the is_warning boolean parameter when processing post actions. The original code in lib/guardian/post_guardian.rb only checked if opts[:is_warning] was present and equal to the string "true", rather than properly evaluating it as a boolean value.

An attacker could bypass this check by sending a truthy value that doesn't match the string "true" exactly—such as sending is_warning as "1", "yes", or any other value that would be interpreted as truthy in Ruby but wouldn't match the string comparison == "true". This allowed the authorization check to pass even for non-staff users, granting them access to the staff-only warning functionality.

The vulnerability requires the attacker to be a logged-in user and targets the notify_user action within the post actions API endpoint. While no data exposure or privilege escalation beyond creating unauthorized warnings was possible, the ability to issue official-looking warnings could be used to harass users or create confusion within communities.

Root Cause

The vulnerability stems from inconsistent boolean handling between the controller and guardian layers. In the PostActionsController, the is_warning parameter was passed directly from params[:is_warning] without proper type casting, while the guardian check used a flawed string comparison (opts[:is_warning] == "true") instead of proper boolean evaluation. This created a gap where certain truthy values could bypass the authorization check while still being interpreted as true elsewhere in the application.

Attack Vector

The attack requires network access and an authenticated session. An attacker would craft a POST request to the post actions API endpoint with a specially formatted is_warning parameter value. The parameter value would need to be truthy enough to create a warning but not equal to the exact string "true" to bypass the staff authorization check. This is a network-based attack with low complexity, requiring only basic authentication and no user interaction.

# Vulnerable code in lib/guardian/post_guardian.rb (before patch)
# The check only matched exact string "true", allowing bypass with other truthy values
if action_key == :notify_user &&
     (
       post.user.blank? ||
         (!is_staff? && opts[:is_warning].present? && opts[:is_warning] == "true")
     )
  return false
end

# Fixed code (after patch)
# Properly evaluates opts[:is_warning] as a boolean
if action_key == :notify_user && (post.user.blank? || (!is_staff? && opts[:is_warning]))
  return false
end

Source: GitHub Commit

# Controller fix in app/controllers/post_actions_controller.rb
# Before: is_warning: params[:is_warning],
# After: Proper boolean casting ensures consistent type handling
is_warning: ActiveModel::Type::Boolean.new.cast(params[:is_warning]),

Source: GitHub Commit

Detection Methods for CVE-2026-27491

Indicators of Compromise

• Unusual warning activity from non-staff user accounts in moderation logs
• POST requests to post actions endpoints with atypical is_warning parameter values (e.g., "1", "yes", "Y")
• Warnings issued without corresponding staff action audit trail entries
• User complaints about receiving warnings from accounts without moderator privileges

Detection Strategies

• Monitor API access logs for POST requests to /post_actions endpoints with is_warning parameters from non-staff authenticated sessions
• Implement log analysis to correlate warning creation events with staff role verification
• Review database records for warnings where the issuing user lacks appropriate staff permissions
• Deploy web application firewall rules to flag unusual parameter patterns in post action requests

Monitoring Recommendations

• Enable detailed logging on the PostActionsController to capture all warning-related requests
• Set up alerts for warning creation events and cross-reference with staff user lists
• Periodically audit the warnings table to identify any warnings created by non-staff users
• Monitor for multiple warning attempts from single non-staff accounts as potential exploitation indicators

How to Mitigate CVE-2026-27491

Immediate Actions Required

• Upgrade Discourse to version 2026.3.0-latest.1, 2026.2.1, or 2026.1.2 or later immediately
• Review moderation logs for any unauthorized warnings issued prior to patching
• Remove any illegitimate warnings that were created through exploitation of this vulnerability
• Notify affected users if they received unauthorized warnings from non-staff accounts

Patch Information

The Discourse team has released security patches across multiple version branches. The fix involves two key changes:

1. Controller layer: The is_warning parameter is now properly cast to a boolean using ActiveModel::Type::Boolean.new.cast() before being passed to the action handler.

2. Guardian layer: The authorization check was simplified to evaluate opts[:is_warning] as a boolean value directly, rather than performing an unreliable string comparison.

Organizations should update to one of the following patched versions:

• 2026.3.0-latest.1 (latest branch)
• 2026.2.1 (stable branch)
• 2026.1.2 (beta branch)

For additional details, refer to the GitHub Security Advisory.

Workarounds

• No official workarounds are available for this vulnerability
• Upgrading to a patched version is the only remediation path
• As a temporary measure, organizations may consider restricting API access to authenticated endpoints pending upgrade
• Monitor and manually review all new warnings until the patch can be applied

# Upgrade Discourse to latest patched version
cd /var/discourse
./launcher rebuild app

# Verify installed version after upgrade
./launcher enter app
rails runner "puts Discourse::VERSION::STRING"