Red Hat Linux Security Advisories & CVEs
6057 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-63980] Use spin_lock_bh for hn_lock
In the Linux kernel, the following vulnerability has been resolved: net/handshake: Use spin_lock_bh for hn_lock nvmet_tcp_state_change(), a socket callback that runs in BH context, can reach handshake_req_cancel() via nvmet_tcp_schedule_release_queue() and tls_handshake_cancel(). handshake_req_cancel() acquires hn->hn_lock with plain spin_lock(). If a process-context thread on the same CPU holds hn->hn_lock when a softirq invokes the cancel path, the lock attempt deadlocks. This is the only caller that invokes tls_handshake_cancel() from BH context; every other consumer calls it from process context. Deferring the cancel to process context in the NVMe target is not straightforward: nvmet_tcp_schedule_release_queue() must call tls_handshake_cancel() atomically with its state transition to DISCONNECTING. If the cancel were deferred, the handshake completion callback could fire in the window before the cancel runs, observe the unexpected state, and return without dropping its kref on the queue. Reworking that interlock is considerably more invasive than hardening the handshake lock. Convert all hn->hn_lock acquisitions from spin_lock/spin_unlock to spin_lock_bh/spin_unlock_bh so the lock is never taken with softirqs enabled. A flaw was found in the Linux kernel's network handshake component.
Medium [CVE-2026-63986] don't pass ERR_PTR to genlmsg_cancel on prepare failure
In the Linux kernel, the following vulnerability has been resolved: ethtool: tsinfo: don't pass ERR_PTR to genlmsg_cancel on prepare failure The goto err label leads to: genlmsg_cancel(skb, ehdr); return ret; If ethnl_tsinfo_prepare_dump() failed, it has not started a genlmsg. There's nothing to cancel, and passing an error pointer to genlmsg_cancel() would cause a crash. This vulnerability occurs when the `ethnl_tsinfo_prepare_dump()` function fails to properly initialize a generic netlink message (`genlmsg`) but still attempts to cancel it by passing an error pointer. This improper error handling can lead to a system crash, resulting in a Denial of Service (DoS) for the affected system. 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. 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. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-64005] Do not re-initialize smc hashtables
In the Linux kernel, the following vulnerability has been resolved: net/smc: Do not re-initialize smc hashtables INIT_HLIST_HEAD(&smc_v*_hashinfo.ht) are called after smc_nl_init(), proto_register() and sock_register(). This can lead to smc_v*_hashinfo.ht being reset even though hash entries already exist and are being used, possibly resulting in a corrupted list. Remove unnecessary and dangerous re-initialisation of smc_v*_hashinfo.ht in smc_init(); it is implicitly initialised to zero anyhow. Add HLIST_HEAD_INIT to the definitions for clarity. A flaw was found in the Linux kernel's Server Message Block (SMC) network component. This vulnerability occurs because the system's internal tables, known as hashtables, are improperly reset after they have already been initialized and are actively in use. This incorrect re-initialization can lead to a corrupted list within the kernel. Such corruption could potentially cause system instability or other unpredictable behavior. 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-237. 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. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-63982] Fix ethx:ingress -> ethy:egress -> ethx:ingress mirred loop
In the Linux kernel, the following vulnerability has been resolved: net/sched: Fix ethx:ingress -> ethy:egress -> ethx:ingress mirred loop When mirred redirects to ingress (from either ingress or egress) the loop state from sched_mirred_dev array dev is lost because of 1) the packet deferral into the backlog and 2) the fact the sched_mirred_dev array is cleared. In such cases, if there was a loop we won't discover it. Here's a simple test to reproduce: ip a add dev port0 10.10.10.11/24 tc qdisc add dev port0 clsact tc filter add dev port0 egress protocol ip \ prio 10 matchall action mirred ingress redirect dev port1 tc qdisc add dev port1 clsact tc filter add dev port1 ingress protocol ip \ prio 10 matchall action mirred egress redirect dev port0 ping -c 1 -W0.01 10.10.10.10 A flaw was found in the Linux kernel's network scheduler component. This vulnerability occurs when the `mirred` action, used for redirecting network traffic, fails to properly detect a redirection loop. An attacker can exploit this by crafting specific network configurations that cause packets to be endlessly redirected, leading to a Denial of Service (DoS) condition where system resources are exhausted and network operations are disrupted. 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-835. Affected Red Hat products: Red Hat Enterprise Linux 6.
Medium [CVE-2026-64012] Replace direct dequeue call with peek and qdisc_dequeue_peeked
In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_sfb: Replace direct dequeue call with peek and qdisc_dequeue_peeked When sfb has children (eg qfq qdisc) whose peek() callback is qdisc_peek_dequeued(), we could get a kernel panic. When the parent of such qdiscs (eg illustrated in patch #3 as tbf) wants to retrieve an skb from its child (sfb in this case), it will do the following: 1a. do a peek() - and when sensing there's an skb the child can offer, then - the child in this case(sfb) calls its child's (qfq) peek. qfq does the right thing and will return the gso_skb queue packet. Note: if there wasnt a gso_skb entry then qfq will store it there. Affected products named by the advisory: Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat package: kernel-rt.
Medium [CVE-2026-63983] fix packet loop on netem when duplicate is on
In the Linux kernel, the following vulnerability has been resolved: net/sched: fix packet loop on netem when duplicate is on When netem duplicates a packet it re-enqueues the copy at the root qdisc. If another netem sits in the tree the copy can be duplicated again, recursing until the stack or memory is exhausted. The original duplication guard temporarily zeroed q->duplicate around the re-enqueue, but that does not cover all cases because it is per-qdisc state shared across all concurrent enqueue paths and is not safe without additional locking. Use the skb tc_depth field introduced in an earlier patch: - increment it on the duplicate before re-enqueue - skip duplication for any skb whose tc_depth is already non-zero. This marks the packet itself rather than mutating qdisc state, therefore it is safe regardless of tree topology or concurrency. A flaw was found in the Linux kernel's network emulator (netem) component. This vulnerability occurs when netem duplicates a packet and re-enqueues it, leading to a recursive packet duplication loop if multiple netem instances are configured. This uncontrolled recursion can exhaust system resources, such as memory or stack, resulting in a Denial of Service (DoS) for the affected system. 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.
Medium [CVE-2026-63995] validate start_cmd_payload_size from module
In the Linux kernel, the following vulnerability has been resolved: ethtool: cmis: validate start_cmd_payload_size from module The CMIS firmware update code reads start_cmd_payload_size from the module's FW Management Features CDB reply and uses it directly as the byte count for memcpy. The destination buffer is 112 bytes (ETHTOOL_CMIS_CDB_LPL_MAX_PL_LENGTH - 8). So a malicious module (or corrupted response) can cause a OOB write later on in cmis_fw_update_start_download(). Let's error out. If modules that expect longer LPL writes actually exist we should revisit. struct cmis_cdb_start_fw_download_pl's definition has to move, no change there. A malicious module or a corrupted response can provide an oversized payload size during the firmware update process. This can lead to an out-of-bounds write, allowing an attacker to corrupt memory. This memory corruption could potentially enable a local attacker to escalate privileges or execute arbitrary code within the kernel. 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. 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. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-63977] use __dpll_device_change_ntf and remove change_work
In the Linux kernel, the following vulnerability has been resolved: dpll: zl3073x: use __dpll_device_change_ntf() and remove change_work The change_work was introduced to send device change notifications from DPLL device callbacks without deadlocking on dpll_lock, since the callbacks are already invoked under that lock. Now that __dpll_device_change_ntf() is exported for callers that already hold dpll_lock, use it directly and remove the change_work infrastructure entirely. This eliminates a race condition where change_work could be re-scheduled after cancel_work_sync() during device teardown, potentially causing the handler to dereference a freed or NULL dpll_dev pointer. This can lead to the system attempting to access a memory location that has been freed or is invalid, potentially causing a system crash and resulting in a 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-476. 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. Affected products named by the advisory: Red Hat package: kernel-rt.
Medium [CVE-2026-63969] fix possible infinite loop in rt6_fill_node
In the Linux kernel, the following vulnerability has been resolved: ipv6: fix possible infinite loop in rt6_fill_node() Sashiko reported this issue [1]. Apply the same fix as commit f8d8ce1b515a ("ipv6: fix possible infinite loop in fib6_info_uses_dev()"). Writers holding tb6_lock can list_del_rcu(&rt->fib6_siblings) without waiting for RCU readers; rt->fib6_siblings.next then still points into the old ring and this softirq-side walker never reaches &rt->fib6_siblings, causing a CPU stall. fib6_del_route() always WRITE_ONCE()s rt->fib6_nsiblings to 0 before list_del_rcu(), so an inside-loop check is a reliable detach signal. [1] A flaw was found in the Linux kernel's IPv6 networking subsystem. A local attacker could trigger an infinite loop within the `rt6_fill_node()` function. This occurs when a writer removes an entry from a list without proper synchronization, causing a softirq-side process to continuously loop. The consequence of this vulnerability is a CPU stall, leading to a Denial of Service (DoS) for the system. 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 10; Red Hat Enterprise Linux 6; 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-64013] Fix ACPI GPE handler leak during removal
In the Linux kernel, the following vulnerability has been resolved: ACPI: button: Fix ACPI GPE handler leak during removal Commit a7e23ec17fee ("ACPI: button: Install notifier for system events as well") changed the ACPI notify handler type for ACPI buttons to ACPI_ALL_NOTIFY, but it forgot to update acpi_button_remove() to reflect that change. This leads to leaking the notify handler past driver removal, which may cause a kernel crash to occur if ACPI notify on the given device is triggered after removing the driver, and causes a subsequent probe of the given device with the same driver to fail. Address this by updating the acpi_remove_notify_handler() call in acpi_button_remove() as appropriate. A flaw was found in the Linux kernel's Advanced Configuration and Power Interface (ACPI) button driver. This vulnerability occurs because the ACPI General Purpose Event (GPE) handler is not properly removed when the driver is unloaded. An attacker could potentially trigger an ACPI notify event on a device after its driver has been removed, leading to a kernel crash and system instability. This issue could also prevent the device from being re-initialized correctly. 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. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 9.
Medium [CVE-2026-64021] Fix exec_queue leak on width check in stream open
In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix exec_queue leak on width check in stream open In xe_oa_stream_open_ioctl(), when param.exec_q->width > 1 the function returns -EOPNOTSUPP directly, skipping the existing err_exec_q cleanup path. The exec_queue reference obtained by xe_exec_queue_lookup() is leaked. The exec queue holds a reference on the xe_file, which is only dropped during queue teardown. The leaked lookup ref is not on the file's exec_queue xarray, so file close cannot release it. This keeps both the exec queue and the file private state pinned indefinitely. Jump to err_exec_q instead of returning directly so the reference is released. (cherry picked from commit 339fa0be9e4a5d69fa47e91f4a36574224fb478f) A resource leak occurs in the xe_oa_stream_open_ioctl() function when an exec_queue reference is not properly released. This can cause the exec_queue and associated file private state to remain allocated indefinitely, potentially leading to a denial of service (DoS) condition. 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 10; 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-63991] check skb_clone return value in send_mcast_pkt
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: 6lowpan: check skb_clone() return value in send_mcast_pkt() The skb_clone() function can return NULL if memory allocation fails. send_mcast_pkt() calls skb_clone() without checking the return value, which can lead to a NULL pointer dereference in send_pkt() when it dereferences skb->data. Add a NULL check after skb_clone() and skip the peer if the clone fails. An attacker could exploit this by triggering a scenario where `skb_clone()` returns null, leading to a null pointer dereference. This can result in a system crash, causing 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-476. Affected Red Hat products: Red Hat Enterprise Linux 10. Red Hat does not currently list a fixing RHSA for this CVE. Affected products named by the advisory: Red Hat package: kernel.
Medium [CVE-2026-45784] Heap Corruption from Incorrect Buffer Sizing
rust-openssl provides OpenSSL bindings for the Rust programming language. From 0.10.50 until 0.10.80, CipherCtxRef::cipher_update_inplace in openssl/src/cipher_ctx.rs incorrectly sized output buffers when used with AES key-wrap-with-padding ciphers EVP_aes_{128,192,256}_wrap_pad. For a non-multiple-of-8 input, OpenSSL writes up to 7 bytes past the end of the caller's buffer or Vec, producing attacker-controllable heap corruption when the plaintext length is attacker-influenced. This issue is fixed in version 0.10.80. When processing data with AES key-wrap-with-padding ciphers, the library incorrectly calculates the size of output buffers. This error can lead to memory corruption, where OpenSSL writes beyond the intended buffer boundaries. An attacker capable of influencing the input data's length could exploit this to cause a denial of service or potentially corrupt data. This Moderate flaw in `rust-openssl` can lead to heap corruption when processing data with AES key-wrap-with-padding ciphers. An attacker able to influence the plaintext length could trigger an out-of-bounds write, potentially causing a denial of service or data integrity issues. Exploitation requires the use of these specific ciphers, limiting the attack surface. Red Hat severity: Moderate — CVSS 5.1 (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L). Weakness: CWE-787.
Medium [CVE-2026-45309] Authentication bypass due to path traversal in username during pre-authentication
AsyncSSH is a Python package which provides an asynchronous client and server implementation of the SSHv2 protocol on top of the Python asyncio framework. Prior to 2.23.0, AsyncSSH expands the OpenSSH-compatible AuthorizedKeysFile %u token in asyncssh/config.py, asyncssh/connection.py, asyncssh/auth_keys.py, and asyncssh/misc.py with the raw SSH username during pre-authentication server config reload, allowing a server configured with AuthorizedKeysFile authorized_keys/%u to read an authorized-keys file outside the intended directory when the SSH username contains /, \, or.. path traversal segments and authenticate with an attacker-selected key file. This issue is fixed in version 2.23.0. This allows the attacker to read sensitive authorized-keys files from unintended directories, potentially leading to unauthorized authentication and system access. Red Hat rates this vulnerability as Moderate rather than the upstream HIGH severity because exploitation requires the AsyncSSH server to be specifically configured with AuthorizedKeysFile %u, a non-default setting that is not commonly deployed in Red Hat environments. Affected products named by the advisory: Red Hat Ceph Storage 7; Red Hat Ceph Storage 8; Red Hat Ceph Storage 9.
Medium [CVE-2026-48487] Data integrity vulnerability via malformed DNS records
Zeroconf is a pure Python implementation of multicast DNS service discovery. Prior to 0.149.16, _read_character_string and _read_string in src/zeroconf/_protocol/incoming.py advanced self.offset by attacker-declared RDLENGTH without checking it against self._data_len, allowing unauthenticated hosts on the local link over UDP/5353 (224.0.0.251 / ff02::fb) to send a TXT, HINFO, or A/AAAA record with rdlength=65535 and seed DNSCache and ServiceInfo.properties with truncated, attacker-shaped key/value or address records. This issue is fixed in version 0.149.16. An unauthenticated attacker on the local network can exploit a vulnerability in how the system processes incoming DNS records. By sending a specially crafted record with an excessive length, the attacker can cause the system's DNS cache and service information to be populated with manipulated or truncated data. This could lead to incorrect service discovery or other data integrity issues within the affected system. Prior to 0.149.16, the record string/character-string readers advance the parser offset using an attacker-declared RDLENGTH without checking it against the actual buffer length, allowing a malformed TXT, HINFO, or A/AAAA record to corrupt subsequent record parsing, resulting in data integrity impact for unauthenticated hosts on the local network segment (UDP/5353, 224.0.0.251 / ff02::fb).
Medium [CVE-2026-48045] Unauthenticated network attacker can cause Denial of Service
Zeroconf is a pure Python implementation of multicast DNS service discovery. Prior to 0.149.12, AsyncListener.handle_query_or_defer retained every truncated TC-bit incoming query, each up to _MAX_MSG_ABSOLUTE = 8966 bytes, in self._deferred[addr] and armed a per-address timer in self._timers[addr] without capping the per-address list or distinct addr keys, allowing unauthenticated hosts on the local link over UDP/5353 (224.0.0.251 / ff02::fb) to spoof sources, grow _deferred and _timers, and cause memory exhaustion and quadratic CPU burn. This issue is fixed in version 0.149.12. A flaw was found in zeroconf, a Python library for network service discovery. This vulnerability allows an unauthenticated attacker on the local network to send specially crafted queries. These queries can cause the system to retain large amounts of data and trigger excessive processing, leading to a denial of service (DoS) due to memory exhaustion and high CPU usage. Exploitation requires the attacker to be on the same local link as the affected host, consistent with Red Hat's Adjacent (AV:A) attack vector scoring. Red Hat's CVSS score matches the vendor/CVE.org assessment for this flaw. Affected products named by the advisory: Red Hat OpenShift Container Platform 4; Red Hat OpenStack Platform 16.2; Red Hat OpenStack Platform 17.1; Red Hat OpenStack Platform 18.0.
Medium [CVE-2026-47184] Denial of Service via uncontrolled memory growth
Zeroconf is a pure Python implementation of multicast DNS service discovery. Prior to 0.149.7, DNSCache._async_add inserted every response record into cache, _expirations, _expire_heap, and service_cache without a cap, allowing unauthenticated hosts on the local link over UDP/5353 (224.0.0.251 / ff02::fb) to multicast valid mDNS responses with unique names and cause memory exhaustion, slower cache lookups, slower async_expire passes, and broken discovery, registration, and ServiceBrowser callbacks. This issue is fixed in version 0.149.7. An unauthenticated attacker on the local network can send specially crafted multicast DNS responses. This can lead to uncontrolled memory growth, causing memory exhaustion and significantly degrading the performance of the service, ultimately resulting in a denial of service (DoS). Exploitation requires the attacker to be on the same local link as the affected host, consistent with Red Hat's Adjacent (AV:A) attack vector scoring. Red Hat's CVSS score matches the vendor/CVE.org assessment for this flaw. This flaw is one of a batch of related Zeroconf issues discovered and fixed close together (CVE-2026-47180, CVE-2026-47183, CVE-2026-47184, CVE-2026-48045, CVE-2026-48487); all affect the same Red Hat product streams in the same way and were triaged consistently as a batch.
Medium [CVE-2026-47183] Denial of Service via unbounded memory growth from mDNS messages
Zeroconf is a pure Python implementation of multicast DNS service discovery. Prior to 0.149.6, DNSIncoming._log_exception_debug and the four QuietLogger exception-dedup methods stored an unbounded _seen_logs dictionary keyed by attacker-influenced IncomingDecodeError messages, retaining sys.exc_info() tracebacks whose frame locals kept raw packet self.data buffers and allowing unauthenticated hosts on the local link over UDP/5353 (224.0.0.251 / ff02::fb) to drive memory growth until mDNS-dependent features degrade or the process is OOM-killed. This issue is fixed in version 0.149.6. An unauthenticated attacker on the local network can send specially crafted mDNS messages, causing the system to store an unbounded number of error messages. This can lead to excessive memory consumption, resulting in a denial of service (DoS) where mDNS-dependent features degrade or the process terminates unexpectedly. Prior to 0.149.6, the exception-deduplication cache that tracks malformed-packet decode errors grows without bound, retaining full tracebacks (including raw packet buffers) keyed by attacker-influenced error messages, leading to unbounded memory growth, resulting in denial of service impact for unauthenticated hosts on the local network segment (UDP/5353, 224.0.0.251 / ff02::fb).
Medium [CVE-2026-47180] Denial of Service via crafted mDNS packets
Zeroconf is a pure Python implementation of multicast DNS service discovery. Prior to 0.149.5, DNSIncoming._decode_labels_at_offset recurses once per DNS-name compression pointer, and a single mDNS packet carrying chained pointers can trigger a RecursionError that escapes DNSIncoming.__init__, causing sustained CPU burn, log flooding, and degraded mDNS-dependent features for unauthenticated hosts on the local link over UDP/5353 (224.0.0.251 / ff02::fb). This issue is fixed in version 0.149.5. This can trigger a recursion error, leading to sustained CPU usage, excessive logging, and degraded mDNS services, ultimately causing a Denial of Service. Exploitation requires the attacker to be on the same local link as the affected host, consistent with Red Hat's Adjacent (AV:A) attack vector scoring. Red Hat's CVSS score matches the vendor/CVE.org assessment for this flaw. This flaw is one of a batch of related Zeroconf issues discovered and fixed close together (CVE-2026-47180, CVE-2026-47183, CVE-2026-47184, CVE-2026-48045, CVE-2026-48487); all affect the same Red Hat product streams in the same way and were triaged consistently as a batch. Red Hat severity: Moderate — CVSS 6.5 (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-835.
Medium [CVE-2026-53712] Authentication downgrade via TLS man-in-the-middle attack
SCRAM (Salted Challenge Response Authentication Mechanism) is part of the family of Simple Authentication and Security Layer (SASL, RFC 4422) authentication mechanisms. Prior to 3.3, a flaw in com.ongres.scram:scram-client and com.ongres.scram:scram-common allows an attacker capable of a TLS man-in-the-middle attack to silently downgrade a connection from SCRAM-SHA-256-PLUS with channel binding to standard SCRAM-SHA-256 without channel binding when TlsServerEndpoint processes an X.509 certificate using a modern signature algorithm such as Ed25519; getChannelBindingData() can return an empty byte array after NoSuchAlgorithmException, and the ScramClient builder treats that as absent channel-binding data. This issue is fixed in version 3.3. This vulnerability allows the attacker to bypass the stronger SCRAM-SHA-256-PLUS authentication with channel binding, forcing a weaker SCRAM-SHA-256 authentication without channel binding, which could compromise the integrity of the authentication. While requiring a sophisticated network attack, successful exploitation bypasses stronger channel-bound authentication, potentially compromising the integrity of user sessions. Red Hat severity: Moderate — CVSS 5.9 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N). Weakness: CWE-303.