Red Hat Security Advisory: Streams for Apache Kafka 3.2.1 release and security update

🔗 CVE IDs covered (58)

📋 Description

🎯 Affected products1

• Streams for Apache Kafka 3.2.1

✅ 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: 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 issue, configure applications utilizing Vert.x HttpClient to strictly validate and restrict the URLs to which HTTP requests can be redirected. Implement allowlists for trusted domains and ensure that any user-supplied or external URLs processed by Vert.x HttpClient are thoroughly sanitized and validated to prevent redirection to attacker-controlled destinations. This may involve updating application-specific configurations or implementing custom URL validation logic. A service restart or reload may be required for changes to take effect. Workaround: A flaw was found in the Go standard library crypto/x509 package. When verifying a TLS certificate hostname, VerifyHostname processed each DNS Subject Alternative Name (SAN) entry in a loop and repeatedly split the candidate hostname on "." characters. For certificates with a very large DNS SAN list, CPU use could grow quadratically with the number of SAN entries and hostname labels. Because hostname verification runs before the certificate chain is built, this overhead can occur even when the certificate is not trusted. Red Hat rates this issue as Important. It affects Red Hat products that include the Go standard library crypto/x509 code from an affected Go toolchain version (before Go 1.25.11, or from Go 1.26.0 through Go 1.26.3). Applications and container images built with a fixed Go release (1.25.11 or later, or 1.26.4 or later) are not affected. Community distributions such as Fedora are also affected. Upstream fix: Go 1.25.11 and Go 1.26.4 (GO-2026-5037). Workaround: To mitigate this issue, applications can be configured to use the pure Go DNS resolver instead of the `cgo` DNS resolver. This can be achieved by setting the `GODEBUG` environment variable to `netdns=go`. For example, to run a Go application with this mitigation: `GODEBUG=netdns=go /path/to/your/go/application`. This change may require restarting affected applications or services to take effect. Users should verify that this change does not negatively impact DNS resolution for their specific application environment. 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: Upgrade to a fixed golang.org/x/net release that includes the idna correction, via updated golang or dependent package rebuilds. Workaround: To mitigate this issue, configure a reverse proxy or load balancer in front of the Quarkus application to normalize incoming URL paths by stripping matrix parameters (semicolons) before requests reach the Quarkus security layer. This ensures that authorization checks are performed on the intended path. Ensure that any changes to proxy configurations are thoroughly tested and services are reloaded or restarted as necessary to apply the new settings. Workaround: To mitigate this issue, restrict network access to services exposing Micrometer's gRPC endpoints to trusted clients only. Implement firewall rules to limit inbound connections to the specific ports used by gRPC. If gRPC functionality is not essential for the deployment, consider disabling it entirely to eliminate the attack vector. Any changes to network configurations or service settings may require a service restart to take effect, potentially impacting availability during the transition. Workaround: To mitigate this issue, restrict network access to services that process MIME headers from untrusted sources. Implement input validation and sanitization for all incoming data, especially MIME headers, to prevent maliciously crafted content from being processed by applications utilizing the vulnerable Golang MIME package. 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 to version 2.18.8, 2.21.4, or 3.1.4 or later to address this vulnerability. If upgrading is not immediately possible, remove BasicPolymorphicTypeValidator.Builder.allowIfSubTypeIsArray() from the application’s ObjectMapper configuration to eliminate the affected deserialization path. Rebuild and restart the application to apply the configuration change. As an additional mitigation, disable polymorphic deserialization of untrusted data where possible by avoiding or removing default typing features such as activateDefaultTyping() or enableDefaultTyping(). When polymorphic deserialization is required, restrict allowed subtypes using a strict whitelist of trusted application packages and avoid broad or permissive type validation rules. Workaround: For users who cannot upgrade immediately, deploy a Kubernetes admission policy agent (such as Kyverno or OPA Gatekeeper) to block or restrict the use of the `watchedNamespace` field in Kafka custom resources (`Kafka.spec.entityOperator.userOperator.watchedNamespace` and `Kafka.spec.entityOperator.topicOperator.watchedNamespace`). Additionally, audit existing Kafka custom resources for unexpected `watchedNamespace` configurations and review RoleBindings in sensitive namespaces. 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: To reduce exposure, restrict the processing of untrusted YAML documents by applications that rely on `js-yaml`. Implement robust input validation and sanitization for all YAML data originating from external or untrusted sources. Consider limiting network access to services that parse YAML content to trusted networks or clients through appropriate firewall configurations. Workaround: Pass map: false when invoking PostCSS to disable source map auto-loading. This prevents the path traversal from being triggered, though it removes source map support entirely.

🔗 References (3)

• selfhttps://access.redhat.com/errata/RHSA-2026:54435
• externalhttps://access.redhat.com/security/updates/classification/#important
• selfhttps://security.access.redhat.com/data/csaf/v2/advisories/2026/rhsa-2026_54435.json