CVE-2026-28282: 
NixOS vulnerability analysis and mitigation

CVE-2026-28282 is an incorrect authorization vulnerability in the discourse-policy plugin for Discourse, an open-source discussion platform. A user with policy creation permission can exploit the add-users-to-group policy attribute to gain unauthorized membership in any private or restricted group, subsequently gaining read access to private topics restricted to those groups. Affected versions include Discourse prior to 2026.1.2 (in the 2026.1.x branch), prior to 2026.2.1 (in the 2026.2.x branch), and version 2026.3.0-latest without the patch. It was disclosed on March 19, 2026, with a CVSS v3.1 base score of 6.5 (Medium) and a CVSS v4.0 base score of 2.3 (Low) (GitHub Advisory).

The root cause is CWE-863 (Incorrect Authorization): the add-users-to-group attribute in the discourse-policy plugin automatically enrolls users into a specified group when they accept a policy, but no code path verified whether the post author had permission to manage the target group (GitHub Advisory). Specifically, the PolicyController#ensure_can_accept method and the post_process_cooked handler both lacked a Guardian#can_edit_group? authorization check before persisting or acting on the add_users_to_group group ID (Patch Commit). An attacker with policy creation permissions could craft a policy referencing any group name — including restricted or admin-only groups — and any user accepting that policy would be silently added to the target group. The attack requires network access, low privileges (policy creation permission), and no user interaction beyond the victim accepting the policy.

Successful exploitation allows an authenticated attacker with policy creation permissions to gain unauthorized membership in any private or restricted Discourse group, including potentially privileged groups such as admin groups. Once group membership is obtained, the attacker can read all private topics and content accessible only to that group, resulting in unauthorized disclosure of sensitive information. There is no direct integrity or availability impact, but the confidentiality breach could expose sensitive organizational communications, internal discussions, or restricted content (GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of disclosure (GitHub Advisory). The EPSS score is approximately 0.013% (0.000130), indicating a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires an authenticated account with policy creation permissions, which limits the attacker pool, though the attack itself requires no user interaction beyond a victim accepting the crafted policy.

1. Obtain policy creation permissions: Ensure the attacker account has permission to create policies on the Discourse instance (e.g., a moderator or trusted user role with the discourse-policy plugin enabled).
2. Identify target group: Enumerate available groups on the Discourse instance, including private or restricted groups (e.g., via the /groups endpoint or admin panel visibility).
3. Craft a malicious policy post: Create a post containing a policy block with the add-users-to-group attribute referencing the target restricted group name, e.g.:

   [policy group=<visible_group> add-users-to-group=<restricted_group_name>]
   Please accept this policy.
   [/policy]

4. Induce policy acceptance: Wait for or socially engineer other users to accept the policy, or accept it yourself — upon acceptance, the PUT /policy/accept.json endpoint adds the accepting user to the target group without authorization checks.
5. Access restricted content: With group membership now granted, browse private topics and categories restricted to the target group to read sensitive content (GitHub Advisory, Patch Commit).

• Logs: Discourse application logs showing PUT /policy/accept.json requests where the associated policy's add_users_to_group field references a group the post author does not manage; unexpected group membership changes in audit logs for private/restricted groups.
• Database/Admin Panel: Unexpected users appearing as members of private or restricted groups, particularly users who should not have access; group membership additions correlated with policy acceptance events rather than direct admin actions.
• Application Behavior: Users reporting access to private topics or categories they were not explicitly granted access to; policy posts containing add-users-to-group attributes referencing groups not owned or managed by the post author.

Upgrade Discourse to one of the patched versions: 2026.1.2, 2026.2.1, or 2026.3.0-latest.1, which add Guardian#can_edit_group? authorization checks to both the post_process_cooked handler and PolicyController#ensure_can_accept (GitHub Advisory, Patch Commit). If immediate patching is not possible, two interim workarounds are available: (1) review all existing policies and remove any add-users-to-group attributes from policy definitions; or (2) disable the discourse-policy plugin entirely by setting the policy_enabled site setting to false. Administrators should also audit current group memberships for any unauthorized additions that may have occurred prior to patching.