Discourse CVE-2026-91134

Requires an authenticated Discourse account with posting privileges (PR:L) and a site where the allowed_iframes prefix policy is configured to permit at least one iframe host prefix. The attacker must craft an iframe src containing encoded userinfo so the decoded form the sanitizer validates differs from the stored src the browser interprets. Exploitation is limited by the need for a valid posting account and by the fact that impact is confined to rendering attacker-controlled cross-origin content in viewers' browsers (no direct RCE or availability loss); default configurations that heavily restrict or disable iframes reduce exposure.

This is a genuine but moderate-severity issue, not a high-priority emergency. The CVSS 3.1 score of 5.4 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N) reflects a network-reachable flaw requiring authentication (PR:L - an account with posting privileges) and yielding only Low confidentiality and Low integrity impact with no availability effect. No EPSS score, KEV listing, or public POC is present in the provided data, so this is 'no public exploit identified at time of analysis.' The vulnerability is a sanitizer allowlist-bypass: the Discourse post sanitizer decoded and validated the iframe src differently from the stored value, so an encoded userinfo segment let the browser resolve an attacker-controlled host while the allowed_iframes prefix check accepted the encoded URL as allowed. Real-world risk is bounded because exploitation requires a valid posting account and the allowed_iframes feature to be configured, and the impact is confined to rendering attacker cross-origin content (phishing/clickjacking/limited content injection) rather than direct code execution. This is a defense-in-depth sanitizer fix worth patching promptly on public/large forums but is not a critical mass-exploitation candidate.

An authenticated user with posting privileges crafts a post containing an <iframe> whose src encodes userinfo so that the allowlist prefix check passes against the encoded form while the browser resolves an attacker-controlled host. Once persisted, every viewer of that post silently loads attacker-controlled cross-origin content (e.g., a phishing or credential-harvesting page framed as trusted forum content). No public exploit code is identified in the provided data, though the fix and regression tests are public in PR #42882.