Discourse CVE-2026-91159

Exploitation requires all of the following concrete prerequisites: (1) an authenticated Discourse account with posting permission (PR:L); (2) attacker control of a public webpage that will be oneboxed and of that page's oEmbed response; and (3) an iframe whose src matches the site's configured iframe allowlist (allowed_iframe_regexes), e.g., a permitted provider such as a YouTube embed. The vulnerable path is Discourse's AllowlistedGenericOnebox oEmbed/onebox processing, which trusted the entire HTML fragment once any allowlisted iframe was present, allowing sibling <style>/<div> content to persist. Limiting factors that reduce realistic risk: a valid posting account is mandatory, the attacker must operate external web infrastructure, and the iframe source must match the specific allowlist; impact is confined to content integrity (stored overlays / misleading UI) - it does not expose restricted data, affect availability, or bypass Discourse's Content Security Policy.

The CVSS 3.1 base score of 7.7 (HIGH, vendor/GHSA-provided) overstates real-world urgency for most operators because the vector is integrity-only (C:N/A:N) and gated behind privileges and attacker infrastructure. Attack vector is network (AV:N) with low complexity (AC:L), but exploitation requires PR:L (an authenticated posting account), control of a public webpage and its oEmbed response, and an iframe source that matches the site's configured allowlist - a meaningful real-world barrier. No EPSS score, no CISA KEV listing, and no POC flag were provided in the intelligence; however, the fix is public (GHSA-f9jx-vv33-4282 plus four commits) and the patch includes a spec test that concretely demonstrates the sibling-HTML/overlay technique, so the method is effectively disclosed even though no weaponized exploit is reported. The scope change (S:C) is justified because stored malicious content renders for other users. Net: this is a content-integrity / UI-spoofing (clickjacking/phishing-style) issue, not RCE or data exposure - a legitimate fix-on-schedule item rather than an emergency, and lower-priority than the 7.7 implies for environments that restrict posting accounts. Note one signal conflict: the vector encodes I:H, but the described impact (misleading visual overlays, no data tampering) reads closer to I:L - treat the HIGH severity with that caveat.

An attacker who holds a low-privilege posting account on a Discourse forum publishes a public webpage whose oEmbed response embeds an allowlisted iframe (e.g., a YouTube embed) alongside unrelated sibling markup such as a <style> block and a fixed-position <div> overlay. They post the page URL; Discourse's onebox processing fetches the oEmbed, treats the whole fragment as trusted because it contains the allowlisted iframe, and stores the overlay in the post. Other users then view a page with an attacker-controlled visual overlay enabling phishing or fraudulent UI. No weaponized exploit is reported, but the fix commit's spec test publicly demonstrates the technique.