Discourse CVE-2026-72731

Exploitation requires: (1) an active Discourse account with membership in a group that has been explicitly granted access to at least one shared Data Explorer query - this is a non-default, administrator-configured state; (2) the discourse-data-explorer plugin must be installed and enabled on the instance; and (3) the target query must accept at least one user-supplied parameter, as queries without parameters have no interpolation surface. Exploitation is limited by the read-only transaction boundary, which unconditionally prevents INSERT, UPDATE, DELETE, and DDL operations regardless of the injected SQL. It is further limited by the PR:L requirement - anonymous visitors and users who have not been granted query access cannot exploit this flaw. The attack does not require staff or admin privileges, meaning any regular user in a sharing group is a potential attacker.

The CVSS 7.1 score (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N) accurately captures the primary risk profile. The network attack vector and low complexity reflect that exploitation requires only a valid HTTP request with crafted parameter values. The PR:L requirement is a meaningful limiting factor: the attacker must hold an account that has been granted access to a shared Data Explorer query, which is not the default for all users. The C:H impact is well-supported - read access to all PostgreSQL tables means credentials, private messages, user PII, and API tokens are exposed. The I:L in the vendor-assigned vector is worth scrutiny: the description explicitly states queries run in a read-only transaction, making direct data modification impossible. The I:L may account for indirect integrity risk (e.g., exfiltrated admin tokens enabling authenticated writes), but this should be understood as secondary rather than direct. No KEV listing and no public POC have been identified at time of analysis, which lowers the urgency relative to the raw CVSS score. However, exploitation complexity is genuinely low for anyone who already has query access, and the confidentiality impact is severe enough to treat this as high priority on affected instances.

A non-staff member of a Discourse group that has been granted access to a shared Data Explorer query crafts a parameter value such that recursive interpolation introduces an additional parameter name, or encodes a SQL comment containing a new parameter declaration - effectively breaking out of the intended query template. The injected SQL executes within the existing read-only transaction, and the attacker extracts rows from the user_emails or api_keys table via the query result set. No public proof-of-concept code has been identified, but the technique is a straightforward variant of classic second-order SQL injection requiring only authenticated HTTP access.