CVE-2026-91121

Discourse before certain versions allowed a stored cross-origin iframe to bypass the allowed_iframes prefix policy when the iframe src contained encoded userinfo. An authenticated user with posting privileges could persist the iframe in a post, causing attacker-controlled cross-origin content to be rendered.

Discourse before certain versions, when wildcard patterns were used in the allowed_iframes setting, could accept a crafted iframe URL whose allowlisted suffix appeared after a URL authority separator. The origin check was bypassed, and the browser selected a different attacker-controlled origin, allowing an attacker-controlled iframe to be rendered.

In Discourse versions prior to 3.5.4, 2025.11.2, 2025.12.1, and 2026.1.0, permalinks pointing to access-restricted resources (private topics, categories, posts, or hidden tags) were redirecting users to URLs containing the resource slug, even when the user didn't have access to view the resource. This leaked potentially sensitive information (e.g., private topic titles) via the redirect Location header and the 404 page's search box.

Discourse, an open source discussion platform, contains a vulnerability in versions prior to 3.5.4, 2025.11.2, 2025.12.1, and 2026.1.0. The issue involves hostname validation in the FinalDestination component, which could allow bypassing SSRF protections under certain conditions.

Discourse is an open source discussion platform. In versions prior to 3.5.4, 2025.11.2, 2025.12.1, and 2026.1.0, some subscription endpoints lack proper checking for ownership before making changes. This issue is patched in versions 3.5.4, 2025.11.2, 2025.12.1, and 2026.1.0.

Prior to versions 2026.1.6, 2026.5.2, 2026.6.1, and 2026.7.0 in Discourse, an unauthenticated attacker could send a single request with a crafted color_scheme_id (or dark_scheme_id) cookie to inject arbitrary HTML into a Discourse page. Because the cookie value was rendered into a color scheme tag without escaping, the attacker could break out of the attribute and inject a tag that bypassed Discourse's nonce-based Content Security Policy, resulting in arbitrary JavaScript execution in visitors' browsers.

Discourse is an open-source discussion platform. Prior to 2026.1.8, 2026.6.3, 2026.7.2, and 2026.8.0, provider-controlled video titles in lazy video embeds could be reparsed as HTML when Discourse generated notification emails or chat summaries. A user with standard posting privileges could create a post for an enabled YouTube, Vimeo, or TikTok provider whose title contained markup, and the email and chat-summary rendering path would place that markup into the output instead of treating it solely as text. Recipients using HTML-capable email clients could see injected content, potentially including event handlers, but the issue did not directly expose a Discourse browser session or affect the forum page itself. Lazy video embeds must be enabled, which is the default configuration. This issue is fixed in versions 2026.1.8, 2026.6.3, 2026.7.2, and 2026.8.0.

Discourse is an open-source discussion platform. Prior to 2026.1.8, 2026.6.3, 2026.7.2, and 2026.8.0, the topic small-action and nested-activity-log components interpolated the free-form action_code_who value into mention-link href attributes without URL encoding. A quote-bearing display name could terminate the intended URL attribute and inject attacker-controlled elements into the trusted rendered markup. Although the visible mention text was escaped, the unencoded path component allowed stored HTML injection when another user viewed the affected topic action or activity log. This issue is fixed in versions 2026.1.8, 2026.6.3, 2026.7.2, and 2026.8.0.

Discourse before certain versions allowed authenticated users to supply unescaped SQL LIKE wildcard characters in upload-resolution patterns, causing unrelated upload records to be selected. Access to restricted metadata, including original filenames and secure-upload paths, was possible without modifying the records.

In Discourse before 2026.1.8, 2026.6.3, 2026.7.2, and 2026.8.0, the iframe src traversal guard did not treat literal backslashes as path separators after decoded dot segments. A crafted source could pass an allowed_iframes subpath check while browser URL normalization moved the iframe outside the intended allowed path. The resulting iframe could load content from a location not allowed by the administrator.