Red Hat Security Advisory: cert-manager Operator for Red Hat OpenShift 1.19.2
🔗 CVE IDs covered (16)
📋 Description
CVE-2026-1965 — curl: curl: Authentication bypass due to incorrect connection reuse with Negotiate authentication CVE-2026-3783 — curl: curl: Information disclosure via OAuth2 bearer token leakage during HTTP(S) redirect CVE-2026-8286 — curl: curl: Insecure connection establishment due to TLS configuration mismatch CVE-2026-9547 — curl: curl: Man-in-the-middle attack via SSH host key bypass CVE-2026-11822 — sqlite: SQLite: Arbitrary code execution via crafted FTS5 full-text search data CVE-2026-11824 — sqlite: SQLite: Arbitrary code execution and crash via heap-based buffer overflow in FTS5 CVE-2026-15588 — GDBusServer: glib2: GDBusServer pre-authentication DoS via unbounded SASL line buffering CVE-2026-29181 — github.com/open-telemetry/opentelemetry-go: OpenTelemetry-Go: Denial of Service via crafted multi-value baggage headers CVE-2026-39883 — github.com/open-telemetry/opentelemetry-go: OpenTelemetry-Go: Arbitrary code execution via PATH hijacking on BSD/Solaris CVE-2026-58010 — glib: buffer over-read in glib/gvariant-serialiser.c via gvs_tuple_is_normal() CVE-2026-58011 — glib: out-of-bounds read in glib/gdatetime.c:g_date_time_get_ymd via invalid GDateTime CVE-2026-58012 — glib: buffer over-read in g_regex_replace() via glib/gregex.c:string_append() and g_utf8_next_char() CVE-2026-58013 — glib: buffer over-read in glib/giochannel.c via "g_io_channel_read_line_backend" CVE-2026-58014 — glib: off-by-one error in glib/gkeyfile.c via "g_key_file_get_locale_string_list" CVE-2026-58015 — glib: path traversal in glib/gio/gdbusauthmechanismsha1.c via keyring_lookup_entry and mechanism_client_data_receive CVE-2026-58055 — nghttp2: nghttp2: HTTP Request/Response Smuggling and Response-Queue Poisoning via ambiguous HTTP/1.1 Upgrade requests
🎯 Affected products5
- Cert Manager support for Red Hat OpenShift release 1.19
- registry.redhat.io/cert-manager/cert-manager-istio-csr-rhel9@sha256:a5b8d2a99391fa45f9090f5cab9ef209ee3ddff67abb3104766241dbaf9e64ad_amd64 as a component of Cert Manager support for Red Hat OpenShift release 1.19
- registry.redhat.io/cert-manager/cert-manager-istio-csr-rhel9@sha256:b0740f7ce0a67df00fbfad64180c4693c7a49af844b3ba4c3a10146c711fc06e_s390x as a component of Cert Manager support for Red Hat OpenShift release 1.19
- registry.redhat.io/cert-manager/cert-manager-istio-csr-rhel9@sha256:d1d6e21ee1786ffa991bb1780cae3a17a3d9396ddea4e5c4eccb29fd5cac2ca7_arm64 as a component of Cert Manager support for Red Hat OpenShift release 1.19
- registry.redhat.io/cert-manager/cert-manager-istio-csr-rhel9@sha256:f8bebf6f267ea510545764940d2cc260b9631a7b2d5be4066e1ccc84eb7429ea_ppc64le 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: 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 prevent the leakage of OAuth2 bearer tokens, ensure that `.netrc` files are carefully managed. Avoid configuring `.netrc` entries for untrusted or unknown hostnames, particularly when `curl` is used with OAuth2 bearer tokens and is configured to follow redirects. Regularly review and restrict the scope of credentials stored in `.netrc` files to only explicitly trusted destinations. 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, in applications processing user-supplied dates, implement input validation to ensure the supplied date is within the supported range before calling g_date_time_add_full() with untrusted data, specifically rejecting inputs that result in a negative or zero days field. Workaround: To mitigate this vulnerability, implement strict input validation to sanitize user-supplied replacement strings, specifically rejecting or escaping case-change modifiers (\u, \l, \U, \L) before calling g_regex_replace() or g_regex_replace_eval() when the G_REGEX_RAW compile flag is used. Removing the G_REGEX_RAW flag or hardcoding the replacement strings will completely neutralize this issue. Workaround: To mitigate this vulnerability, restrict any custom line terminator string passed to g_io_channel_set_line_term() to a maximum length of one byte before calling g_io_channel_read_line_backend(). Using the default line terminators will completely neutralize this issue. Workaround: To mitigate this vulnerability, implement input validation to sanitize untrusted key files (such as .desktop or .ini files), specifically rejecting or stripping empty values before calling g_key_file_get_locale_string_list(). Alternatively, restricting the application to only load key files from trusted sources will completely neutralize this issue. Workaround: To mitigate this vulnerability, ensure that applications only connect to trusted D-Bus servers and operate within secure, isolated networks to prevent man-in-the-middle (MitM) attacks. If feasible, configuring the D-Bus connection to strictly require the EXTERNAL authentication mechanism and disabling DBUS_COOKIE_SHA1 will completely neutralize this issue. Workaround: Configure your WAF or load balancer to drop incoming HTTP/1.1 requests that contain both Upgrade and Content-Length headers. This blocks the malformed traffic at the edge before it can reach the vulnerable proxy without impacting legitimate users.
🔗 References (20)
- selfhttps://access.redhat.com/errata/RHSA-2026:63140
- externalhttps://docs.openshift.com/container-platform/latest/security/cert_manager_operator/index.html
- externalhttps://access.redhat.com/security/cve/CVE-2026-11822
- externalhttps://access.redhat.com/security/cve/CVE-2026-11824
- externalhttps://access.redhat.com/security/cve/CVE-2026-15588
- externalhttps://access.redhat.com/security/cve/CVE-2026-1965
- externalhttps://access.redhat.com/security/cve/CVE-2026-29181
- externalhttps://access.redhat.com/security/cve/CVE-2026-3783
- externalhttps://access.redhat.com/security/cve/CVE-2026-39883
- externalhttps://access.redhat.com/security/cve/CVE-2026-58010
- externalhttps://access.redhat.com/security/cve/CVE-2026-58011
- externalhttps://access.redhat.com/security/cve/CVE-2026-58012
- externalhttps://access.redhat.com/security/cve/CVE-2026-58013
- externalhttps://access.redhat.com/security/cve/CVE-2026-58014
- externalhttps://access.redhat.com/security/cve/CVE-2026-58015
- externalhttps://access.redhat.com/security/cve/CVE-2026-58055
- externalhttps://access.redhat.com/security/cve/CVE-2026-8286
- externalhttps://access.redhat.com/security/cve/CVE-2026-9547
- externalhttps://access.redhat.com/security/updates/classification/
- selfhttps://security.access.redhat.com/data/csaf/v2/advisories/2026/rhsa-2026_63140.json