CVE-2026-27491: 
NixOS vulnerability analysis and mitigation

CVE-2026-27491 is a missing authorization vulnerability in Discourse, an open-source discussion platform, that allows authenticated non-staff users to issue official warnings to other users — a capability restricted to staff/moderators. The flaw stems from a type coercion issue in the post actions API endpoint (PostActionsController). It affects Discourse versions 2026.1.0 up to (but not including) 2026.1.2, 2026.2.0 up to (but not including) 2026.2.1, and version 2026.3.0-latest prior to 2026.3.0-latest.1. Disclosed on March 19, 2026, it carries a CVSS v3.1 base score of 4.3 (Medium) and a CVSS v4.0 base score of 6.9 (Medium) (GitHub Advisory, Red Hat CVE).

The root cause is a type coercion mismatch (CWE-862: Missing Authorization) in PostActionsController#create. When a JSON API request is submitted, the is_warning parameter arrives as a Ruby boolean true rather than the string "true". The authorization guard in PostGuardian#post_can_act? compared opts[:is_warning] == "true", which evaluates to false in Ruby when the value is a boolean true, causing the non-staff check to be silently bypassed. With the guard passed, PostActionCreator#perform proceeds to TopicCreator#create_warning, where boolean true is truthy and a UserWarning record is created. The fix involved casting params[:is_warning] using ActiveModel::Type::Boolean.new.cast in the controller and simplifying the guardian check to a direct truthiness evaluation (GitHub Commit, GitHub Advisory).

Exploitation allows any authenticated (logged-in) non-staff Discourse user to issue official moderation warnings to other users, a feature intended exclusively for staff. The practical consequence is potential abuse of the warning system for harassment or impersonation of moderator authority. No data exposure, privilege escalation beyond this specific action, or availability impact is possible through this vulnerability (GitHub Advisory).

Exploitation requires the attacker to be a logged-in (authenticated) Discourse user and to send a specifically crafted JSON API request to /post_actions.json with is_warning: true as a boolean. No public proof-of-concept exploit code has been identified, and there is no evidence of in-the-wild exploitation. The EPSS score is approximately 0.039% (very low probability of exploitation), and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog (GitHub Advisory, Red Hat CVE).

1. Authenticate: Log in to a vulnerable Discourse instance as any regular (non-staff) user account.
2. Identify a target post: Note the post ID of any post authored by the user you wish to warn.
3. Craft a JSON API request: Send a POST request to /post_actions.json with Content-Type: application/json, including the following body:

{
  "id": <target_post_id>,
  "post_action_type_id": <notify_user_type_id>,
  "message": "<warning message text>",
  "is_warning": true
}

4. Bypass authorization: Because is_warning is sent as a JSON boolean true rather than the string "true", the guardian's string comparison (opts[:is_warning] == "true") evaluates to false, causing the non-staff restriction check to be skipped.
5. Warning created: The request proceeds through PostActionCreator and TopicCreator#create_warning, resulting in an official UserWarning record being created against the target user (GitHub Commit, GitHub Advisory).

• Network: Unexpected POST requests to /post_actions.json from non-staff user accounts with Content-Type: application/json and a body containing "is_warning": true.
• Logs: Discourse application logs showing PostActionsController#create invocations with is_warning=true from accounts not in the staff group; new UserWarning records created by non-staff user IDs.
• Database: Unexpected entries in the user_warnings table associated with non-staff created_by_id values.

Upgrade Discourse to one of the patched versions: 2026.3.0-latest.1, 2026.2.1, or 2026.1.2. The patches are applied across three separate commits targeting each supported release branch. No configuration-based workarounds are available; patching is the only remediation (GitHub Advisory, GitHub Commit).