Red Hat Linux Security Advisories & CVEs
12447 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-72182] fix refcount leak in is_full_charged
In the Linux kernel, the following vulnerability has been resolved: power: supply: charger-manager: fix refcount leak in is_full_charged() In is_full_charged(), power_supply_get_by_name() is called to obtain a reference to the fuel_gauge power supply. If the voltage check (uV >= desc->fullbatt_uV) succeeds, the function returns true directly without releasing the reference, leaking the refcount. Fix this by setting a flag and jumping to the out label where power_supply_put() properly drops the reference. A reference count (refcount) leak occurs within the `is_full_charged()` function. This happens when a reference to the fuel gauge power supply is obtained but not properly released if a specific voltage check succeeds. This resource leak could potentially lead to system instability or a denial of service. Red Hat rates this flaw Moderate severity with a CVSS:3.1 base score of 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), reflecting the local attack vector and the availability-only impact. The vulnerable code was introduced upstream in Linux kernel 5.10. Weakness: CWE-911. 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 as not affected.
Medium [CVE-2026-72278] Re-translate VNCR before injecting abort
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Re-translate VNCR before injecting abort KVM faults in the VNCR page with FOLL_WRITE whenever the guest aborts for a write, similar to how a regular stage-2 mapping is handled. It is entirely possible that the guest reads from the VNCR before writing to it, in which case the PFN could only be read-only. Invalidate the VNCR TLB and re-fetch the translation upon taking a VNCR abort, allowing the host mapping to be faulted in for write the second time around. Interestingly enough, this also satisfies the ordering requirements of FEAT_ETS2/3 between descriptor updates and MMU faults. A flaw was found in the Linux kernel's Kernel-based Virtual Machine (KVM) for arm64 systems. This vulnerability occurs when a guest operating system attempts to access the Virtualization Nested Control Register (VNCR) page. If the guest reads from VNCR before writing to it, KVM may incorrectly handle the memory access, potentially leading to unexpected behavior or instability within the virtualized environment. Red Hat Product Security has rated this flaw as having LOW impact. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat package: kernel.
Medium [CVE-2026-72300] validate vendor array size before parsing
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: topology: validate vendor array size before parsing sof_parse_token_sets() reads array->size while iterating over topology private data. The loop condition only checks that some data remains, so a malformed topology with a truncated trailing vendor array can make the parser read the size field before a full vendor-array header is available. Validate that the remaining private data contains a complete snd_soc_tplg_vendor_array header before reading array->size. The declared array size check also needs to remain signed. asize is an int, but sizeof(*array) has type size_t, so comparing them directly promotes negative asize values to unsigned and lets them pass the check, as reported in the stable review thread reference below. This rejects negative, zero and otherwise too-small sizes before the parser dispatches to the tuple-specific code. A flaw was found in the Linux kernel's Advanced Linux Sound Architecture (ASoC) Sound Open Firmware (SOF) topology component. A local attacker could exploit this by providing malformed topology data, leading to an out-of-bounds read. This could result in system instability or a denial of service. Red Hat rated this flaw Moderate with a CVSS 3.1 base score of 5.5 (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), reflecting a local attack vector with availability-only impact.
Medium [CVE-2026-72199] validate resident index root values on lookup
In the Linux kernel, the following vulnerability has been resolved: ntfs: validate resident index root values on lookup Resident $INDEX_ROOT values carry index header fields that callers consume after lookup. Some callers already validate parts of the layout before walking entries, but those checks are scattered and do not cover all root header invariants, such as entries_offset alignment and lower bound, index_length, and allocated_size consistency. The resident root resize paths now keep these header fields consistent while the value size changes: ntfs_ir_truncate() lowers index.allocated_size before shrinking the resident value, and ntfs_ir_reparent() grows the resident value before publishing a larger root header. Lookup-time validation can therefore cover these invariants without tripping over the driver's own resize paths. Add $INDEX_ROOT to the minimum resident value size table and validate the resident index header fields before returning the attribute from lookup. Require 8-byte aligned index header fields, a sane entries_offset, an index_length within allocated_size, allocated_size within the resident value, and enough entry space for at least an index entry header. The shared validator already rejects non-resident records for resident-only attribute types, including $INDEX_ROOT. A flaw was found in the NTFS filesystem driver of the Linux kernel.
Medium [CVE-2026-72370] release pages on atomic dio size mismatch
In the Linux kernel, the following vulnerability has been resolved: iomap: release pages on atomic dio size mismatch If bio_iov_iter_get_pages() or the bounce helper succeeds but builds a short bio, the REQ_ATOMIC size check rejects it before submission. The old error path only dropped the bio reference, leaving any pages already attached to the bio unreleased. Release or unbounce the pages before falling through to out_put_bio on this error path. This bug was reported by sashiko: When handling atomic direct I/O (DIO) operations, if a bio (a data structure representing I/O requests) is built with a size mismatch and subsequently rejected, the kernel's error handling path fails to release the associated memory pages. This oversight can lead to a resource leak, potentially causing memory exhaustion and a Denial of Service (DoS) condition on the affected system. A low impact resource leak was found in the Linux kernel iomap direct I/O (DIO) subsystem. When an atomic direct I/O write builds a short bio that is rejected by the REQ_ATOMIC size check before submission, the error path drops the bio reference without releasing the pages already attached to the bio. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat package: kernel.
Medium [CVE-2026-72377] Remove setting of AS_RELEASE_ALWAYS for symlinks and mountpoints
In the Linux kernel, the following vulnerability has been resolved: afs: Remove setting of AS_RELEASE_ALWAYS for symlinks and mountpoints Regular AFS files correctly use afs_file_aops which have release_folio set as netfs_release_folio, so AS_RELEASE_ALWAYS is valid for them when fscache is enabled (set via afs_vnode_set_cache()). However, afs_apply_status() unconditionally calls mapping_set_release_always() for these. In such case when memory management code attempts to release folios, filemap_release_folio() checks folio_needs_release() which returns true due to AS_RELEASE_ALWAYS being set. Since there is no release_folio callback, it falls through to try_to_free_buffers(), which at present expects buffer_heads to be not null. For symlinks and mountpoints without buffer_heads, this causes pointer dereference. [dh: Added more bits that were missed] A flaw was found in the Linux kernel's Andrew File System (AFS) module. When fscache is enabled, AFS symlinks and mountpoints are incorrectly handled during memory management operations. This can lead to a pointer dereference, which a local attacker could potentially exploit to cause a system crash, resulting in a Denial of Service (DoS). Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat package: kernel.
Medium [CVE-2026-72280] Drop bogus WARN for write to ZCR_EL2
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: nv: Drop bogus WARN for write to ZCR_EL2 It is entirely possible for a guest to write to the ZCR_EL2 sysreg alias while in a nested context, as it is expected if FEAT_NV2 is advertised to the L1 hypervisor. Get rid of the bogus WARN which, since the hyp vectors were installed at this point, has the effect of a hyp_panic... A flaw was found in the Linux kernel's KVM (Kernel-based Virtual Machine) for ARM64 architectures. A guest operating system, when operating in a nested virtualization environment, could trigger a hypervisor panic (hyp_panic) by writing to the ZCR_EL2 system register alias. This issue leads to a denial of service for the virtual machine, potentially affecting the stability of the host system. The kernel incorrectly treats this legitimate write as a warning condition; because the hypervisor vectors are installed at that point, the warning has the effect of a hypervisor panic (hyp_panic), causing a denial of service affecting the host and the virtual machines running on it. Only ARM64 systems that expose KVM nested virtualization to guests are exposed to this flaw; guests that do not run nested virtualization cannot trigger it. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 9; Red Hat package: kernel-rt.
Medium [CVE-2026-72423] Guard conntrack opts error writes
In the Linux kernel, the following vulnerability has been resolved: bpf: Guard conntrack opts error writes The conntrack lookup and allocation kfuncs take an opts pointer together with an opts__sz argument. The verifier checks only the memory range described by opts__sz, but the wrappers unconditionally write opts->error whenever the internal lookup or allocation helper returns an error. For an invalid size smaller than the end of opts->error, that write can land outside the verifier-checked range. Keep returning NULL for invalid arguments, but only report the error through opts->error when the supplied size includes the field. This preserves error reporting for the supported 12-byte and 16-byte layouts, and for other invalid sizes that still include opts->error. The BPF (Berkeley Packet Filter) subsystem's conntrack (connection tracking) functionality contains an out-of-bounds write vulnerability. This occurs because the system does not properly validate the size of an options structure when reporting errors in conntrack lookup and allocation kernel functions (kfuncs). An attacker could potentially exploit this by providing an invalid size, leading to memory corruption. This results in kernel memory corruption, most concretely a system crash or denial of service. Affected products named by the advisory: Red Hat Enterprise Linux 9; Red Hat package: kernel-rt.
Medium [CVE-2026-72171] remove failed entries from the device list
In the Linux kernel, the following vulnerability has been resolved: mtd: slram: remove failed entries from the device list register_device() links a new slram_mtdlist entry before allocating all of the state needed by the entry. If a later allocation, memremap(), or mtd_device_register() fails, the partially initialized entry remains on the global list. A later cleanup can then dereference or free invalid state from that failed entry. Unwind the partially initialized entry and clear the list tail on each failure path after the entry has been linked. A flaw was found in the Linux kernel's Memory Technology Device (MTD) subsystem, specifically within the `slram` module. A subsequent cleanup operation may then attempt to dereference or free invalid memory, potentially leading to memory corruption or 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-824. 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 as not affected.
Medium [CVE-2026-72269] fix potential memory leak in uvesafb_probe
In the Linux kernel, the following vulnerability has been resolved: fbdev: uvesafb: fix potential memory leak in uvesafb_probe() Due to an incorrect goto label, memory allocated for modedb and modelist in uvesafb_vbe_init() is not freed in some error paths. A flaw was found in the Linux kernel's framebuffer device (fbdev) component, specifically within the `uvesafb` driver. This vulnerability occurs because memory allocated for display modes is not properly released during certain error handling paths. This oversight can lead to a memory leak, which might exhaust system resources and cause the system to become unresponsive, resulting in a Denial of Service (DoS). A local attacker able to trigger such an error path during uvesafb initialization could cause repeated memory leaks, potentially exhausting system resources and leaving the system unresponsive, resulting in a denial of service. Red Hat rates this flaw Moderate impact (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H); it affects only system availability, with no impact on confidentiality or integrity. All currently listed Red Hat product relationships for this flaw, covering the Red Hat Enterprise Linux and Red Hat In-Vehicle OS kernel offerings, are marked not affected because the vulnerable code is not present in the shipped kernel packages, so no Red Hat update is required. Weakness: CWE-772.
Medium [CVE-2026-72263] fix memory leak in snd_sof_load_topology
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: topology: fix memory leak in snd_sof_load_topology When the topology filename contains "dummy" and tplg_cnt is 0, the function returns -EINVAL directly without freeing the tplg_files allocated by kcalloc() at line 2497. This leaks memory on every such topology load attempt. Fix this by setting ret = -EINVAL and jumping to the out: label, which already handles the kfree(tplg_files) cleanup. A flaw was found in the Linux kernel's ASoC (Audio System on Chip) Sound Open Firmware (SOF) topology component. When a topology filename contains "dummy" and a specific counter is zero, the `snd_sof_load_topology` function fails to deallocate previously assigned memory. This oversight results in a memory leak with each failed topology load attempt, potentially leading to resource exhaustion and a denial of service (DoS) for the system. 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-772. Affected Red Hat products: Red Hat Enterprise Linux 9. 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-72138] fix error handling in ioctl
In the Linux kernel, the following vulnerability has been resolved: xen/gntdev: fix error handling in ioctl When gntdev_ioctl_map_grant_ref() fails to copy the operation result back to userspace after successfully adding the mapping to the list, the error path returns -EFAULT without releasing the reference acquired by gntdev_alloc_map(). The mapping remains in priv->maps with a refcount of 1, causing a memory leak and a dangling list entry. Additionally, gntdev_add_map() may modify map->index to avoid overlap with existing mappings. Therefore, the index returned to userspace must be obtained after gntdev_add_map() completes. Fix this by holding the mutex across gntdev_add_map(), retrieving the correct index, and copy_to_user(). If copy_to_user() fails, remove the mapping from the list and release the reference while still holding the lock. Fix these issues by properly handling all error cases. When the `gntdev_ioctl_map_grant_ref()` function fails to copy operation results back to userspace, it does not properly release a memory reference. This oversight can lead to a memory leak and a corrupted list entry. A local attacker could exploit this to cause a denial of service by exhausting system memory. 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-772.
Medium [CVE-2026-72481] fix potential kernel stack memory leak
In the Linux kernel, the following vulnerability has been resolved: iio: magnetometer: ak8975: fix potential kernel stack memory leak Currently in the AK8975 driver there are four instances where potential uninitialized kernel stack memory leaks can occur. If i2c_smbus_read_i2c_block_data_or_emulated() returns a value less than the size of the buffer, uninitialized bytes are retained in the buffer and later the buffer is passed on to IIO buffers, potentially leaking memory to userspace. Fix this by adding checks whether the return value of the function is equal to the size of the buffer and subsequently if the value is lesser than zero to distinguish from a returned error code. This vulnerability occurs when the `i2c_smbus_read_i2c_block_data_or_emulated()` function returns fewer bytes than expected, leaving uninitialized data in a buffer. A local attacker with access to IIO (Industrial Input/Output) buffers could potentially exploit this to read sensitive information from the kernel stack memory, leading to information disclosure. All currently listed Red Hat offerings, including Red Hat Enterprise Linux 6 through 10 (kernel and kernel-rt) and Red Hat In-Vehicle OS, are marked not affected because the vulnerable code is not present in the shipped kernels. 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-908.
Medium [CVE-2026-72179] Fix node reference leak in populate_cache_leaves
In the Linux kernel, the following vulnerability has been resolved: riscv: cacheinfo: Fix node reference leak in populate_cache_leaves Currently, the while loop drops the reference to prev in each iteration. If the loop terminates early due to a break, the final of_node_put(np) correctly drops the reference to the current node. However, if the loop terminates naturally because np == NULL, calling of_node_put(np) is a no-op. This leaves the last valid node stored in prev without its reference dropped, resulting in a node reference leak. Fix this by changing the final `of_node_put(np)` to `of_node_put(prev)`. A flaw was found in the Linux kernel's handling of cache information. This vulnerability occurs when the system fails to properly release memory references during certain operations. This oversight results in a memory leak, which can lead to resource exhaustion and potentially impact system stability. This node reference leak results in a kernel memory leak, which could allow a local user on an affected system to progressively exhaust memory resources and degrade system availability. Red Hat Enterprise Linux and Red Hat In-Vehicle OS are not affected by this flaw, because the vulnerable code is not present in the shipped kernel packages. 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-772.
Medium [CVE-2026-72188] sanitize MFT references returned from ntfs_lookup_inode_by_name
In the Linux kernel, the following vulnerability has been resolved: ntfs: sanitize MFT references returned from ntfs_lookup_inode_by_name() ntfs_lookup_inode_by_name() returns MFT references read from directory index entries on disk. These values are untrusted, but the function can currently return an error-marked MFT reference to its callers without validating it. Callers later decode lookup failures with MREF_ERR(). A crafted NTFS image can set the MREF error bit while leaving the low bits as an arbitrary value, causing callers to consume a bogus pseudo-errno instead of treating the lookup result as corrupted on-disk metadata. Fix this at the source by normalizing every error-marked MFT reference returned from ntfs_lookup_inode_by_name() to ERR_MREF(-EIO). Apply this to all four directory lookup return paths so every caller gets a validated result without needing additional checks or an API change. This keeps the sanitization in the common lookup helper, which is cleaner than duplicating validation in each caller. A flaw was found in the Linux kernel's NTFS filesystem driver. A remote attacker could craft a malicious NTFS image that, when processed, causes the ntfs_lookup_inode_by_name() function to return an unvalidated error-marked MFT (Master File Table) reference.
Medium [CVE-2026-72237] Fix kernel address leakage
In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd/brs: Fix kernel address leakage A user-only branch stack can contain branches that originate from the kernel. As a result, kernel addresses are exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. On AMD processors supporting X86_FEATURE_BRS (Zen 3 only), perf can still report entries such as SYSRET/interrupt returns for which the branch-from addresses are in the kernel. E.g. $ perf record -j any,u -c 4000 -e branch-brs -o - -- \ perf bench syscall basic --loop 1000 | \ perf script -i - -F brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}'... 0xffffffff810001c4/0x72e2e32955eb/-/-/-/0//- 0xffffffff810001c4/0x72e2d94a9821/-/-/-/0//- 0xffffffff810001c4/0x72e2d94ffa1b/-/-/-/0//-... BRS provides no hardware branch filtering, so privilege level filtering is performed entirely in software. However, amd_brs_match_plm() only validates the branch-to address against the requested privilege levels. For branches from the kernel to user space, the branch-from address is left unchecked and is leaked. Extend the software filter to also validate the branch-from address, so that any branch record whose branch-from address is in the kernel is dropped when PERF_SAMPLE_BRANCH_USER is requested.
Medium [CVE-2026-72271] fix potential memory leak in i740fb_probe
In the Linux kernel, the following vulnerability has been resolved: fbdev: i740fb: fix potential memory leak in i740fb_probe() In i740fb_probe(), the memory allocated in fb_videomode_to_modelist() for modelist is not freed in the error paths. Fix that by calling fb_destroy_modelist(). This oversight can lead to a memory leak, potentially impacting system stability and performance over time. A moderate-severity memory leak flaw was found in the Linux kernel fbdev i740fb driver (drivers/video/fbdev/i740fb.c). When the driver probe fails, kernel memory is leaked, and repeated failed probes could progressively exhaust memory and degrade system availability. The Red Hat CVSS v3 score for this flaw is 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), reflecting a local attack vector requiring low privileges, with high impact on availability and no impact on confidentiality or integrity. None of the Red Hat products tracked for this flaw are affected: all Red Hat Enterprise Linux (kernel and kernel-rt) and Red Hat In-Vehicle OS (kernel and kernel-ivos-qualcomm) update streams are recorded as NOT AFFECTED with the justification that the vulnerable code is not present in the shipped Red Hat kernel builds. 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-772.
Medium [CVE-2026-72285] Reject concurrent change to CPUID entry count
In the Linux kernel, the following vulnerability has been resolved: KVM: TDX: Reject concurrent change to CPUID entry count Reject KVM_TDX_INIT_VM if userspace changes cpuid.nent between the initial read and the subsequent copy of the initialization data. tdx_td_init() first reads user_data->cpuid.nent to size the flexible kvm_tdx_init_vm copy. The copied structure also contains cpuid.nent, and that field can differ from the value used to size the allocation if userspace modifies the input concurrently. setup_tdparams_cpuids() later passes init_vm->cpuid.nent to kvm_find_cpuid_entry2(), which uses it as the array bound for the copied entries. Require the copied count to match the value used to size the allocation so that CPUID parsing cannot access beyond the entries actually copied. A flaw was found in the Linux kernel's KVM (Kernel-based Virtual Machine) TDX (Trust Domain Extensions) module. A local attacker, by concurrently modifying the CPUID entry count during the initialization of a virtual machine, could cause the CPUID parsing to access memory beyond the intended boundaries. This out-of-bounds access could potentially lead to a denial of service or other undefined behavior within the virtualized environment. Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat package: kernel.
Medium [CVE-2026-72264] fix potential memory leak in trident_pci_probe
In the Linux kernel, the following vulnerability has been resolved: fbdev: tridentfb: fix potential memory leak in trident_pci_probe() In trident_pci_probe(), the memory allocated for modelist using fb_videomode_to_modelist() is not freed in subsequent error paths. Fix that by calling fb_destroy_modelist(). This could allow a local attacker to exhaust available memory resources, leading to 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-772. 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 as not affected.
Medium [CVE-2026-72184] fix hole runlist memory leak in insert range error path
In the Linux kernel, the following vulnerability has been resolved: ntfs: fix hole runlist memory leak in insert range error path ntfs_non_resident_attr_insert_range() allocates hole_rl before mapping the whole runlist. If ntfs_attr_map_whole_runlist() fails, the error path drops ni->runlist.lock and returns without freeing hole_rl. This leaks memory of sizeof(*hole_rl) * 2 bytes. Fix this memory leak by freeing hole_rl before returning from that error path, matching the later error paths in the same function. A flaw was found in the Linux kernel's NTFS file system driver. When handling non-resident attributes, a memory leak occurs in the `ntfs_non_resident_attr_insert_range()` function. If the mapping of the runlist fails, allocated memory for `hole_rl` is not properly released. This can lead to resource exhaustion over time, potentially resulting in a Denial of Service (DoS) for the system. A local attacker able to repeatedly trigger this error path on an NTFS file system could gradually exhaust kernel memory and cause a denial of service. Red Hat rates this flaw MODERATE severity with a CVSS 3.1 base score of 5.5 (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).