RHSA-2026:69296HighCVSS 8.6

Red Hat Security Advisory: Red Hat Data Grid 8.6.3 security update

Published
September 21, 2026
Last Modified
October 1, 2026

🔗 CVE IDs covered (17)

CVE-2026-49978 →CVE-2026-55831 →CVE-2026-56745 →CVE-2026-59899 →CVE-2026-55833 →CVE-2026-56746 →CVE-2026-56817 →CVE-2026-62243 →CVE-2026-76844 →CVE-2026-56820 →CVE-2026-59296 →CVE-2026-59901 →CVE-2026-73508 →CVE-2026-44891 →CVE-2026-55851 →CVE-2026-56819 →CVE-2026-68494 →

📋 Description

CVE-2026-44891 — io.netty/netty-codec-stomp: Netty: Denial of Service vulnerability in STOMP decoder CVE-2026-49978 — dompurify: DOMPurify: Cross-site scripting vulnerability allows code execution CVE-2026-55831 — io.netty/netty-codec-http: Netty: Denial of Service via SPDY SETTINGS frame processing CVE-2026-55833 — netty: io.netty/netty-codec-http: Netty: Denial of Service via SPDY header decompression amplification CVE-2026-55851 — io.netty/netty-codec-haproxy: Netty codec-haproxy: Denial of Service via crafted PROXY protocol v2 message CVE-2026-56745 — netty: io.netty/netty-codec-http: Netty: Denial of Service via memory exhaustion in SPDY-to-HTTP codec CVE-2026-56746 — io.netty/netty-codec-http: Netty: Security control bypass allows unauthorized requests via null origin header CVE-2026-56817 — io.netty/netty-codec-xml: Netty: Information disclosure via XML External Entity (XXE) vulnerability CVE-2026-56819 — io.netty/netty-codec-http2: Netty: Denial of Service via HTTP/2 DATA frame memory leak CVE-2026-56820 — io.netty/netty-handler-ssl-ocsp: Netty: Certificate revocation bypass via OCSP response replay attack CVE-2026-59296 — io.micrometer/micrometer-registry-statsd: io.micrometer/micrometer-core: Micrometer: Line-protocol and log injection via unsanitized input allows metric and log spoofing CVE-2026-59899 — io.netty/netty-codec-http: Netty: Memory exhaustion in netty-codec-http (decompression bomb) CVE-2026-59901 — io.netty/netty-codec-compression: Netty: Infinite loop in netty-codec-compression (bzip2) CVE-2026-62243 — io.netty/netty-handler: Netty: TLS hostname verification bypass via OpenSSL client path misconfiguration 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 CVE-2026-73508 — io.netty/netty-codec-dns: Netty: Denial of Service via Memory Leak in DNS Record Decoder with Malformed Domain Names CVE-2026-76844 — webpack-dev-middleware: webpack-dev-middleware: Information Disclosure via Path Traversal

🎯 Affected products1

  • Red Hat Data Grid 8.6.3

✅ 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: To reduce the risk of this denial of service, restrict network access to any services that expose a STOMP endpoint and use Netty's `StompSubframeDecoder`. Implement firewall rules or network access controls to permit connections only from trusted sources. This action limits the ability of untrusted remote clients to exploit the vulnerability. 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: If CORS short-circuit functionality is not required, disable the shortCircuit() configuration in the CorsHandler. Alternatively, implement application-level origin validation to reject requests with null Origin headers. A web application firewall (WAF) can also be configured to block requests with null or missing Origin headers. Workaround: This vulnerability only affects applications that explicitly configure Netty to use the OpenSSL TLS provider (SslProvider.OPENSSL). The following mitigations can reduce exposure without applying a patch: 1) Use the default JDK SSL provider — Do not configure SslProvider.OPENSSL in your Netty SslContext setup. The default JDK SSL provider (SslProvider.JDK) is not affected by this vulnerability. Most applications use the JDK default unless explicitly overridden. 2) Use X509ExtendedTrustManager — If the OpenSSL provider is required, ensure the configured trust manager extends X509ExtendedTrustManager rather than the plain X509TrustManager interface. The extended variant performs hostname verification independently of the Netty wrapping logic. 3) Run on Java 24 or earlier — The vulnerable code path only triggers on Java 25+ where sun.misc.Unsafe-based trust-manager wrapping is unavailable. Running on earlier Java versions (e.g., Java 21 LTS) means the wrapping works correctly and hostname verification stays enabled. 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. Workaround: Red Hat recommends upgrading to a fixed version as the primary remediation. Where an immediate upgrade is not possible, restrict network access so that only trusted DNS servers and trusted network peers can send DNS traffic to the affected application, using firewall or network policy rules to block or rate-limit DNS traffic from untrusted sources. This reduces exposure to the malformed DNS records that trigger the issue but does not fully eliminate it; upgrading remains the only complete fix. Workaround: Ensure that the configured publicPath always ends with a trailing slash (e.g., '/assets/'), or utilize the default setting ('auto'), which resolves to '/' and is unmitigated by default. Alternatively, avoid backing the middleware with a physical filesystem (writeToDisk: false).

🔗 References (20)