VulniPulse uses Google Ads measurement to understand visits from advertisements and campaign performance. It runs cookie-free until you choose — accepting enables cookies for more accurate attribution. Rejecting keeps it cookie-free and never limits the site.
See exactly what is measuredComplete feed
4112 advisories across 32 monitored vendors.
Nokogiri is an open source XML and HTML library for the Ruby programming language. Prior to 1.19.4, the NONET parse option, which Nokogiri turns on by default for Nokogiri::XML::Schema (see CVE-2020-26247), was not correctly enforced on the JRuby implementation. As a result, a schema parsed with default options could still cause external resources to be fetched over the network, potentially enabling SSRF or XXE attacks. This vulnerability is fixed in 1.19.4. This oversight could allow a specially crafted XML schema to fetch external resources over the network, potentially leading to Server-Side Request Forgery (SSRF) or XML External Entity (XXE) attacks. Red Hat products are not affected by this vulnerability. Red Hat products use the CRuby (MRI) implementation, where NONET is correctly enforced and external resource fetching is properly blocked. Red Hat severity: Low — CVSS 4.8 (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:N/A:N). Weakness: CWE-611. Red Hat lists Red Hat 3scale API Management Platform 2; Red Hat Satellite 6 as not affected.
Nokogiri is an open source XML and HTML library for the Ruby programming language. Prior to 1.19.4, calling Document#encoding= with an invalid encoding (e.g., a non-string, or a string containing a null byte) raises an exception, but only after freeing the document's current encoding string without replacing it. The document is left referencing freed memory, so the next call to Document#encoding reads invalid memory, which can cause a segfault or leak freed bytes into a Ruby String. Affects the CRuby (libxml2) implementation only; JRuby is not affected. This vulnerability is fixed in 1.19.4. This leaves the document referencing freed memory, which can lead to a denial of service (DoS) due to a segmentation fault or information disclosure by leaking freed memory into a Ruby String. This flaw has an Important impact as Nokogiri's CRuby implementation in Red Hat products is vulnerable to a use-after-free when processing invalid encoding values. Red Hat severity: Moderate — CVSS 6.5 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:H). Weakness: CWE-825. Affected Red Hat products: Red Hat Satellite 6. Red Hat does not currently list a fixing RHSA for this CVE.
A vulnerability has been identified in the **GNOME Geary** package within its **`mailto` URI handling** component. This flaw occurs because the email client automatically processes a non-standard `attach` parameter in email links without prompting or alerting the user. An attacker could exploit this by tricking a user into clicking a specially crafted link (for example, `mailto:user@example.com?attach=/path/to/sensitive_file`). When clicked, Geary will automatically open a new compose window with the specified local file already attached. Because there is no dialog box or visual warning indicating that the file was attached by the link rather than the user, the user might unknowingly send sensitive files or data to the attacker upon hitting send. - This issue is classified as Moderate severity primarily. - Conditions for Exploitation: Exploitation requires significant user interaction, as a victim must be tricked into manually sending the email without noticing the unexpectedly attached file. - Impact Limitations: The vulnerability is strictly limited to targeted information disclosure, and does not allow for remote code execution, broader system compromise, or privilege escalation. Red Hat severity: Moderate — CVSS 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N).
GitLab has remediated an issue in GitLab CE/EE affecting all versions from 9.3 before 18.11.6, 19.0 before 19.0.3, and 19.1 before 19.1.1 that under certain conditions could have allowed sensitive information to be written to application logs due to insufficient filtering in a CI/CD API endpoint.
GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.11 before 18.11.6, 19.0 before 19.0.3, and 19.1 before 19.1.1 that under certain conditions could have allowed an authenticated user with developer-role permissions to bypass package protection rules and overwrite protected Maven package metadata due to incorrect authorization checks.
GitLab has remediated an issue in GitLab CE/EE affecting all versions from 13.6 before 18.11.6, 19.0 before 19.0.3, and 19.1 before 19.1.1 that under certain conditions could have allowed an authenticated user with Reporter-level group permissions to view package metadata from projects with the Package Registry disabled due to incorrect authorization checks in the group packages feature.
GitLab has remediated an issue in GitLab EE affecting all versions from 18.6 before 18.11.6, 19.0 before 19.0.3, and 19.1 before 19.1.1 that under certain conditions could have allowed an authenticated user to read or modify another group's virtual registry cleanup policy settings without authorization.
GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.5 before 18.11.6, 19.0 before 19.0.3, and 19.1 before 19.1.1 that under certain conditions could have allowed an unauthenticated user to view confidential issue references on public projects due to improper authorization checks.
GitLab has remediated an issue in GitLab CE/EE affecting all versions from 14.8 before 18.11.6, 19.0 before 19.0.3, and 19.1 before 19.1.1 that under certain conditions could have allowed an authenticated user to conceal content within a Snippet due to improper input validation.
GitLab has remediated an issue in GitLab EE affecting all versions from 13.11 prior to 18.11.6, 19.0 prior to 19.0.3, and 19.1 prior to 19.1.1 in which incorrect authorization in DAST site profile management could allow a user with Developer role to exfiltrate DAST site profile secrets under certain conditions.
shell-quote prior to 1.8.5 finalizes parsed tokens in parse() using Array.prototype.concat as a reduce accumulator, which reallocates and copies the entire growing array on every iteration. As a result parse() runs in O(n^2) time relative to the number of input tokens. An attacker who can supply an attacker-controlled string to any code path that calls parse() (no shell metacharacters are required; plain space-separated words suffice) can block the single-threaded Node.js event loop for an extended period with a small input, resulting in a denial of service. There is no code execution or data disclosure; impact is to availability only. Fixed in 1.8.5. An attacker who can supply a specially crafted string to the `parse()` function can exploit an inefficiency in how the component processes input. A flaw was found in the shell-quote npm package's `parse()` function, which uses an `O(n²)` array concatenation pattern when processing tokens. The vulnerable `parse()` function is not typically exposed to external user input in Red Hat product deployments, reducing the practical exploitability of this flaw. Red Hat severity: Moderate — CVSS 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-1050. Affected products named by the advisory: Cryostat 4; Gatekeeper 3; Migration Toolkit for Containers; Node HealthCheck Operator; and 22 more.
A flaw was found in KubeVirt's virt-handler network cache handling. The WriteToCachedFile function writes data to a launcher-rooted path using os.WriteFile and os.Chown without symlink protection. A user with access to the virt-launcher container can plant a symlink at the cache file path, causing virt-handler to follow it and overwrite an arbitrary host file with JSON content and change its ownership. This flaw affects OpenShift Virtualization deployments where virtual machines are configured with bridge or other non-masquerade network interfaces. The default network binding mode in OpenShift Virtualization is masquerade, which does not trigger the vulnerable code path — exploitation requires a cluster administrator to have pre-configured a NetworkAttachmentDefinition with bridge-type binding, a condition beyond the attacker's control. Additionally, the attacker must have exec access to the virt-launcher container (not merely VM guest console access). The file content written by the exploit is constrained to valid JSON following the network cache schema — arbitrary byte injection is not possible. On OpenShift Container Platform, SELinux mandatory access controls in enforcing mode restrict the set of host files writable by the virt-handler process, and base OS binaries under /usr/ are protected by RHCOS read-only ostree layers.
A server-side request forgery (SSRF) flaw was found in KubeVirt's virt-api port-forward handler. When processing a port-forward request to a VirtualMachineInstance (VMI), virt-api reads the target IP from vmi.Status.Interfaces[0].IP and passes it directly to net.Dial() without validation. For VMIs using non-masquerade network bindings (bridge or secondary-only), this IP is reported by the QEMU guest agent running inside the VM and is fully controllable by the VM owner. An attacker with kubevirt.io:edit permissions can create a VM with a modified guest agent that reports an arbitrary IP address, then request port-forward to establish a bidirectional TCP tunnel from virt-api's cluster-internal network position to any routable destination, bypassing NetworkPolicy isolation. Red Hat has rated this issue as Moderate impact. Only VMs configured with bridge binding or secondary-only network interfaces (which require a cluster administrator to have created a NetworkAttachmentDefinition) are affected. Red Hat severity: Moderate — CVSS 6.4 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N). Weakness: CWE-918. Affected Red Hat products: Red Hat OpenShift Virtualization 4. Red Hat does not currently list a fixing RHSA for this CVE.
In the Linux kernel, the following vulnerability has been resolved: USB: serial: kl5kusb105: fix bulk-out buffer overflow klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied.
In the Linux kernel, the following vulnerability has been resolved: locking/rtmutex: Skip remove_waiter() when waiter is not enqueued syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI: KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd ("rtmutex: Use waiter::task instead of current in remove_waiter()") made this fatal. Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 ("futex: Handle early deadlock return correctly"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex(). A local attacker could trigger a null-pointer dereference by using the `FUTEX_CMP_REQUEUE_PI` operation. This vulnerability occurs because the `remove_waiter()` function is called when the waiter is not properly enqueued, leading to a system crash and a denial of service (DoS). This issue was detected by KASAN (Kernel Address Sanitizer).
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind: DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed. When an XDP (eXpress Data Path) transmission fails, the driver does not properly unmap DMA (Direct Memory Access) addresses or free allocated XDP frames.
In the Linux kernel, the following vulnerability has been resolved: mptcp: allow subflow rcv wnd to shrink In MPTCP connection, the `window` field in the TCP header refers to the MPTCP-level rcv_nxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog). As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving. Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting. This vulnerability occurs because the TCP stack independently manages the TCP-level receive window, which can lead to an artificial inflation of the MPTCP receive window. A remote attacker could exploit this by sending specific traffic, causing the incoming data to exceed the receiver's buffer size. This can result in a Denial of Service (DoS) condition, making the system unresponsive to legitimate traffic. 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-131. 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.
In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.
In the Linux kernel, the following vulnerability has been resolved: udp: clear skb->dev before running a sockmap verdict On the UDP receive path skb->dev is repurposed as dev_scratch (the truesize/state cache set by udp_set_dev_scratch()), through the union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff. When a UDP socket is in a sockmap, sk_data_ready is sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor() (sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq. Clear skb->dev so bpf_skc_lookup() falls back to sock_net(skb->sk), which skb_set_owner_sk_safe() set just above. When a User Datagram Protocol (UDP) socket is configured with a sockmap, and a BPF (Berkeley Packet Filter) program attached to it calls a socket-lookup helper, the `skb->dev` field is not properly cleared. This improper handling of the `skb->dev` field can lead to a general protection fault, resulting in a Denial of Service (DoS) condition. A local attacker with the necessary permissions to load BPF programs could potentially trigger this vulnerability. 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-909. 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.
In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: rtw_mlme: add bounds checks before ie_length subtraction Add guards to ensure ie_length is large enough before subtracting fixed IE offsets to prevent unsigned integer underflow. A flaw was found in the Linux kernel, specifically within the `rtl8723bs` Wi-Fi driver's `rtw_mlme` component. This issue could potentially impact system stability or integrity. Red Hat severity: Moderate. Weakness: CWE-191. 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.