Discourse CVE-2026-91133

Requires an authenticated Discourse account (PR:L) able to invoke upload-resolution functionality - specifically the upload-metadata lookup, URL-lookup, or cooked-video-placeholder code paths - on a version prior to 2026.1.8/2026.6.3/2026.7.2/2026.8.0. The exploit works against default configurations (no special feature toggle needed), so instances that permit self-registration or have many low-trust members are most exposed. Limiting factors: attacker must be authenticated (not anonymous), impact is confined to reading restricted upload metadata (filenames and secure-upload paths) with no ability to modify records, and no integrity or availability effect occurs.

This is a legitimate but moderate-priority information-disclosure flaw, not a critical one. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N = 6.5) shows a remotely reachable, low-complexity bug that requires an authenticated account (PR:L) and yields confidentiality-only impact - no integrity or availability effect (I:N/A:N), consistent with the description that upload records are read but not modified. No EPSS score, no CISA KEV listing, and no public exploit code were provided, so exploitation status is 'no public exploit identified at time of analysis'; there is no SSVC decision data supplied either. The one signal worth scrutinizing is the C:H rating: the disclosed data is restricted upload METADATA (original filenames, secure-upload paths) rather than full record contents, so C:H is arguably generous - though secure-upload paths can serve as a stepping-stone to fetch otherwise-restricted files, which justifies the vendor's high confidentiality rating. Because any registered/authenticated user can trigger it against network-facing default installs, it is worth patching promptly on multi-tenant or public-signup Discourse instances, but the authentication requirement and confidentiality-only scope keep it below emergency severity.

An attacker registers or uses an existing low-privilege account on a Discourse forum and submits an upload-resolution request (upload metadata lookup, URL lookup, or cooked-video-placeholder path) containing SQL LIKE wildcards such as '%' or '_' instead of a literal upload identifier. Because the 'url LIKE ?' query is built without sanitize_sql_like, the wildcard matches unrelated upload rows, returning original filenames and secure-upload paths for uploads the user was never authorized to see. No public exploit code was identified, but the fix diff makes the trigger trivial to reconstruct.