RHSA-2026:54531HighCVSS 9.1

Red Hat Security Advisory: cert-manager Operator for Red Hat OpenShift 1.19.1

Published
August 13, 2026
Last Modified
August 21, 2026

🔗 CVE IDs covered (13)

CVE-2026-39830 →CVE-2026-42502 →CVE-2026-46595 →CVE-2026-46597 →CVE-2026-25681 →CVE-2026-27136 →CVE-2026-33186 →CVE-2026-39828 →CVE-2026-42499 →CVE-2026-42504 →CVE-2026-27145 →CVE-2026-39820 →CVE-2026-39821 →

📋 Description

CVE-2026-25681 — golang.org/x/net/html: golang.org/x/net/html: Arbitrary code execution via Cross-Site Scripting 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-33186 — google.golang.org/grpc/grpc-go: google.golang.org/grpc/authz: gRPC-Go: Authorization bypass due to improper HTTP/2 path validation CVE-2026-39820 — net/mail: golang: Go net/mail: Denial of Service via crafted email inputs CVE-2026-39821 — golang.org/x/net/idna: golang: net/http: golang.org/x/net/idna: Privilege escalation via incorrect Punycode label processing CVE-2026-39828 — golang.org/x/crypto/ssh: golang.org/x/crypto/ssh: Unauthorized command execution via discarded SSH permissions CVE-2026-39830 — golang.org/x/crypto/ssh: golang.org/x/crypto/ssh: Denial of Service via resource leak from unsolicited SSH responses CVE-2026-42499 — net/mail: golang: net/mail: Denial of Service via pathological email address parsing CVE-2026-42502 — golang.org/x/net/html: golang: golang.org/x/net/html: Cross-Site Scripting via unexpected HTML tree rendering CVE-2026-42504 — mime: golang: Golang MIME: Denial of Service via maliciously-crafted MIME header CVE-2026-46595 — golang.org/x/crypto/ssh: golang.org/x/crypto/ssh: Authorization bypass due to skipped source-address validation CVE-2026-46597 — golang.org/x/crypto/ssh: golang.org/x/crypto/ssh: Denial of Service via crafted AES-GCM packet decoder inputs

🎯 Affected products9

  • Cert Manager support for Red Hat OpenShift release 1.19
  • registry.redhat.io/cert-manager/jetstack-cert-manager-acmesolver-rhel9@sha256:0e4493d95443c137e4fe2e5b81cdf3d6a9b7b5d74c9162c3f32909a331dc07f2_amd64 as a component of Cert Manager support for Red Hat OpenShift release 1.19
  • registry.redhat.io/cert-manager/jetstack-cert-manager-acmesolver-rhel9@sha256:5074228e3df2095b082e468b4c99d285203313133e208ca1893b2ae966fbee90_arm64 as a component of Cert Manager support for Red Hat OpenShift release 1.19
  • registry.redhat.io/cert-manager/jetstack-cert-manager-acmesolver-rhel9@sha256:a16ba6a9cb55a5c6e0743cf8d38742c346c22518e02c1e045b017bed380863b6_ppc64le as a component of Cert Manager support for Red Hat OpenShift release 1.19
  • registry.redhat.io/cert-manager/jetstack-cert-manager-acmesolver-rhel9@sha256:b574ad0711134be333ae87c25dcc910c5f4847ce454779eda9ea0125230777f3_s390x as a component of Cert Manager support for Red Hat OpenShift release 1.19
  • registry.redhat.io/cert-manager/jetstack-cert-manager-rhel9@sha256:60f97a1218b94ccb0e21bb5677bf906be3369b79ff81fa35050de1f4385027da_ppc64le as a component of Cert Manager support for Red Hat OpenShift release 1.19
  • registry.redhat.io/cert-manager/jetstack-cert-manager-rhel9@sha256:6dd44adc300558e1a9bee074347bc394e9335de4cab7ca3a32cc8a403cdad5dd_s390x as a component of Cert Manager support for Red Hat OpenShift release 1.19
  • registry.redhat.io/cert-manager/jetstack-cert-manager-rhel9@sha256:79091d478d6c09140474f2707e4dad555f393c9bdc866d567265b747ad7cc9a4_arm64 as a component of Cert Manager support for Red Hat OpenShift release 1.19
  • registry.redhat.io/cert-manager/jetstack-cert-manager-rhel9@sha256:82461a011b7698c367b21a0866ac8c73a44fb3d5f21527cb34ed1495383207c2_amd64 as a component of Cert Manager support for Red Hat OpenShift release 1.19

✅ Remediation

Before applying this update, make sure all previously released errata relevant to your system have been applied. The steps to apply the upgraded images are different depending on the installation plan approval policy you used when installing the cert-manager Operator for Red Hat OpenShift. - If the approval policy is set to `Automatic`, then the Operator will be upgraded automatically when there is a new version of the Operator. No further action is required to upgrade. This is the default setting. - If you changed the approval policy to `Manual`, then you must manually approve the upgrade to the Operator. See https://docs.openshift.com/container-platform/latest/security/cert_manager_operator/index.html for additional information. Workaround: To mitigate this flaw, applications processing untrusted HTML input must implement strict input sanitization and ensure all output is properly encoded before rendering. Deploying a comprehensive Content Security Policy (CSP) can restrict script execution, further reducing the attack surface. Administrators should review application configurations to ensure adequate protection against XSS. 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: 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, implement infrastructure-level normalization to ensure all incoming HTTP/2 `:path` headers are properly formatted with a leading slash before reaching the gRPC-Go server. This can be achieved by configuring a reverse proxy or API gateway to validate and normalize the `:path` header. Ensure that any such intermediary is properly configured and restarted to apply the changes, which may temporarily impact service availability. 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 denial of service vulnerability, restrict network access to any service that utilizes the `golang.org/x/crypto/ssh` library and is exposed to untrusted networks. Implement firewall rules to allow connections only from trusted hosts or networks. This action limits the ability of malicious peers to send unsolicited global request responses. A restart of the affected service may be necessary for the new network rules to be applied effectively. 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 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: Upgrade to a fixed golang.org/x/crypto/ssh release via updated golang or package rebuilds. Ensure SSH servers use supported public-key callback configurations with source-address validation as intended.

🔗 References (17)