Red Hat Linux Security Advisories & CVEs
3200 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 32 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-53060] dm cache metadata: fix memory leak on metadata abort retry
In the Linux kernel, the following vulnerability has been resolved: dm cache metadata: fix memory leak on metadata abort retry When failing to acquire the root_lock in dm_cache_metadata_abort because the block_manager is read-only, the temporary block_manager created outside the root_lock is not properly released, causing a memory leak. Reproduce steps: This can be reproduced by reloading a new table while the metadata is read-only. While the second call to dm_cache_metadata_abort is caused by lack of support for table preload in dm-cache, mentioned in commit 9b1cc9f251af ("dm cache: share cache-metadata object across inactive and active DM tables"), it exposes the memory leak in dm_cache_metadata_abort when the function is called multiple times. Specifically, dm-cache fails to sync the new cache object's mode during preresume, creating the reproducer condition. This issue could also occur through concurrent metadata_operation_failed calls due to races in cache mode updates, but the table preload scenario below provides a reliable reproducer. 1. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9.
Medium [CVE-2026-52985] zero initialize struct iphdr in dummy sk_buff
In the Linux kernel, the following vulnerability has been resolved: netdevsim: zero initialize struct iphdr in dummy sk_buff Syzbot reports a KMSAN uninit-value originating from nsim_dev_trap_skb_build, with the allocation also being performed in the same function. Fix this by calling skb_put_zero instead of skb_put to guarantee zero initialization of the whole IP header. An uninitialized memory vulnerability exists in the handling of struct iphdr within a dummy sk_buff due to the use of skb_put instead of skb_put_zero. This could lead to unpredictable system behavior, including crashes (Denial of Service), or potentially the disclosure of sensitive information. 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-824. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-53074] reject short IPv4/IPv6 inputs in bpf_prog_test_run_skb
In the Linux kernel, the following vulnerability has been resolved: bpf: reject short IPv4/IPv6 inputs in bpf_prog_test_run_skb bpf_prog_test_run_skb() calls eth_type_trans() first and then uses skb->protocol to initialize sk family and address fields for the test run. For IPv4 and IPv6 packets, it may access ip_hdr(skb) or ipv6_hdr(skb) even when the provided test input only contains an Ethernet header. Reject the input earlier if the Ethernet frame carries IPv4/IPv6 EtherType but the L3 header is too short. Fold the IPv4/IPv6 header length checks into the existing protocol switch and return -EINVAL before accessing the network headers. A flaw was found in the Linux kernel's BPF (Berkeley Packet Filter) subsystem. Specifically, the `bpf_prog_test_run_skb()` function, responsible for testing BPF programs with network packets, did not properly validate the length of IPv4 and IPv6 inputs. This could allow the kernel to attempt to access network header information even when the provided packet data was too short, potentially leading to system instability or unexpected behavior. Red Hat severity: Moderate — CVSS 6.4 (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-1284. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-53115] use generic driver_override infrastructure
In the Linux kernel, the following vulnerability has been resolved: bus: fsl-mc: use generic driver_override infrastructure When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. During the driver probing process, a Use-After-Free (UAF) vulnerability can occur because the `match()` callback accesses the `driver_override` field without proper locking. This can lead to system instability or potentially allow an attacker to execute arbitrary code. 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-413. Affected Red Hat products: Red Hat Enterprise Linux 10. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-53100] fix deadlock in remain-on-channel
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: fix deadlock in remain-on-channel mt76_remain_on_channel() and mt76_roc_complete() call mt76_set_channel() while already holding dev->mutex. Since mt76_set_channel() also acquires dev->mutex, this results in a deadlock. Use __mt76_set_channel() instead of mt76_set_channel(). Add cancel_delayed_work_sync() for mac_work before acquiring the mutex in mt76_remain_on_channel() to prevent a secondary deadlock with the mac_work workqueue. A flaw was found in the Linux kernel's mt76 wireless driver. This vulnerability occurs in the `remain-on-channel` functionality, where the `mt76_remain_on_channel()` and `mt76_roc_complete()` functions attempt to acquire a mutex that is already held. This improper handling of the device mutex can lead to a system deadlock, causing the system to become unresponsive. 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-833. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-52954] handle rbtree insertion error in decode_choose_args
In the Linux kernel, the following vulnerability has been resolved: libceph: handle rbtree insertion error in decode_choose_args() A message of type CEPH_MSG_OSD_MAP contains an OSD map that itself contains a CRUSH map. The received CRUSH map may optionally contain choose_args that get decoded in decode_choose_args(). In this function, num_choose_arg_maps is read from the message, and a corresponding number of crush_choose_arg_maps gets decoded afterwards. Each crush_choose_arg_map has a choose_args_index, which serves as the key when inserting it into the choose_args rbtree of the decoded crush_map. If a (potentially corrupted) message contains two crush_choose_arg_maps with the same index, the assertion in insert_choose_arg_map() triggers a kernel BUG when trying to insert the second crush_choose_arg_map. This patch fixes the issue by switching to the non-asserting rbtree insertion function and rejecting the message if the insertion fails. [ idryomov: changelog ] A remote attacker could send a specially crafted CEPH_MSG_OSD_MAP message containing a corrupted CRUSH map. If this map includes two crush_choose_arg_maps with identical indices, it triggers an assertion failure, leading to a kernel bug and a system crash. This vulnerability results 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).
Medium [CVE-2026-52988] join hook list via splice_list_rcu in commit phase
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: join hook list via splice_list_rcu() in commit phase Publish new hooks in the list into the basechain/flowtable using splice_list_rcu() to ensure netlink dump list traversal via rcu is safe while concurrent ruleset update is going on. This vulnerability involves a concurrency issue during updates to netfilter rulesets. When multiple updates occur simultaneously, improper synchronization could lead to unsafe data access during netlink dump list traversal. This could result in system instability or unexpected behavior. The issue has been resolved by ensuring new hooks are published safely, preventing these concurrency problems. 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-821. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-53058] Set the mhdp connector earlier in atomic_enable
In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cadence: cdns-mhdp8546-core: Set the mhdp connector earlier in atomic_enable() In case if we get errors in cdns_mhdp_link_up() or cdns_mhdp_reg_read() in atomic_enable, we will go to cdns_mhdp_modeset_retry_fn() and will hit NULL pointer while trying to access the mutex. Unlike in legacy cases with flag!DRM_BRIDGE_ATTACH_NO_CONNECTOR, we do not have connector initialised in bridge_attach(), so add the mhdp->connector_ptr in device structure to handle both cases with DRM_BRIDGE_ATTACH_NO_CONNECTOR and!DRM_BRIDGE_ATTACH_NO_CONNECTOR, set it in atomic_enable() earlier to avoid possible NULL pointer dereference in recovery paths like modeset_retry_fn() with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag set. This vulnerability allows for a NULL pointer dereference during error handling within the `atomic_enable()` function. If `cdns_mhdp_link_up()` or `cdns_mhdp_reg_read()` encounter errors, a subsequent attempt to access a mutex in `cdns_mhdp_modeset_retry_fn()` can result in a NULL pointer dereference. This can lead to a system crash, causing a denial of service (DoS). 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-824. Affected Red Hat products: Red Hat Enterprise Linux 10. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-53061] dm cache: fix dirty mapping checking in passthrough mode switching
In the Linux kernel, the following vulnerability has been resolved: dm cache: fix dirty mapping checking in passthrough mode switching As mentioned in commit 9b1cc9f251af ("dm cache: share cache-metadata object across inactive and active DM tables"), dm-cache assumed table reload occurs after suspension, while LVM's table preload breaks this assumption. The dirty mapping check for passthrough mode was designed around this assumption and is performed during table creation, causing the check to fail with preload while metadata updates are ongoing. This risks loading dirty mappings into passthrough mode, resulting in data loss. Reproduce steps: 1. Create a writeback cache with zero migration_threshold to produce dirty mappings dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writeback smq \ 2 migration_threshold 0" 2. Write to the first cache block to make it dirty fio --filename=/dev/mapper/cache --name=populate --rw=write --bs=4k \ --direct=1 --size=64k 4.
Medium [CVE-2026-53048] prevent NULL pointer dereference during unmount
In the Linux kernel, the following vulnerability has been resolved: gfs2: prevent NULL pointer dereference during unmount When flushing out outstanding glock work during an unmount, gfs2_log_flush() can be called when sdp->sd_jdesc has already been deallocated and sdp->sd_jdesc is NULL. Commit 35264909e9d1 ("gfs2: Fix NULL pointer dereference in gfs2_log_flush") added a check for that to gfs2_log_flush() itself, but it missed the sdp->sd_jdesc dereference in gfs2_log_release(). This happens because `gfs2_log_flush()` is called when a critical data structure (`sdp->sd_jdesc`) has already been deallocated, and a subsequent dereference in `gfs2_log_release()` lacks a necessary NULL check. An attacker could potentially exploit this to cause a system crash, leading to a Denial of Service (DoS). 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-825. Affected Red Hat products: Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Will not fix / out of support: Red Hat Enterprise Linux 6. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-53094] Fix stale offload->prog pointer after constant blinding
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stale offload->prog pointer after constant blinding When a dev-bound-only BPF program (BPF_F_XDP_DEV_BOUND_ONLY) undergoes JIT compilation with constant blinding enabled (bpf_jit_harden >= 2), bpf_jit_blind_constants() clones the program. The original prog is then freed in bpf_jit_prog_release_other(), which updates aux->prog to point to the surviving clone, but fails to update offload->prog. When the network namespace is subsequently destroyed, cleanup_net() triggers bpf_dev_bound_netdev_unregister(), which iterates ondev->progs and calls __bpf_prog_offload_destroy(offload->prog). Accessing the freed prog causes a page fault: BUG: unable to handle page fault for address: ffffc900085f1038 Workqueue: netns cleanup_net RIP: 0010:__bpf_prog_offload_destroy+0xc/0x80 Call Trace: __bpf_offload_dev_netdev_unregister+0x257/0x350 bpf_dev_bound_netdev_unregister+0x4a/0x90 unregister_netdevice_many_notify+0x2a2/0x660... cleanup_net+0x21a/0x320 The test sequence that triggers this reliably is: 1. Set net.core.bpf_jit_harden=2 (echo 2 > /proc/sys/net/core/bpf_jit_harden) 2. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9.
Medium [CVE-2026-53118] use generic driver_override infrastructure
In the Linux kernel, the following vulnerability has been resolved: vdpa: use generic driver_override infrastructure When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. This vulnerability occurs because a specific field, `driver_override`, is accessed without proper locking during the driver's initialization process. An attacker could exploit this Use-After-Free (UAF) condition to potentially execute arbitrary code or cause a system crash (Denial of Service). 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-413. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-52958] Fix potential out-of-bounds access in osdmap_decode
In the Linux kernel, the following vulnerability has been resolved: libceph: Fix potential out-of-bounds access in osdmap_decode() When decoding osd_state and osd_weight from an incoming osdmap in osdmap_decode(), both are decoded for each osd, i.e., map->max_osd times. The ceph_decode_need() check only accounts for sizeof(*map->osd_weight) once. This can potentially result in an out-of-bounds memory access if the incoming message is corrupted such that the max_osd value exceeds the actual content of the osdmap message. This vulnerability, located within the `osdmap_decode()` function, can lead to an out-of-bounds memory access. A remote attacker could exploit this by sending a specially crafted and corrupted `osdmap` message, where the `max_osd` value exceeds the actual message content. This could potentially result in system instability or other unforeseen impacts due to memory corruption. 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-1284. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9. Red Hat does not currently list a fixing RHSA for this CVE.
Medium [CVE-2026-11972] Python tarfile module: Denial of Service via improper EOF handling in streaming mode
Python tarfile module: Denial of Service via improper EOF handling in streaming mode. Red Hat rates this moderate (CVSS 6.5). Weakness: CWE-835. Red Hat lists fixing advisory RHSA-2026:35813 with package python3-11-main-3.11.15-4.4.hum1, python3-14-main-3.14.6-1.2.hum1, python3-13-main-3.13.14-1.2.hum1, python3-12-main-3.12.13-3.3.hum1.
Medium [CVE-2026-54518] Information disclosure and data manipulation via view-based access control bypass
jackson-databind contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor. From 2.21.0 until 2.21.4 and 3.1.4, UnwrappedPropertyHandler.processUnwrappedCreatorProperties() replays buffered JSON into creator parameters but never consults prop.visibleInView(activeView). The normal property-based creator path gates creator properties on the active view, but this unwrapped-creator replay path bypasses that check, so a constructor parameter annotated with both @JsonView(AdminView.class) and @JsonUnwrapped is populated from attacker JSON even when a more restrictive view is active. This vulnerability is fixed in 2.21.4 and 3.1.4. This vulnerability allows a remote attacker to bypass security view restrictions by sending specially crafted JSON (JavaScript Object Notation) data. The UnwrappedPropertyHandler component, which processes unwrapped properties, incorrectly populates constructor parameters that should be hidden by an active security view. This can lead to unauthorized information disclosure or data manipulation. When processing unwrapped creator properties, the component fails to properly enforce @JsonView annotations, enabling sensitive constructor parameters to be populated from untrusted JSON data. Red Hat severity: Moderate — CVSS 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N). Weakness: CWE-639.
Medium [CVE-2026-54514] Information Disclosure via Eager DNS Resolution
jackson-databind contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor. From 2.0.0 until 2.18.8, 2.21.4, and 3.1.4, JDKFromStringDeserializer constructed InetSocketAddress with new InetSocketAddress(host, port), which performs eager DNS name resolution for hostname inputs at deserialization time. An application that binds untrusted JSON into a type containing an InetSocketAddress field issues an attacker-chosen DNS query during readValue, before any application-level validation or connect logic. The fix uses InetSocketAddress.createUnresolved(host, port), deferring DNS to an explicit connect. This vulnerability is fixed in 2.18.8, 2.21.4, and 3.1.4. A flaw was found in jackson-databind, a library used for processing JSON data. This vulnerability allows a remote attacker to force the application to perform an attacker-chosen DNS (Domain Name System) query. This occurs when untrusted JSON input containing specific network address information is processed, potentially leading to the disclosure of sensitive network configuration details. Moderate: A flaw in `jackson-databind` can lead to information disclosure in Red Hat products that process untrusted JSON input. This eager DNS resolution occurs before application-level validation, potentially revealing internal network configuration details through DNS logs.
Medium [CVE-2026-54515] Ignored properties can be unexpectedly modified
jackson-databind contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor. From 2.8.0 until 2.18.9, 2.21.5, and 3.1.4, in BeanDeserializerBase.createContextual(), per-property @JsonIgnoreProperties exclusions are applied by _handleByNameInclusion(), producing a contextual deserializer whose BeanPropertyMap has the ignored properties removed. The subsequent per-property case-insensitivity block (triggered by @JsonFormat(ACCEPT_CASE_INSENSITIVE_PROPERTIES)) rebuilds from this._beanProperties (the original, unfiltered map) instead of contextual._beanProperties, then overwrites the filtered map — restoring every property _handleByNameInclusion had just removed. This vulnerability is fixed in 2.18.9, 2.21.5, and 3.1.4. This vulnerability occurs in the data-binding functionality where properties intended to be ignored are incorrectly restored and become writable again. An attacker could potentially exploit this by providing input that modifies data through these supposedly ignored properties. This could lead to unintended changes in application data, impacting data integrity. This is a Moderate impact flaw in jackson-databind where applications enabling case-insensitive property matching alongside per-property @JsonIgnoreProperties may inadvertently expose fields to unauthorized modification.
Medium [CVE-2026-54516] Security bypass due to improper handling of renamed properties
jackson-databind contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor. From 2.21.0 until 2.21.4 and 3.1.4, POJOPropertiesCollector._renameProperties() allows a property with @JsonProperty("renamed") on the getter and @JsonIgnore on the setter to be renamed rather than dropped. With MapperFeature.INFER_PROPERTY_MUTATORS enabled (default), the private backing field is retained; during deserialization BeanDeserializerFactory.addBeanProps() sees hasField()==true, builds a FieldProperty, and makes the backing field writable. An attacker supplying the renamed JSON key writes the backing field directly, bypassing the @JsonIgnore on the setter. This vulnerability is fixed in 3.1.4. This vulnerability allows a remote attacker to bypass security controls by exploiting an issue in how properties are handled when both @JsonProperty (for renaming) and @JsonIgnore (for ignoring) annotations are used. By supplying a specially crafted JSON key, an attacker can directly write to a private data field, circumventing the intended security restrictions and potentially leading to unexpected data modification. Moderate: This flaw in jackson-databind allows for property tampering and mass assignment in Red Hat products. Red Hat severity: Moderate — CVSS 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N). Weakness: CWE-915.
Medium [CVE-2026-54517] Information disclosure via improper JsonView filter application
jackson-databind contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor. From 2.21.0 until 2.21.4 and 3.1.4, in BeanDeserializer._deserializeUsingPropertyBased, the active-view (@JsonView) filter was applied only to creator properties; the regular property-buffering branch performed no prop.visibleInView(activeView) check. A change making SetterlessProperty.isMerging() return true routed setterless Collection/Map properties through this unguarded path, so a setterless collection annotated with a restricted @JsonView is populated from attacker JSON even when the active view excludes it. This vulnerability is fixed in 2.21.4 and 3.1.4. A remote attacker can exploit this vulnerability due to an issue in how active-view (@JsonView) filters are applied. This can lead to information disclosure, allowing an attacker to access data that should otherwise be restricted. Moderate: A flaw in jackson-databind allows for information disclosure and an access-control bypass. This occurs because the `@JsonView` filter, intended to restrict data visibility, is not correctly applied to setterless collection and map properties during deserialization. An attacker could exploit this to populate view-restricted properties from untrusted JSON, potentially accessing sensitive data that should be excluded by the active view.
Medium [CVE-2026-54762] Authentication bypass due to invalid authentication secret
Traefik is an HTTP reverse proxy and load balancer. From 3.7.0-ea.1 until 3.7.5, there is a medium severity vulnerability in Traefik's Kubernetes Ingress NGINX provider that causes affected routes to fail open. When an Ingress explicitly enables BasicAuth or DigestAuth through the supported nginx.ingress.kubernetes.io/auth-type and auth-secret annotations, but the referenced auth Secret cannot be resolved or parsed, Traefik logs the resolution error, skips installing the authentication middleware, and still emits a router to the backend service. A route that operators intended to protect is therefore published to the data plane without its authentication control, allowing unauthenticated access to the backend. The trigger is an invalid or unresolved auth dependency — a missing, malformed, unreadable, or policy-denied Secret — rather than an intentionally unprotected route. This vulnerability is fixed in 3.7.5. This allows unauthenticated access to backend services that were intended to be protected, potentially exposing sensitive information or functionality. Red Hat severity: Low — CVSS 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N). Weakness: CWE-166. Affected Red Hat products: Red Hat OpenShift Dev Spaces. Red Hat does not currently list a fixing RHSA for this CVE.