RHSA-2026:76134HighCVSS 9.6

Red Hat Security Advisory: Red Hat Single Sign-On 7.6.13 for OpenShift image security update

Published
October 5, 2026
Last Modified
October 6, 2026

🔗 CVE IDs covered (27)

📋 Description

CVE-2025-9784 — undertow: Undertow MadeYouReset HTTP/2 DDoS Vulnerability CVE-2025-12543 — undertow-core: Undertow HTTP Server Fails to Reject Malformed Host Headers Leading to Potential Cache Poisoning and SSRF CVE-2025-14813 — bouncycastle: BC-JAVA: GOSTCTR implementation unable to process more than 255 blocks correctly CVE-2026-0603 — org.hibernate/hibernate-core: Hibernate: Information disclosure and data deletion via second-order SQL injection CVE-2026-2092 — keycloak-services: Keycloak: Unauthorized access via improper validation of encrypted SAML assertions CVE-2026-2575 — keycloak: Keycloak: Denial of Service due to excessive SAMLRequest decompression CVE-2026-3505 — bouncycastle: BC-JAVA: unbounded PGP AEAD chunk size leads to pre-auth resource exhaustion CVE-2026-4634 — keycloak: Keycloak: Denial of Service via excessive processing of OpenID Connect scope parameters CVE-2026-5588 — bouncycastle: BC-JAVA: PKIX draft CompositeVerifier accepts empty signature sequence as valid CVE-2026-7307 — keycloak: Keycloak: Denial of Service via specially crafted SAML input CVE-2026-7507 — org.keycloak/keycloak-services: Session fixation in OIDC login flow that can lead to account takeover CVE-2026-15563 — wildfly-iiop-openjdk: Missing authentication on EAP's IIOP NameService leads to MITM or DoS CVE-2026-42578 — netty: io.netty/netty-handler-proxy: Netty: HTTP Header Injection via HttpProxyHandler Disabled Validation CVE-2026-42579 — netty: Netty: High integrity impact due to improper DNS domain name constraint enforcement CVE-2026-42581 — netty: io.netty/netty-codec-http: Netty: HTTP Request Smuggling due to improper handling of conflicting HTTP/1.0 headers CVE-2026-42587 — netty: io.netty/netty-codec-http: io.netty/netty-codec-http2: Netty: Denial of Service via unbounded memory allocation in HTTP content decompression CVE-2026-44249 — netty-handler: netty-handler: IPv6 subnet rule bypass due to incorrect masking operation CVE-2026-44893 — netty-codec-haproxy: Netty-codec-haproxy: Denial of Service via malformed HAProxy message CVE-2026-45416 — netty-handler: Netty: Denial of Service due to eager buffer allocation in TLS handshake CVE-2026-45674 — netty-resolver-dns: Netty: Information disclosure and data manipulation due to improper CNAME record validation CVE-2026-47691 — io.netty/netty-resolver-dns: Netty has Insufficient Bailiwick Validation for NS Records CVE-2026-48043 — netty-codec-http2: netty-codec-http2: Denial of Service due to resource leak CVE-2026-48059 — netty-codec-haproxy: Netty HAProxy PROXY protocol v2 codec: Denial of Service via memory leak from crafted PROXY protocol headers CVE-2026-50010 — netty-handler: Netty: Improper trust manager handling leads to hostname verification bypass CVE-2026-50193 — jackson-databind: Jackson-databind: Denial of Service via deeply nested JSON processing CVE-2026-54512 — jackson-databind: jackson-databind: Arbitrary code execution via PolymorphicTypeValidator bypass CVE-2026-68494 — com.fasterxml.jackson.core/jackson-core: tools.jackson.core/jackson-core: jackson-core: Denial of Service via incomplete fix in async JSON parser

🎯 Affected products4

  • Middleware Containers for OpenShift
  • rh-sso-7/sso76-openshift-rhel8@sha256:3c851f2398ba67beb5b9ca55d984010262b35bf9d659f279829abd33da01a7ac_ppc64le as a component of Middleware Containers for OpenShift
  • rh-sso-7/sso76-openshift-rhel8@sha256:c5afebef31c670ec67dab77ebaef767778c89c88be00f108cc435773fc42a993_amd64 as a component of Middleware Containers for OpenShift
  • rh-sso-7/sso76-openshift-rhel8@sha256:d466be5920b7e34edbca61e8e565dce1e8139b22481fa1d1b8f98d79acc946dc_s390x as a component of Middleware Containers for OpenShift

✅ Remediation

Before applying this update, make sure all previously released errata relevant to your system have been applied. For details on how to apply this update, refer to: https://access.redhat.com/articles/11258 Workaround: No mitigation is currently available that meets Red Hat Product Security’s standards for usability, deployment, applicability, or stability. Workaround: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use, applicability, or stability. Workaround: To mitigate this vulnerability, strictly limit the payload encrypted under a single key and Initialization Vector (IV) pair using the GOSTCTR implementation and G3413CTRBlockCipher to a maximum of 255 blocks. Alternatively, transition to a more secure, standardized and authenticated encryption mode. Workaround: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability. Workaround: To mitigate this vulnerability, enforce payload size limits on all incoming PGP messages before processing them. Additionally, apply memory quotas to the JVM or container environment to prevent a complete system outage in the event of memory exhaustion. Workaround: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability. Workaround: To mitigate this flaw, check that the signature sequence is not empty before passing any data to the CompositeVerifier for cryptographic validation. If the sequence is empty or null, explicitly reject the payload before it is processed. Workaround: To mitigate this vulnerability, restrict network access to the Keycloak SAML endpoint to trusted networks and clients. Implement firewall rules to limit inbound connections to the Keycloak service port (e.g., 8080) from untrusted sources. If the SAML protocol is not required for your deployment, consider disabling it to eliminate the attack surface. Applying these network restrictions or configuration changes may necessitate a restart or reload of the Keycloak service, which could temporarily affect its availability. Workaround: Applications utilizing Netty's HttpProxyHandler must ensure that any user-controlled input used to populate outbound headers is rigorously sanitized to prevent CRLF injection. If comprehensive input sanitization cannot be implemented, restricting network access to the application that uses the HttpProxyHandler can reduce the attack surface. Workaround: To mitigate this issue, configure any reverse proxies or load balancers in front of Netty to either reject HTTP/1.0 requests containing both Transfer-Encoding: chunked and Content-Length headers, or to explicitly prioritize the Transfer-Encoding header over Content-Length for HTTP/1.0 traffic. This ensures consistent interpretation of message boundaries and prevents request smuggling attacks. Workaround: To mitigate this issue, configure applications utilizing Netty's `SslClientHelloHandler` to specify a non-zero value for the `maxClientHelloLength` parameter. This will enable the internal length validation, preventing the eager allocation of large memory buffers when processing crafted TLS ClientHello messages. Refer to your specific application's documentation for details on configuring Netty's TLS handler. A restart of the affected application or service is required for the configuration changes to take effect. Workaround: Upgrade com.fasterxml.jackson.core:jackson-core to a fixed version, such as 2.18.8 or later, 2.21.4 or later, or the first fixed release in the applicable 2.22.x stream. For Jackson 3.x, upgrade to 3.1.4 or later, or the first fixed release in the applicable 3.2.x stream. If upgrading is not immediately possible, do not expose the non-blocking parser to untrusted, incrementally streamed JSON. Where feasible, use a synchronous parser or buffer and enforce strict request-size, connection-timeout, and concurrency limits at the ingress layer. Apply the upgrade as soon as possible because ingress limits reduce exposure but do not correct the parser defect.

🔗 References (3)