Discourse EUVD-2026-86300

Requires the administrator to have configured the allowed_iframes site setting with a subpath-restricted allowlist pattern (e.g. https://host/*/preview/); the bypass is meaningless without such a path restriction to evade. The attacker must be able to submit post content containing an <iframe>, which in a default Discourse install requires an authenticated account with sufficient trust level to post. Exploitation depends on the iframe being rendered when a user views the post, and on the specific backslash-after-dot-segment normalization behavior of the viewer's browser.

Moderate, non-priority risk. The NVD CVSS 3.1 base score is 7.2 (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N), but the impact metrics are low across the board (C:L/I:L/A:N) and the 'High' tier here comes mostly from the scope change (S:C) plus PR:N/UI:N - not from severe technical impact. There is no EPSS score, no CISA KEV listing, and no public POC in the provided data, so the exploitation status is 'no public exploit identified at time of analysis.' No SSVC decision was supplied. A notable conflict: NVD scores this PR:N (unauthenticated), yet the vulnerability lives in the post-content HTML sanitizer, and injecting an <iframe> into a Discourse post realistically requires an account with posting privileges - verify against vendor. Bottom line: this is a real allowlist-bypass bug worth patching in the normal cycle, but the limited impact (loading disallowed embedded content, not code execution or data theft) and absence of any exploitation signal make it a lower operational priority than the raw 7.2 suggests.

An attacker with posting access to a Discourse instance whose admin has configured allowed_iframes with a subpath-restricted pattern crafts an iframe src using a decoded dot-segment followed by a literal backslash (e.g. ...preview/%2e%2e\evil). The traversal guard treats the path as inside the allowed subpath, but the browser normalizes the backslash and loads the iframe from an origin/path the admin never intended - enabling phishing, clickjacking, or hostile embedded content rendered inside the forum. No POC is known to be public.