Where
-Infinity
0
Severity
6.3
EPSS
0.04%
XSS, SSRF
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Impact

The DomainFilteringAdapter in the Embed extension is vulnerable to an allowlist bypass due to a missing hostname boundary assertion in the domain-matching regex. An attacker-controlled domain like youtube.com.evil passes the allowlist check when youtube.com is an allowed domain.

This enables two attack vectors:

- SSRF: The OscaroteroEmbedAdapter makes server-side HTTP requests to the embed URL via the embed/embed library. A bypassed domain filter causes the server to make outbound requests to an attacker-controlled host, potentially probing internal services or exfiltrating request metadata. - XSS: EmbedRenderer outputs the oEmbed response HTML directly into the page with no sanitization. An attacker controlling the bypassed domain can return arbitrary HTML/JavaScript in their oEmbed response, which is rendered verbatim.

Any application using the Embed extension and relying on alloweddomains to restrict domains when processing untrusted Markdown input is affected.

Patches

This has been patched in version 2.8.2. The fix replaces the regex-based domain check with explicit hostname parsing using parseurl(), ensuring exact domain and subdomain matching only.

Workarounds

- Disable the Embed extension, or restrict its use to trusted users - Provide your own domain-filtering implementation of EmbedAdapterInterface - Enable a Content Security Policy (CSP) and outbound firewall restrictions

1 / 2
Source: GitHub
First published (updated )
Severity
6.1
EPSS
0.03%
XSS
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:L/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Impact

The DisallowedRawHtml extension can be bypassed by inserting a newline, tab, or other ASCII whitespace character between a disallowed HTML tag name and the closing >. For example, <script\n> would pass through unfiltered and be rendered as a valid HTML tag by browsers. This is a cross-site scripting (XSS) vector for any application that relies on this extension to sanitize untrusted user input.

All applications using the DisallowedRawHtml extension to process untrusted markdown are affected. Applications that use a dedicated HTML sanitizer (such as HTML Purifier) on the rendered output are not affected.

Patches

Fixed in 2.8.1. The regex character class [ \/>] was changed to [\s\/>] to match all whitespace characters that browsers accept as valid tag name terminators.

Workarounds

- Set the htmlinput configuration option to 'escape' or 'strip' to disable all raw HTML, though this is a broader restriction than the DisallowedRawHtml extension provides. - Pass the rendered HTML through a dedicated HTML sanitizer before serving it to users (always recommended)

Resources

- CommonMark DisallowedRawHtml documentation - CWE-79: Improper Neutralization of Input During Web Page Generation - CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

1 / 2
Source: GitHub
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203