Received a bug report claiming onebox iframe allowlist bypass can someone help verify?

We run a Discourse forum and received an external report claiming a stored code-injection vulnerability via the onebox / allowed_onebox_iframes mechanism. Before we act on it, I’d like help from the community/team confirming whether the described behavior is actually possible on current Discourse.

The report claims:

  • Discourse oneboxes a bare URL on its own line and embeds the page’s twitter:player as an iframe for all viewers.
  • Origin matching for the iframe allowlist is “prefix-only,” so a host like www.youtube.com.attacker.example would be accepted as a legitimate YouTube embed while serving attacker-controlled HTML.
  • The default allowed_onebox_iframes is effectively a wildcard.

My understanding is that (a) Discourse matches allowlisted iframe hosts on a domain-boundary basis rather than a bare prefix, and (b) the default onebox iframe allowlist is a curated provider list, not *. Can someone confirm how host matching for allowed_onebox_iframes works in the current version, and whether a subdomain-suffix trick like the one described could actually pass validation?

We’re on Discourse version v2026.8.0-latest . Happy to share the raw report privately with the security team if useful.

Thanks.

I’m suspicious that this is a LLM security report from an incomplete pipeline.

A fully developed LLM security pipeline would develop a theory, then set up a test install of Discourse, set up the problematic site settings, and demonstrate the issue there. This does not seem to have happened, and they jumped from Theory → Sending the report to you.

Hi @Saurabh1,

I can confirm that the vulnerability is legitimate and we have a fix in the pipeline.

A fix for this issue is included in July 31st 2026 intermediate releases