Discourse EUVD-2026-36560

On Discourse instances where login_required is disabled (the default for many public communities): no authentication is required - anonymous users can subscribe to any /web_hook_events/<id> channel. On instances where login_required is enabled: any authenticated user account, regardless of role or group membership, can access all webhook event channels. The core enabling condition is the absence of group_ids enforcement in the MessageBus.publish call within Jobs::RedeliverWebHookEvents - this is a code-level omission present in all affected versions regardless of other configuration. Exploitation is further limited by requiring that webhook redelivery jobs have actually run (i.e., the feature must be in use), and the confidentiality impact depends entirely on what data the site's configured webhooks carry in their payloads.

The vendor-assigned CVSS score of 4.3 (Medium) uses AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N. The PR:N rating reflects that unauthenticated access is possible when login_required is disabled, while UI:R is inconsistent with the described attack - direct MessageBus channel subscription requires no victim interaction, suggesting the UI:R metric may underrepresent real-world exploitability on public instances. EPSS of 0.03% at the 9th percentile and the absence of a CISA KEV listing collectively indicate low probability of widespread automated exploitation currently. Real-world risk is moderate to sensitive Discourse deployments that use webhooks for internal integrations (CI/CD callbacks, CRM events, payment notifications) where payload content is confidential. Instances with login_required enabled narrow the attacker pool to authenticated members, substantially reducing exposure. This is not a high-urgency emergency patch but represents a meaningful access-control bypass warranting prompt remediation given the trivial enumeration path.

An attacker - authenticated or anonymous depending on instance configuration - subscribes to the Discourse MessageBus channel /web_hook_events/1, /web_hook_events/2, and so on, iterating sequential integer IDs to retrieve webhook event payloads. Because webhook IDs are sequential integers with no per-channel authorization check, the attacker harvests event data (potentially including integration tokens, payload bodies, or system event details) across all redelivered webhook events without any elevated privileges. No exploit code has been publicly identified, but the attack requires no technical sophistication beyond basic HTTP knowledge.