Discourse CVE-2026-44782

The vulnerability requires two conditions to be exploitable in a meaningful way: (1) a valid authenticated session on the Discourse instance - unauthenticated access is not sufficient per the CVSS PR:L metric; and (2) the site administrator must have set SiteSetting.enable_names to false, which is a non-default configuration used by communities that wish to suppress display of user real names. On instances where enable_names remains at its default true value, user names are already publicly visible and no information is improperly disclosed. Exploitation is limited to read-only name enumeration via group post endpoints; it does not enable account takeover, code execution, or data modification.

The NVD-assigned CVSS 3.1 score of 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) is consistent with the nature of the flaw: network-reachable, low complexity, requires a valid session, and produces only a limited confidentiality impact. The EPSS score of 0.03% at the 9th percentile corroborates low real-world exploitation interest, and the vulnerability is neither listed in CISA KEV nor accompanied by any public proof-of-concept code. The practical risk is bounded by two factors: exploitation requires an authenticated session (PR:L), and the information disclosure is only consequential when an administrator has intentionally set enable_names to false - a non-default privacy configuration. Instances running with the default enable_names=true are not impacted because names are already publicly visible. The combination of low EPSS, no KEV listing, no POC, authentication requirement, and non-default configuration dependency places this firmly in the lower tier of prioritization for most operators, though it is a meaningful trust violation for communities that rely on name suppression for user safety.

An authenticated Discourse user - even one with minimal trust-level permissions - sends an API or browser request to a group post listing endpoint. The GroupPostSerializer serializes user.name unconditionally due to the misnamed predicate, and the response JSON includes the real names of post authors. On a community where the administrator has disabled names to protect pseudonymous members, the attacker harvests a mapping of usernames to real names across all returned posts. No public exploit code exists for this specific issue.