Dom Sanitizer
Monthly
Sanitizer bypass in rhukster dom-sanitizer up to and including 1.0.15 lets attackers smuggle external references through SVG presentation attributes that the library is supposed to neutralize, because the raw regex check can be defeated by CSS comments or hex escapes while a browser's CSS tokenizer still decodes the value into a live URL. The flaw is remote and requires no authentication or user privileges (CVSS 4.0 base 6.9; assessed CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L), and it only produces impact in deployments that sanitize attacker-supplied SVG (DOMSanitizer::SVG mode, or HTML mode containing inline SVG) and then render that output in a browser. Publicly available exploit code exists and the vendor has released 1.0.16 as the fix; there is no indication of confirmed active exploitation (CISA KEV) at time of analysis, and EPSS-style risk is driven mainly by the low attack complexity and the availability of a public proof of concept.
Cross-site scripting in rhukster/dom-sanitizer through 1.0.15 lets an attacker who can submit HTML that the library sanitizes slip script-capable URLs into attributes the filter never checked - form action, cite, poster, src, srcset, and background - because DOMSanitizer::isDangerousUrl() only scheme-validated href and xlink:href. The headline case is a form action="javascript:..." that survives end-to-end as a complete, submittable form (form, button/input and type are all allow-listed), firing when a victim views the stored content and interacts with it. Publicly available exploit code exists (published alongside the GHSA-mrpv-6x26-mf6c advisory); there is no confirmed active exploitation and this CVE is not in CISA KEV. Vendor-released patch: 1.0.16.
In rhukster/dom-sanitizer versions prior to 1.0.15, a data: URL containing Base64-encoded active markup (for example data:text/html;base64,… or data:image/svg+xml;base64,… with an onload handler) survives the isDangerousUrl() check and is emitted intact inside href and xlink:href attributes of sanitized HTML/SVG/MathML, allowing a sanitizer bypass that turns sanitized output into an injection vector when the application renders it. Exploitation is unauthenticated by the sanitizer itself (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N, assessed), but requires victim interaction - the victim must follow or trigger the surviving link - and is further constrained because modern browsers block top-level navigation to data:text/html URLs, which neutralizes the most common payload form; data: payloads consumed in other contexts (for example SVG <image> or embedded resource loading) remain more viable. There is no public exploit identified at time of analysis and no KEV listing; EPSS data was not provided, and the vendor has released a patched version.
DOMSanitizer before version 1.0.10 fails to sanitize CSS content within SVG <style> elements, allowing attackers to inject url() references and @import rules that trigger unauthorized HTTP requests to attacker-controlled hosts when the sanitized SVG is rendered in a browser. This affects PHP applications using the vulnerable library to sanitize user-supplied SVG content, enabling information disclosure through request metadata and potential CSRF attacks. The vulnerability requires user interaction (rendering the SVG) but affects all downstream users of the sanitized content due to scope change (C:L, S:C).
DOMSanitizer (aka dom-sanitizer) before 1.0.7 allows XSS via an SVG document because of mishandling of comments and greedy regular expressions. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Cross-Site Scripting (XSS) vulnerability could allow attackers to inject malicious scripts into web pages viewed by other users.
Sanitizer bypass in rhukster dom-sanitizer up to and including 1.0.15 lets attackers smuggle external references through SVG presentation attributes that the library is supposed to neutralize, because the raw regex check can be defeated by CSS comments or hex escapes while a browser's CSS tokenizer still decodes the value into a live URL. The flaw is remote and requires no authentication or user privileges (CVSS 4.0 base 6.9; assessed CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L), and it only produces impact in deployments that sanitize attacker-supplied SVG (DOMSanitizer::SVG mode, or HTML mode containing inline SVG) and then render that output in a browser. Publicly available exploit code exists and the vendor has released 1.0.16 as the fix; there is no indication of confirmed active exploitation (CISA KEV) at time of analysis, and EPSS-style risk is driven mainly by the low attack complexity and the availability of a public proof of concept.
Cross-site scripting in rhukster/dom-sanitizer through 1.0.15 lets an attacker who can submit HTML that the library sanitizes slip script-capable URLs into attributes the filter never checked - form action, cite, poster, src, srcset, and background - because DOMSanitizer::isDangerousUrl() only scheme-validated href and xlink:href. The headline case is a form action="javascript:..." that survives end-to-end as a complete, submittable form (form, button/input and type are all allow-listed), firing when a victim views the stored content and interacts with it. Publicly available exploit code exists (published alongside the GHSA-mrpv-6x26-mf6c advisory); there is no confirmed active exploitation and this CVE is not in CISA KEV. Vendor-released patch: 1.0.16.
In rhukster/dom-sanitizer versions prior to 1.0.15, a data: URL containing Base64-encoded active markup (for example data:text/html;base64,… or data:image/svg+xml;base64,… with an onload handler) survives the isDangerousUrl() check and is emitted intact inside href and xlink:href attributes of sanitized HTML/SVG/MathML, allowing a sanitizer bypass that turns sanitized output into an injection vector when the application renders it. Exploitation is unauthenticated by the sanitizer itself (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N, assessed), but requires victim interaction - the victim must follow or trigger the surviving link - and is further constrained because modern browsers block top-level navigation to data:text/html URLs, which neutralizes the most common payload form; data: payloads consumed in other contexts (for example SVG <image> or embedded resource loading) remain more viable. There is no public exploit identified at time of analysis and no KEV listing; EPSS data was not provided, and the vendor has released a patched version.
DOMSanitizer before version 1.0.10 fails to sanitize CSS content within SVG <style> elements, allowing attackers to inject url() references and @import rules that trigger unauthorized HTTP requests to attacker-controlled hosts when the sanitized SVG is rendered in a browser. This affects PHP applications using the vulnerable library to sanitize user-supplied SVG content, enabling information disclosure through request metadata and potential CSRF attacks. The vulnerability requires user interaction (rendering the SVG) but affects all downstream users of the sanitized content due to scope change (C:L, S:C).
DOMSanitizer (aka dom-sanitizer) before 1.0.7 allows XSS via an SVG document because of mishandling of comments and greedy regular expressions. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Cross-Site Scripting (XSS) vulnerability could allow attackers to inject malicious scripts into web pages viewed by other users.