Skip to content
VulniPulse

Complete feed

No mitigation yet

No fix, workaround or mitigation extracted yet

Home overview

Android app · Google Play

Take your CVE monitoring with you.

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.

Medium6.4Red Hat

Medium [CVE-2026-60183] Clone Plugin unspecified vulnerability (CPU Jul 2026)

Clone Plugin unspecified vulnerability (CPU Jul 2026). Red Hat rates this moderate (CVSS 6.4). Weakness: CWE-266.

CVE-2026-60183
Unclassified
Jul 21, 2026
Medium6.6Red Hat

Medium [CVE-2026-60585] Replication unspecified vulnerability (CPU Jul 2026)

Replication unspecified vulnerability (CPU Jul 2026). Red Hat rates this moderate (CVSS 6.6). Weakness: CWE-266.

CVE-2026-60585
Unclassified
Jul 21, 2026
Low3.4Red Hat

Low [CVE-2026-16410] JIT miscompilation in the JavaScript Engine: JIT component

JIT miscompilation in the JavaScript Engine: JIT component. Red Hat rates this low (CVSS 3.4). Weakness: CWE-1037.

CVE-2026-16410
Unclassified
Jul 21, 2026
Low3.4Red Hat

Low [CVE-2026-16409] Invalid pointer in the Security: PSM component

Invalid pointer in the Security: PSM component. Red Hat rates this low (CVSS 3.4). Weakness: CWE-476.

CVE-2026-16409
Unclassified
Jul 21, 2026
Low3.4Red Hat

Low [CVE-2026-16408] Integer overflow in the Audio/Video: Playback component

Integer overflow in the Audio/Video: Playback component. Red Hat rates this low (CVSS 3.4). Weakness: CWE-190.

CVE-2026-16408
Unclassified
Jul 21, 2026
Low3.4Red Hat

Low [CVE-2026-16407] Mitigation bypass in the DOM: Service Workers component

Mitigation bypass in the DOM: Service Workers component. Red Hat rates this low (CVSS 3.4). Weakness: CWE-807.

CVE-2026-16407
Unclassified
Jul 21, 2026
Low3.4Red Hat

Low [CVE-2026-16406] Mitigation bypass in the Networking component

Mitigation bypass in the Networking component. This vulnerability was fixed in Firefox 153 and Thunderbird 153. Red Hat Product Security rates the severity of this flaw as determined by the Mozilla Foundation Security Advisory. Red Hat severity: Low — CVSS 3.4 (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:N/A:N). 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: thunderbird.

CVE-2026-16406
Red Hat Enterprise Linux
Jul 21, 2026
Low3.4Red Hat

Low [CVE-2026-16404] Spoofing issue in Firefox for Android

Spoofing issue in Firefox for Android. Red Hat rates this low (CVSS 3.4). Weakness: CWE-290.

CVE-2026-16404
Unclassified
Jul 21, 2026
Low3.4Red Hat

Low [CVE-2026-16403] Spoofing issue in the Address Bar component

Spoofing issue in the Address Bar component. This vulnerability was fixed in Firefox 153 and Thunderbird 153. Red Hat Product Security rates the severity of this flaw as determined by the Mozilla Foundation Security Advisory. Red Hat severity: Low — CVSS 3.4 (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:N/A:N). 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.

CVE-2026-16403
Unclassified
Jul 21, 2026
Low2.7Red Hat

Low [CVE-2026-61081] Performance Schema unspecified vulnerability (CPU Jul 2026)

Performance Schema unspecified vulnerability (CPU Jul 2026). Red Hat rates this low (CVSS 2.7). Weakness: CWE-497.

CVE-2026-61081
Unclassified
Jul 21, 2026
Low2.2Red Hat

Low [CVE-2026-60190] Replication unspecified vulnerability (CPU Jul 2026)

Replication unspecified vulnerability (CPU Jul 2026). Red Hat rates this low (CVSS 2.2). Weakness: CWE-770.

CVE-2026-60190
Unclassified
Jul 21, 2026
Low2.9Red Hat

Low [CVE-2026-61096] Pluggable Auth unspecified vulnerability (CPU Jul 2026)

Pluggable Auth unspecified vulnerability (CPU Jul 2026). Red Hat rates this low (CVSS 2.9). Weakness: CWE-266.

CVE-2026-61096
Unclassified
Jul 21, 2026
Critical9.8Red Hat

Critical [CVE-2026-64193] Net::DNS: Net::DNS: Arbitrary code execution via EDNS EXTENDED ERROR handling

Net::DNS: Net::DNS: Arbitrary code execution via EDNS EXTENDED ERROR handling. Red Hat rates this critical (CVSS 9.8). Weakness: CWE-78.

