Discourse EUVD-2026-86303

Requires TWO concrete preconditions both stated in the advisory: (1) the site must have a WILDCARD pattern configured in the allowed_iframes setting - this is not the default, so instances without wildcard iframe entries are not exploitable; and (2) the attacker must hold posting privileges (PR:L) to create a post or trigger a Onebox oEmbed request for an attacker-controlled URL. The technical trigger is an iframe URL whose allowlisted suffix appears after a URL authority separator, causing the server wildcard origin check to match while the browser resolves a different attacker-controlled origin. Impact is limited to rendering an attacker-controlled iframe (integrity/content injection), with no confidentiality or availability impact per the CVSS vector.

This is a genuinely low-priority issue despite being a real bug. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N = 4.3 Medium) reflects an authenticated (PR:L) content-injection / origin-confusion flaw with only limited integrity impact (I:L) and no confidentiality or availability impact. No EPSS score, no CISA KEV listing, and no public exploit are present in the input, so exploitation status is 'no public exploit identified at time of analysis.' Crucially, exploitation is gated on a non-default precondition: the site must configure a WILDCARD pattern in the allowed_iframes setting - most Discourse instances do not, which sharply narrows the real-world exposed population below what the network vector alone suggests. The 'Information Disclosure' tag conflicts with the CVSS vector (C:N), which indicates this is a content/origin-integrity issue, not data disclosure - treat the tag as mislabeled. Overall: a valid defense-in-depth fix worth patching on normal cadence, not an emergency.

On a Discourse forum that has enabled a wildcard entry in allowed_iframes, an attacker with an ordinary posting account crafts a post (or triggers a Onebox oEmbed lookup) containing an iframe URL whose allowlisted suffix is placed after a URL authority separator. The server-side wildcard origin check matches the allowed domain text, but browsers parse a different attacker-controlled origin, so an attacker-controlled iframe renders for viewers. No public exploit code is identified in the input, and the attack requires an authenticated posting account plus the non-default wildcard configuration.