RHSA-2026:59559HighCVSS 9.9

Red Hat Security Advisory: multicluster engine for Kubernetes v2.9.7 security update

Published
August 25, 2026
Last Modified
August 26, 2026

🔗 CVE IDs covered (31)

CVE-2026-73086 →CVE-2024-45336 →CVE-2026-27136 →CVE-2026-33811 →CVE-2026-54272 →CVE-2026-69192 →CVE-2025-22866 →CVE-2026-39831 →CVE-2026-42502 →CVE-2026-47219 →CVE-2026-66808 →CVE-2026-67213 →CVE-2026-67214 →CVE-2026-73266 →CVE-2026-59869 →CVE-2026-73268 →CVE-2026-19130 →CVE-2026-39829 →CVE-2026-46597 →CVE-2026-66804 →CVE-2026-69153 →CVE-2026-73267 →CVE-2026-73269 →CVE-2026-44740 →CVE-2026-10059 →CVE-2026-27145 →CVE-2026-66794 →CVE-2026-66795 →CVE-2026-66805 →CVE-2026-12143 →CVE-2026-45623 →

📋 Description

CVE-2024-45336 — golang: net/http: net/http: sensitive headers incorrectly sent after cross-domain redirect CVE-2025-22866 — crypto/internal/nistec: golang: Timing sidechannel for P-256 on ppc64le in crypto/internal/nistec CVE-2026-10059 — cluster-curator-controller: cluster-curator-controller: namespace admin can escalate to cluster-wide curator authority via ClusterCurator ServiceAccount token CVE-2026-12143 — form-data: form-data: Form field override via CRLF injection CVE-2026-19130 — provider-credential-controller: provider-credential-controller: cross-namespace credential propagation via attacker-controlled copiedFrom labels bypasses authorization CVE-2026-27136 — golang.org/x/net/html: golang: golang.org/x/net/html: Cross-Site Scripting via HTML parsing bypass CVE-2026-27145 — crypto/x509: golang: golang crypto/x509: Denial of Service via excessive processing of DNS SAN entries CVE-2026-33811 — net: golang: Go net package: Denial of Service via long CNAME response in LookupCNAME CVE-2026-39829 — golang.org/x/crypto/ssh: golang.org/x/crypto/ssh: Denial of Service via crafted public key with excessive parameters CVE-2026-39831 — golang.org/x/crypto/ssh: golang.org/x/crypto/ssh: Security key bypass due to missing user presence check CVE-2026-42502 — golang.org/x/net/html: golang: golang.org/x/net/html: Cross-Site Scripting via unexpected HTML tree rendering CVE-2026-44740 — github.com/go-git/go-billy: Billy: Denial of Service via crafted input due to insufficient validation CVE-2026-45623 — postcss: PostCSS: Information disclosure and denial of service via crafted CSS input CVE-2026-46597 — golang.org/x/crypto/ssh: golang.org/x/crypto/ssh: Denial of Service via crafted AES-GCM packet decoder inputs CVE-2026-47219 — find-my-way: find-my-way: Denial of Service vulnerability in HTTP/2 server CVE-2026-54272 — ip-address: ip-address: Server-Side Request Forgery via IPv4-mapped/NAT64 IPv6 address misclassification CVE-2026-59869 — js-yaml: js-yaml: Denial of Service via crafted YAML documents CVE-2026-66794 — cluster-proxy-addon: cluster-proxy-addon: unauthenticated SSRF to arbitrary managed-cluster services via public Route CVE-2026-66795 — managedcluster-import-controller: managedcluster-import-controller: CSR auto-approver does not validate certificate Subject, signerName, or requester identity CVE-2026-66804 — console: console: authenticated SSRF via /ansibletower allows arbitrary host access with full response disclosure CVE-2026-66805 — console: console: stored DOM XSS via unescaped pod logs in document.write CVE-2026-66808 — hypershift-addon-operator: hypershift-addon-operator: unsanitized hub ConfigMap data passed as CLI arguments to privileged install Job (argument injection) CVE-2026-67213 — nanoid: nanoid: Denial of Service via infinite loop in random ID generation CVE-2026-67214 — nanoid: nanoid: Denial of Service via negative size input in non-secure module functions CVE-2026-69153 — postcss: PostCSS: Information disclosure via crafted sourceMappingURL CVE-2026-69192 — ip-address: ip-address: Inconsistent IP address parsing leads to Server-Side Request Forgery (SSRF) and trust-boundary bypass CVE-2026-73086 — nanoid: nanoid: Predictable ID generation due to integer overflow CVE-2026-73266 — clusterclaims-controller: clusterclaims-controller: tenant-controlled ClusterClaim labels propagated to ManagedCluster enabling cross-tenant ManagedClusterSet join CVE-2026-73267 — clusterclaims-controller: clusterclaims-controller: ManagedCluster deletion keyed solely on ClusterClaim.Spec.Namespace with no ownership check CVE-2026-73268 — cluster-curator-controller: cluster-curator-controller: spec.install.overrideJob allows arbitrary Job spec injection CVE-2026-73269 — cluster-curator-controller: cluster-curator-controller: tenant-controllable trigger creates ClusterRoleBinding granting cluster-wide secrets access to namespace-local SA