CVE-2026-64193
Unclassified
Jul 20, 2026
High7.0Vendor: MediumRed Hat

High [CVE-2026-64192] Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is uninitialized

In the Linux kernel, the following vulnerability has been resolved: bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is uninitialized When CONFIG_BPF_LSM=y is set, BPF inode storage maps (BPF_MAP_TYPE_INODE_STORAGE) are compiled into the kernel. However, if the BPF LSM is not explicitly enabled at boot time (e.g. omitted from the "lsm=" boot parameter), lsm_prepare() is never executed for the BPF LSM. Consequently, the BPF inode security blob offset (bpf_lsm_blob_sizes.lbs_inode) is never initialized and remains at its default compiled size of 8 bytes instead of being updated to a valid offset past the reserved struct rcu_head (typically 16 bytes or more). When a privileged user creates and updates a BPF_MAP_TYPE_INODE_STORAGE map, bpf_inode() evaluates inode->i_security + 8. This erroneously aliases the struct rcu_head.func callback pointer at the beginning of the inode->i_security blob. During subsequent map element cleanup or inode destruction, writing NULL to owner_storage clears the queued RCU callback pointer. When rcu_do_batch() later executes the queued callback, it attempts an instruction fetch at address 0x0, triggering an immediate kernel panic. Fix this by introducing a global bpf_lsm_initialized boolean flag marked with __ro_after_init. Set this flag to true inside bpf_lsm_init() when the LSM framework successfully registers the BPF LSM.

CVE-2026-64192
Linux Kernel
Jul 20, 2026
Medium5.9Red Hat

Medium [CVE-2026-64194] Net::DNS: Net::DNS: Denial of Service via crafted DNS compression pointers

Net::DNS versions through 1.55 for Perl allow Denial of Service via deep DNS compression pointer chains. Net::DNS::DomainName::decode follows RFC 1035 compression pointers by recursing into itself with no depth limit. It is possible to construct a name which saturates the call stack (at least with larger TCP responses), leading to a potential Denial of Service. The guard `$link new(\$wire)` i.e. any point where the library decodes a DNS message from the network. A remote attacker can exploit this vulnerability by sending a specially crafted DNS packet with deep compression pointer chains. This can cause excessive recursion in the `Net::DNS::DomainName::decode` function, leading to stack exhaustion and a Denial of Service (DoS) for any application processing untrusted DNS data. Contrary to the CVE description, this issue does not easily trigger an application crash via stack memory exhaustion, as the Perl interpreter h… Affected products named by the advisory: Red Hat Enterprise Linux 7; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9.

CVE-2026-64194
Unclassified
Jul 20, 2026
Medium5.3Red Hat

Medium [CVE-2026-26199] Denial of Service via buffer underflow in H5Iget_name

HDF5 is a high-performance library and a file format specification that implements the HDF5 data model. If `H5Iget_name` is invoked on a group id with `0` for the size parameter, it will underflow when trying to place a null terminator in the buffer. This can occur if `H5Iget_name` is invoked in a way where `size` can be forced to zero, and there is important data before the `name` buffer. A flaw was found in HDF5, a library used for managing large datasets. This vulnerability occurs when a specific function, H5Iget_name, is called with an invalid size parameter, leading to a buffer underflow. An attacker could exploit this by providing specially crafted input, potentially causing the application to crash or become unavailable, resulting in a denial of service (DoS). This Moderate vulnerability in HDF5 involves a buffer underflow in the `H5Iget_name` function, which can lead to a denial of service. Exploitation requires an attacker to provide specially crafted input that forces the `size` parameter to zero, a condition not commonly encountered in default Red Hat configurations, thus limiting the attack's practicality. Red Hat severity: Moderate — CVSS 5.3 (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:H). Weakness: CWE-124. Affected Red Hat products: Red Hat AI Inference Server; Red Hat Enterprise Linux AI (RHEL AI) 3; Red Hat OpenShift AI (RHOAI).

CVE-2026-26199
Unclassified
Jul 20, 2026
Medium5.3Red Hat

Medium [CVE-2026-26197] Out-of-bounds read due to corrupted file can lead to denial of service

