Red Hat Linux Security Advisories & CVEs
13569 advisories tracked · Red Hat Security Data API · direct feeds checked every minute; rate-limited backstops use a safe source cadence
Android app · Google Play
Monitor Red Hat CVEs from your phone.
Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 34 official vendor sources and 160+ reviewed platform categories.
Security advisories for your Red Hat release
Pick your distribution release to see every advisory issued for it and its severity mix. Fixes ship as errata — keep the system patched. This is the release's advisory history, not a per-package scan.
Official source
Red Hat Security Data API
Red Hat Enterprise Linux errata (RHSA) via the official Red Hat Security Data API — CVE severity, CVSS and affected packages. A credential-free official source.
Latest Red Hat advisories
Medium [CVE-2026-68439] fix possible NULL-pointer deref in mt7925_mcu_bss_he_tlv
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix possible NULL-pointer deref in mt7925_mcu_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it. A flaw was found in the Linux kernel's Wi-Fi driver for the `mt7925` component. This vulnerability arises from a potential NULL-pointer dereference within the `mt7925_mcu_bss_he_tlv()` function. If the `mt76_connac_get_he_phy_cap` routine returns a null value, it is not properly checked before being used, which could lead to system instability or a denial of service (DoS). This issue affects systems using MediaTek mt7925 Wi-Fi hardware. mt7925_mcu_bss_he_tlv() did not check for a NULL HE PHY capabilities pointer before dereferencing it, which can cause a kernel oops. Systems without mt7925 wireless hardware are not affected. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-476. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9; Red Hat Enterprise Linux for NVIDIA 26. Red Hat lists Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat OpenShift Container Platform 4 as not affected. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-68431] validate minimum PDU size for transform requests
In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate minimum PDU size for transform requests The receive path applies the minimum SMB2 PDU size check only when ProtocolId is SMB2_PROTO_NUMBER. A packet carrying SMB2_TRANSFORM_PROTO_NUM bypasses the check even when the negotiated dialect does not provide transform handling. On an SMB 2.1 connection, a short transform packet therefore reaches init_smb2_rsp_hdr(), which interprets the request as a full SMB2 header and reads beyond the request allocation. The copied fields can then be returned to the unauthenticated client. Compression transforms are converted to ordinary SMB2 messages before protocol validation. After that conversion, validate ordinary SMB2 requests against SMB2_MIN_SUPPORTED_PDU_SIZE and require encryption transform requests to contain both a transform header and an SMB2 header. This rejects truncated requests before work allocation. When handling Server Message Block version 2 (SMB2) transform requests, the system fails to validate the minimum Protocol Data Unit (PDU) size. An unauthenticated remote attacker can send a specially crafted, short transform packet, bypassing security checks. This leads to the system reading beyond allocated memory and potentially disclosing sensitive information to the attacker. This issue affects systems running ksmbd (in-kernel SMB server).
Medium [CVE-2026-68438] Make CSD lock acquisition atomic for debug mode
In the Linux kernel, the following vulnerability has been resolved: smp: Make CSD lock acquisition atomic for debug mode Commit b0473dcd4b1d ("smp: Improve smp_call_function_single() CSD-lock diagnostics") changed smp_call_function_single() so that, when CSD lock debugging is enabled, async!wait calls use the destination CPU csd_data. That improves diagnostics, but it also removes the single-writer property that made the old csd_lock() safe: multiple CPUs can now prepare the same destination CPU CSD concurrently. csd_lock() currently waits for CSD_FLAG_LOCK to clear and then sets the bit with a non-atomic read-modify-write. Two senders can both see an unlocked CSD, set the bit, overwrite the callback fields, and enqueue the same llist node. Re-adding a node that is already the queue head can make node->next point to itself, leaving the target CPU stuck walking call_single_queue. Later synchronous work, such as a TLB shootdown, can then remain queued and trigger soft-lockup warnings or panics. Keep the single csd_lock() implementation, but when CSD lock debugging is enabled, acquire CSD_FLAG_LOCK with try_cmpxchg_acquire(). This makes the destination CPU CSD a real atomic lock in the only configuration where it can be shared by multiple remote senders, while preserving the existing non-debug fast path.
Medium [CVE-2026-68433] bound get_version reply decode to front len
In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire. This vulnerability occurs because the system incorrectly processes replies, using an allocated buffer size rather than the actual received data length. A specially crafted, truncated reply can lead to the system reading uninitialized memory. This could result in the disclosure of sensitive information or cause system instability. This issue affects systems using the in-kernel Ceph client (libceph). MON_GET_VERSION_REPLY decoding used the allocated buffer size instead of received length, allowing stale tail bytes to be read on truncated replies from the monitor. Systems without Ceph are not affected. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-125.
Medium [CVE-2026-68440] fix heap overflow when reading module EEPROM
In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix heap overflow when reading module EEPROM txgbe_read_eeprom_hostif() always copies round_up(length, 4) bytes into the caller buffer, which ethtool allocates with exactly 'length' bytes. A non-4-aligned length therefore causes an out-of-bounds write. Copy only the remaining bytes on the final dword instead. A flaw was found in the Linux kernel's txgbe network driver. When reading module EEPROM (Electrically Erasable Programmable Read-Only Memory), the txgbe_read_eeprom_hostif() function can attempt to copy more data than the allocated buffer size if the data length is not a multiple of four. This out-of-bounds write can lead to memory corruption, potentially causing system instability or a denial of service. This issue affects Wangxun txgbe network adapters. ethtool EEPROM reads with non-4-byte-aligned lengths cause txgbe_read_eeprom_hostif() to write past the caller buffer. Systems without txgbe hardware are not affected. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-787. Red Hat lists Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat Enterprise Linux for NVIDIA 26; Red Hat OpenShift Container Platform 4 as not affected.
Medium [CVE-2026-68445] Prevent shader BO mappings from becoming writable
In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Prevent shader BO mappings from becoming writable vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects. This vulnerability allows a local user to bypass security validation for shader code. By manipulating memory permissions, an attacker could modify shader instructions after they have been deemed safe, potentially leading to unauthorized code execution. This issue affects Raspberry Pi and other systems using the vc4 DRM driver. Validated shader buffer objects reject writable mmap but leave VM_MAYWRITE set, allowing mprotect() to make shader code writable after GPU validation. Systems without vc4 hardware are not affected. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-179.
Medium [CVE-2026-68434] Fix NULL function pointer dereference on DNV/ICX-D/SNR platforms
In the Linux kernel, the following vulnerability has been resolved: serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR platforms Commit b1b4efea05a5 ("serial: 8250_mid: Disable DMA for selected platforms") replaced the dnv_board setup and exit callbacks with PTR_IF(false,...), which evaluates to NULL. However, the three call sites in mid8250_probe() and mid8250_remove() unconditionally dereference these function pointers without NULL checks, causing a NULL pointer dereference (kernel oops) on any Denverton (DNV), Ice Lake Xeon D (ICX-D/CDF), or Snowridge (SNR) platform. This vulnerability occurs due to missing NULL checks before calling setup and exit callbacks, which can result in a NULL pointer dereference. A local attacker could exploit this flaw to cause a kernel oops, leading to a Denial of Service (DoS) on affected Denverton, Ice Lake Xeon D, or Snowridge platforms. Setup and exit callbacks were set to NULL but are dereferenced unconditionally during probe/remove, causing a kernel oops. Other platforms using 8250_mid are not affected. Red Hat severity: Low — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-476. Affected Red Hat products: Red Hat Enterprise Linux 8; Red Hat OpenShift Container Platform 4. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-68441] Handle TC_ACT_REDIRECT from qdisc filter chains
In the Linux kernel, the following vulnerability has been resolved: net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains When a TC filter attached to a qdisc filter chain returns TC_ACT_REDIRECT (ex: via an eBPF program calling bpf_redirect() or an act_bpf action), the redirect was silently lost i.e no qdisc classify function handled TC_ACT_REDIRECT, so the packet fell through the switch and was enqueued normally instead of being redirected. This has been broken since bpf_redirect() was introduced for TC in commit 27b29f63058d ("bpf: add bpf_redirect() helper"). We got lucky for a long time because bpf_net_context was a per-CPU variable that was always available. commit 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.") turned bpf_net_context into a task_struct member that is only set up by explicit callers. Without a caller setting it up, bpf_redirect() itself crashes with a NULL pointer dereference in bpf_net_ctx_get_ri(). However, even with bpf_net_context available, TC_ACT_REDIRECT from qdisc filter chains cannot be honored without adding skb_do_redirect() calls to every qdisc classify function, which would require changes across net/sched/. Isolate it to ebpf core where it belongs.
Medium [CVE-2026-68435] Fix address space mismatch in kexec command line lookup
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Fix address space mismatch in kexec command line lookup When searching the loaded segments for the "kexec" command line marker, the kexec_load(2) path (file_mode == 0) passes the user-space segment buffer straight to strncmp() through a bogus (char __user *) cast. This dereferences a user pointer in kernel context, which is wrong and is flagged by sparse: arch/loongarch/kernel/machine_kexec.c:84:51: sparse: incorrect type in argument 2 (different address spaces) @@ expected char const * @@ got char [noderef] __user * Here copy the marker-sized prefix of each segment into a small on-stack buffer with copy_from_user() before comparing, and skip segments that fault. The subsequent copy_from_user() that stages the full command line into the safe area is left unchanged. A local attacker could exploit this by using the `kexec_load` system call, which incorrectly passes a user-space segment buffer to a kernel function without proper validation. This improper handling leads to dereferencing a user pointer in kernel context, potentially resulting in a denial of service or information disclosure. This issue affects LoongArch systems using kexec_load(). Systems not using LoongArch are not affected. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-822.
Medium [CVE-2026-68444] Fix NULL dereference in ffa_partition_info_get
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc: uuid_parse+0x40/0xac | lr: ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input. A local attacker or malicious process could exploit this vulnerability by providing a NULL argument to the `ffa_partition_info_get()` function. This missing NULL check leads to a NULL pointer dereference, causing a kernel panic and resulting in a Denial of Service (DoS) for the affected system. This issue affects ARM systems using FF-A (Firmware Framework for Arm). ffa_partition_info_get() passes a NULL uuid_str to uuid_parse() without validation, causing kernel panic. Callers must pass valid UUID strings; systems without FF-A are not affected. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-476.
Medium [CVE-2026-68437] Fit paired fragment job in the correct CCCB
In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fit paired fragment job in the correct CCCB For geometry jobs with a paired fragment job, at the moment, the DRM scheduler's prepare_job() callback: - checks for internal (driver) dependencies for the geometry job; - calls into pvr_queue_get_paired_frag_job_dep() to check for external dependencies for the fragment job (the two jobs are submitted together but the common scheduler code doesn't know about it, so this needs to be done at this point in time); - calls into the prepare_job() callback again, but for the fragment job, to check its internal dependencies as well, passing the fragment job's drm_sched_job and the geometry job's drm_sched_entity / pvr_queue. The problem with the last step is that pvr_queue_prepare_job() doesn't always take the mismatched fragment job and geometry queue into account, in particular when checking whether there is space for the fragment command to be submitted, so the code ends up checking for space in the geometry (i.e. wrong) CCCB. The rest of the nested prepare_job() callback happens to work fine at the moment as the other internal dependencies are not relevant for a paired fragment job. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux for NVIDIA 26; Red Hat package: kernel.
Medium [CVE-2026-68443] (gigabyte_waterforce) Stop device IO before calling hid_hw_stop
In the Linux kernel, the following vulnerability has been resolved: hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after "io start" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). A race condition exists because `hid_hw_stop()` does not properly stop device I/O. This can occur during a driver probe failure after I/O has been initiated, leading to a Use-After-Free (UAF) vulnerability. An attacker could potentially exploit this to achieve arbitrary code execution or cause a denial of service. This issue affects Gigabyte Waterforce AIO coolers using the gigabyte_waterforce hwmon driver. hid_hw_stop() does not stop device I/O, so probe failure after io start can race with hid_input_report() causing use-after-free. Systems without this hardware are not affected. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-825. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux for NVIDIA 26.
Medium [CVE-2026-68449] fix infinite loop in NCQ tag completion bit-scanning
In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point!(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument. This can lead to a system hang or crash, resulting in a Denial of Service (DoS). Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-835. Affected Red Hat products: Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat OpenShift Container Platform 4. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-68447] clamp v9 CRIU control stack checkpoint copy to BO size
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size CRIU checkpoint copies the MQD control stack using cp_hqd_cntl_stack_size from hardware without bounding it to the allocated BO region. If the HW field is larger than the queue's control stack allocation, memcpy reads past the BO into adjacent GTT memory and can leak kernel data to userspace. Store the page-aligned control stack BO size in mqd_manager and clamp checkpoint copies and reported checkpoint sizes to min(cp_hqd_cntl_stack_size, mm->ctl_stack_size). Apply the same bound for multi-XCC v9.4.3 checkpoint layout. (cherry picked from commit 6c2abd0ec09e86c6323010673766f76050e28aa3) The Checkpoint/Restore in Userspace (CRIU) checkpoint process, which saves and restores the state of a running application, incorrectly copies the Memory Queue Descriptor (MQD) control stack. This occurs because the copy operation does not properly limit the amount of data copied to the allocated buffer size. A local attacker could exploit this by causing the system to read beyond the intended memory region, potentially leading to the disclosure of sensitive kernel data to userspace. Red Hat severity: Moderate — CVSS 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-125.
Low [CVE-2026-73492] Arbitrary code execution due to URI scheme bypass
Loofah is a general library for manipulating and transforming HTML/XML documents and fragments, built on top of Nokogiri. From 2.25.0 until 2.25.2, Loofah::HTML5::Scrub.allowed_uri? does not reject javascript: or vbscript: URIs whose scheme is split by semicolon-less numeric character references such as:,, , or CGI.unescapeHTML leaves these references encoded, so allowed_uri? reports the URL safe even though a browser decodes an encoded colon or strips encoded whitespace and executes the resulting URI scheme. This issue affects only callers that pass HTML-encoded strings directly to allowed_uri?; Loofah's default sanitize() path is not affected. This issue is fixed in version 2.25.2. The 'allowed_uri?' function, intended to validate Uniform Resource Identifiers (URIs), does not correctly identify and reject 'javascript:' or 'vbscript:' URIs when their scheme is obscured by specific HTML-encoded numeric character references. This oversight allows a browser to decode and execute the manipulated URI, potentially leading to arbitrary code execution. This issue specifically impacts applications that directly provide HTML-encoded strings to the 'allowed_uri?' function. Red Hat severity: Low — CVSS 3.7 (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:N). Weakness: CWE-76. Affected Red Hat products: Red Hat 3scale API Management Platform 2; Red Hat Satellite 6.
Low [CVE-2026-73491] Cross-Site Scripting via malformed `javascript:` URI parsing
Loofah is a general library for manipulating and transforming HTML/XML documents and fragments, built on top of Nokogiri. From 2.25.0 until 2.25.2, Loofah::HTML5::Scrub.allowed_uri? does not reject javascript: URIs whose scheme is split or prefixed with the HTML5 named whitespace character references or CGI.unescapeHTML leaves those references intact, so allowed_uri? reports the URL safe even though a browser decodes and strips the tab or line feed and executes the resulting javascript: URL. This issue affects only callers that pass HTML-encoded strings directly to allowed_uri?; Loofah's default sanitize() path is not affected. This issue is fixed in version 2.25.2. A flaw was found in Loofah. This vulnerability allows a remote attacker to craft a malicious URI that, when processed by affected callers, is incorrectly deemed safe. Consequently, a web browser will decode and execute the embedded JavaScript code, leading to Cross-Site Scripting (XSS) and potential arbitrary code execution in the user's browser context. Red Hat severity: Low — CVSS 3.7 (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:N). Weakness: CWE-1289. Affected Red Hat products: Red Hat 3scale API Management Platform 2; Red Hat Satellite 6. Will not fix / out of support: Red Hat 3scale API Management Platform 2. Red Hat does not currently list a fixing RHSA for this CVE.
Critical [CVE-2026-73213] Server-Side Request Forgery via incorrect IPv6 comparison
Coturn is a free open source implementation of TURN and STUN Server. Prior to 4.16.0, addr_less_eq() in src/client/ns_turn_ioaddr.c uses a component-wise comparison for native IPv6 min-max intervals in ioa_addr_in_range(), allowing an authenticated TURN client to relay to an IPv6 peer that is numerically within a configured non-prefix-aligned denied-peer-ip range but is classified as outside it. This issue is fixed in version 4.16.0. A flaw was found in Coturn. An authenticated TURN client can bypass configured IP address restrictions due to an incorrect component-wise IPv6 comparison in the `addr_less_eq()` function. This allows the client to relay traffic to an IPv6 peer that should be denied, leading to a Server-Side Request Forgery (SSRF) vulnerability. Red Hat products do not ship Coturn. The community packages (Fedora, EPEL) ship Coturn 4.16.0 which includes the fix for this vulnerability. Red Hat severity: Critical — CVSS 9.9 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). Weakness: CWE-918.
Critical [CVE-2026-10579] auth bypass in Picketlink SAML unsolicited-response
A flaw was found in Picketlink Federation SAML; the unsolcited response handler would accept forged assertions with no verification or validation, permitting an unauthed attacker to authenticate as any principal in any role. This could lead to information disclosure, access to restricted operations, or other flaws. Red Hat severity: Critical — CVSS 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-347. Affected Red Hat products: Red Hat JBoss Enterprise Application Platform 7.4.25; Red Hat JBoss Enterprise Application Platform 7.4 ELS on RHEL 7; Red Hat JBoss Enterprise Application Platform 7.4 ELS on RHEL 8; Red Hat JBoss Enterprise Application Platform 7.4 ELS on RHEL 9; Red Hat JBoss Enterprise Application Platform 7. Red Hat fixing advisory: RHSA-2026:53806, RHSA-2026:53644, RHSA-2026:53645, RHSA-2026:53646.
Critical [CVE-2026-73268] spec.install.overrideJob allows arbitrary Job spec injection
A flaw was found in the cluster-curator-controller component of multicluster engine (MCE). A tenant with create or update permissions on ClusterCurator resources can inject an arbitrary Job specification. This is possible because the CreateJob() function does not validate user-controlled input when unmarshaling the spec.install.overrideJob raw extension. Successful exploitation allows the injected Job to run with the controller's elevated privileges, leading to arbitrary code execution and privilege escalation, potentially accessing cluster-wide secrets. The vulnerability stems from insufficient validation of the `spec.install.overrideJob` field, enabling injection of malicious Job specifications that run with the controller's highly privileged ServiceAccount, potentially exposing cluster-wide secrets and managed cluster access. Red Hat severity: Important — CVSS 9.9 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). Weakness: CWE-94. Affected Red Hat products: multicluster engine for Kubernetes 2.10; multicluster engine for Kubernetes 2.11; multicluster engine for Kubernetes 2.17; multicluster engine for Kubernetes 2.6; multicluster engine for Kubernetes 2.8; multicluster engine for Kubernetes 2.9. Red Hat fixing advisory: RHSA-2026:59557, RHSA-2026:59556, RHSA-2026:59593, RHSA-2026:59579, RHSA-2026:59558, RHSA-2026:59559.
Critical [CVE-2026-73269] tenant-controllable trigger creates ClusterRoleBinding granting cluster-wide secrets access to namespace-local SA
A flaw was found in the cluster-curator-controller component. A local user, by creating a ClusterCurator resource with a specific naming convention, can trigger the creation of a cluster-scoped ClusterRoleBinding. This allows the user to escalate their privileges from namespace-local access to cluster-wide control. This privilege escalation grants broad permissions, including the ability to access and manipulate secrets, manage cluster actions, and delete hosted clusters or node pools. By creating a ClusterCurator resource with a mismatched name and namespace, an attacker can gain extensive permissions, including the ability to manage secrets and delete managed clusters, bypassing existing admission controls. This poses a significant risk to the overall cluster security and data integrity within Red Hat OpenShift environments deploying MCE. Red Hat severity: Important — CVSS 9.9 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). Weakness: CWE-269. Affected Red Hat products: multicluster engine for Kubernetes 2.10; multicluster engine for Kubernetes 2.11; multicluster engine for Kubernetes 2.17; multicluster engine for Kubernetes 2.6; multicluster engine for Kubernetes 2.8; multicluster engine for Kubernetes 2.9. Red Hat fixing advisory: RHSA-2026:59557, RHSA-2026:59556, RHSA-2026:59593, RHSA-2026:59579, RHSA-2026:59558, RHSA-2026:59559.