🎯 Affected products121

  • multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/addon-manager-rhel9@sha256:1a4b539f906040524f20d4afe9ebed65a0b24f901ea281ae869d6a8d99409698_ppc64le as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/addon-manager-rhel9@sha256:45985b45748ae291d47aa64078fffc8dab0e8bfda806b9939625ad774e6b3ef4_amd64 as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/addon-manager-rhel9@sha256:cc7013d30b2b83c31af89ce47b4c4efe09ec261d6d7ff12ee771edd76178eb40_arm64 as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/addon-manager-rhel9@sha256:e01aeb18f0cbde8820e33110b3a84658eb3499c92ab98cdc303bec63c6aac61f_s390x as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/backplane-rhel9-operator@sha256:3995afe31f150073f193fe13ef0929d648d82bc8a26c21a3164de4cebcf29d8a_s390x as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/backplane-rhel9-operator@sha256:60024dbb8bfd8806948b3a55e3249939a37550cdc956cafdef213148883d8f0e_amd64 as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/backplane-rhel9-operator@sha256:63494e538df04d6cd40eb5796801255706114ea08fd75b4922512bad206bbb22_arm64 as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/backplane-rhel9-operator@sha256:b30a771171c2196261dbb44c07daeb77e2c4ce0bc563fb2a796bc2a17a0a6b3d_ppc64le as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/capoa-bootstrap-rhel9@sha256:7c777cb8bb9817687a5358f3cdd1586004f611c26662d3f49ef13915f837bdcd_arm64 as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/capoa-bootstrap-rhel9@sha256:99074f3627b1673def8fa6c18692c31b845026d936d63a84fb84f51321188d15_amd64 as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/capoa-bootstrap-rhel9@sha256:b61e9d64de43a20c9cfbfb364bb8e3496006798eb13b57dd3face70404d79ea0_s390x as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/capoa-bootstrap-rhel9@sha256:ced32449a6b1f022ee0f28c74083d693870d932930c071a600d09ca50afb6edd_ppc64le as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/capoa-control-plane-rhel9@sha256:053a61ec8e0729be31362e335d720d6bc81591eb290fd59e3df13faf4f5f2fae_arm64 as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/capoa-control-plane-rhel9@sha256:2686a921f4ef6226bab2c2972db6acc2f231ffc294845ba024ae2bddd9538ffd_amd64 as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/capoa-control-plane-rhel9@sha256:5fa09497a00c910a08d32caac06e89affcabad9764be636fc2c580df77d4a795_s390x as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/capoa-control-plane-rhel9@sha256:60128db2df92e5703db2d51c74a8be50eb4a9d0db4ac8dbd174ff9143077d175_ppc64le as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/cluster-api-provider-agent-rhel9@sha256:33cf56d43b468b4f570ee8f8c0983657066295aed8de4ac73fb9798508576230_s390x as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/cluster-api-provider-agent-rhel9@sha256:5ca3f5c58494399feb8951f75cdc7df3f39569476948343afb996bc7aa952244_amd64 as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/cluster-api-provider-agent-rhel9@sha256:7413a8d2294042646a0bd67dbe1108d711649af218439f2047822c1895620eb8_ppc64le as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/cluster-api-provider-agent-rhel9@sha256:bc2cc86003213e2adf2ab1d0ba6430c4fc352d9b807ba5802409748efb8778c5_arm64 as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/cluster-api-provider-kubevirt-rhel9@sha256:19aa52d6b60f40297a4406b92832bb67bd8ddd94f47a64b9b2e27e57dfcccd13_amd64 as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/cluster-api-provider-kubevirt-rhel9@sha256:47ebcd5f56ea619facf43b3bc28affd8e6455085ca3bc03f8003f47cd69aa7cf_s390x as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/cluster-api-provider-kubevirt-rhel9@sha256:942cb26bbdd64fedbc3ea93b0948be6c07d0452d8c7b7bdf4b557a58ccd3329a_ppc64le as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/cluster-api-provider-kubevirt-rhel9@sha256:f30452cede0d185a8976217639e3a13b1cbbd94bdf900aed18ececeb81c88a3f_arm64 as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/cluster-curator-controller-rhel9@sha256:7cea38767a8d325bc3baefafd1845c104de88115bff509d5dc945ffb543a9f86_ppc64le as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/cluster-curator-controller-rhel9@sha256:8430a5c05f5bd902fe241a06b9b354e2c0a6d1f14176c29d6b0e096173bcb2be_s390x as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/cluster-curator-controller-rhel9@sha256:c70617a156df7c8ae7bc096e54ac450d2aa03f0d79bfd524387d5b95926b4b6d_arm64 as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/cluster-curator-controller-rhel9@sha256:c732c25aedb88b7390b4e98796cf0d5e9ff926dfec95067065630ecdb977b70c_amd64 as a component of multicluster engine for Kubernetes 2.9
  • registry.redhat.io/multicluster-engine/cluster-image-set-controller-rhel9@sha256:5f296c7fe1dbe297110de3cf18b0acd795618ddc56c1aa28f6cbc206283cd97c_s390x as a component of multicluster engine for Kubernetes 2.9
  • +91 more not shown