HDF5 is a high-performance library and a file format specification that implements the HDF5 data model. If a file is corrupted such that an array datatype's size, the number of elements, and the element size are not in agreement it can trigger an out of bounds read. The array datatype stores the full size of the datatype (`dt->shared->size`) separately from the number of elements (`dt->shared->u.array.nelem`) and the element size (`dt->shared->parent->shared->size`). If any one of these are corrupted so that they don't align with the others (element size * nelem = full size), it can lead to an out of bounds read. Depending on what is corrupted, it can alter the type of out of bounds read triggered. The vulnerability is present only in files that have been maliciously altered, as its generally not possible to independently alter the full size of the datatype, the element count and the element size. As such, this is only present if a malicious actor is altering files, and won't appear in regular usage. A remote attacker can exploit this vulnerability by providing a maliciously altered HDF5 file. This can lead to a denial of service (DoS) by causing the application to crash or become unresponsive. This Moderate flaw in HDF5 is due to an out-of-bounds read when processing a maliciously crafted HDF5 file with inconsistent array datatype metadata.

CVE-2026-26197
Unclassified
Jul 20, 2026
Medium6.5Red Hat

Medium [CVE-2026-15813] memory corruption and out-of-bounds access via malformed network packet defragmentation

A vulnerability was found in the network packet de-fragmentation engine of kronosnet (Version affected <= 1.34). The internal reassembly code does not properly validate sequence numbers of incoming payload fragments. An attacker can exploit this lack of verification by transmitting malformed packets with corrupted sequence parameters. Under specific conditions, this forces the packet processing layer to parse data outside the designated bounds of the internal memory structures, causing an out-of-bounds memory access or heap corruption. This behavior can result in sudden application crashes or system instability. Red Hat Product Security rates this vulnerability's impact as Low. While memory corruption and out-of-bounds access conditions are technically severe flaw types (typically rated Moderate or Important), the deployment requirements drastically reduce the real-world threat vector. The flaw can only be reached if kronosnet is running completely unencrypted traffic (a setting unsupported for production) and the attacker is capable of spoofing a trusted IP address already authorized within the cluster infrastructure to pass initial Access Control Lists (ACLs). Affected products named by the advisory: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat OpenShift Container Platform 4; and 1 more.

CVE-2026-15813
Red Hat Enterprise Linux
Jul 20, 2026
Medium5.5Red Hat

Medium [CVE-2026-64206] cancel pending_rx_work before taking conn->lock

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock l2cap_conn_del() takes conn->lock and then calls cancel_work_sync() for pending_rx_work. process_pending_rx() takes the same mutex, so teardown can deadlock against the worker it is flushing. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the l2cap_conn_ready() -> queue_work(..., &conn->pending_rx_work) submit path, the l2cap_conn_del() -> cancel_work_sync(&conn->pending_rx_work) teardown path, and the process_pending_rx() -> mutex_lock(&conn->lock) worker edge. Lockdep WARNING: possible circular locking dependency detected process_pending_rx+0x21/0x2a [vuln_msv] l2cap_conn_del.constprop.0+0x3f/0x4e [vuln_msv] *** DEADLOCK *** Cancel pending_rx_work before taking conn->lock, matching the existing lock-before-drain ordering used for the two delayed works in the same teardown path. The pending_rx queue is still purged after the work has been cancelled and conn->lock has been acquired. A flaw was found in the Linux kernel's Bluetooth Logical Link Control and Adaptation Protocol (L2CAP) subsystem. A local attacker could trigger a deadlock during connection teardown due to a circular locking dependency between `l2cap_conn_del()` and `process_pending_rx()` functions.

CVE-2026-64206
Linux Kernel
Jul 20, 2026
Medium5.5Red Hat

Medium [CVE-2026-64190] fix NULL pointer dereference in team_xmit during mode change

In the Linux kernel, the following vulnerability has been resolved: net: team: fix NULL pointer dereference in team_xmit during mode change __team_change_mode() clears team->ops with memset() before restoring safe dummy handlers via team_adjust_ops(). A concurrent team_xmit() running under RCU on another CPU can read team->ops.transmit during this window and call a NULL function pointer, crashing the kernel. The race requires a mode change (CAP_NET_ADMIN) concurrent with transmit on the team device. BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: 0010 [#1] SMP KASAN NOPTI RIP: 0010:0x0 Call Trace: team_xmit (drivers/net/team/team_core.c:1853) dev_hard_start_xmit (net/core/dev.c:3904) __dev_queue_xmit (net/core/dev.c:4871) packet_sendmsg (net/packet/af_packet.c:3109) __sys_sendto (net/socket.c:2265) The original code assumed that no ports means no traffic, so mode changes could freely memset()/memcpy() the ops. AF_PACKET with forced carrier breaks that assumption. Prevent the race instead of making it safe: replace memset()/memcpy() with per-field updates that never touch transmit or receive. Those two handlers are managed solely by team_adjust_ops(), which already installs dummies when tx_en_port_count == 0 (always true during mode change since no ports are present).

CVE-2026-64190
Linux Kernel
Jul 20, 2026