✅ Remediation

For multicluster engine for Kubernetes, see the following documentation for details on how to install the images: https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.14/html/clusters/cluster_mce_overview#mce-install-intro 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: Applications using the `form-data` library should implement strict input validation and sanitization for all field names and filenames derived from untrusted sources. This prevents the injection of control characters (CR, LF, ") that could lead to header injection or form field overrides. Deployments that exclusively use fixed or trusted field names are not impacted. 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: Applications utilizing `golang.org/x/net/html` should implement robust sanitization of all untrusted HTML input before rendering to prevent the creation of unexpected HTML structures that could facilitate XSS attacks. If an application does not require rendering arbitrary HTML, it should avoid processing such input. Workaround: To mitigate the issue, we suggest upgrading to versions 5.9.0+ or 6.0.0-alpha.1+ Workaround: There is no available mitigation for this flaw other than updating the bundled find-my-way library to a fixed version (9.7.0 or later). Where feasible, restricting the affected service to HTTP/1.1 (disabling HTTP/2) removes the attack vector, since the flaw is only reachable through the HTTP/2 request path. 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: To mitigate this issue, restrict network access to the user-facing Route of the `cluster-proxy-addon` to trusted networks only. Implement firewall rules to limit inbound connections to the Route's exposed port, ensuring only authorized sources can reach it. This reduces the attack surface by preventing unauthenticated external access to the vulnerable proxy. Workaround: To reduce the risk of exploitation, ensure strict access controls are enforced on managed clusters, limiting the ability of untrusted users to deploy or modify pods and thus inject malicious content into container logs. Additionally, users should exercise caution when viewing "Raw" logs from potentially untrusted sources within the hub console. Workaround: To mitigate this issue, ensure application code validates the size parameter passed to customAlphabet or customRandom, rejecting or sanitizing zero-value inputs before passing them to nanoid. Workaround: Sanitize all user-supplied integer inputs before passing them to `nanoid` or `customAlphabet` functions in the `nanoid/non-secure` module, ensuring the size parameter is strictly a non-negative integer. 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. Workaround: To mitigate this issue, implement strict Role-Based Access Control (RBAC) policies to limit create and update permissions on `clustercurators.cluster.open-cluster-management.io` resources to trusted administrators only. This restricts the ability of less privileged tenants to exploit the vulnerability and escalate privileges within the Kubernetes environment. Workaround: To mitigate this issue, restrict the ability of tenants to create `ClusterCurator` resources. Implement Kubernetes Role-Based Access Control (RBAC) policies to limit `create` permissions for `clustercurators.cluster.open-cluster-management.io` resources to only trusted administrators or service accounts. Alternatively, deploy an admission controller to enforce that `metadata.name` and `metadata.namespace` fields are identical when `ClusterCurator` resources are created, preventing the vulnerable condition.

🔗 References (34)