Export limit exceeded: 349863 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (349863 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-28930 | 1 Apple | 1 Macos | 2026-05-11 | N/A |
| A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Tahoe 26.5. An app may be able to access protected user data. | ||||
| CVE-2026-43654 | 1 Apple | 5 Ios And Ipados, Macos, Tvos and 2 more | 2026-05-11 | N/A |
| The issue was addressed with improved memory handling. This issue is fixed in iOS 18.7.9 and iPadOS 18.7.9, iOS 26.5 and iPadOS 26.5, macOS Sequoia 15.7.7, macOS Sonoma 14.8.7, macOS Tahoe 26.5, tvOS 26.5, visionOS 26.5, watchOS 26.5. An app may be able to disclose kernel memory. | ||||
| CVE-2026-43655 | 1 Apple | 4 Ios And Ipados, Macos, Tvos and 1 more | 2026-05-11 | N/A |
| An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in iOS 26.5 and iPadOS 26.5, macOS Tahoe 26.5, tvOS 26.5, watchOS 26.5. An app may be able to cause unexpected system termination or read kernel memory. | ||||
| CVE-2026-28897 | 1 Apple | 5 Ios And Ipados, Macos, Tvos and 2 more | 2026-05-11 | N/A |
| A buffer overflow was addressed with improved input validation. This issue is fixed in iOS 18.7.9 and iPadOS 18.7.9, iOS 26.5 and iPadOS 26.5, macOS Sequoia 15.7.7, macOS Sonoma 14.8.7, macOS Tahoe 26.5, tvOS 26.5, visionOS 26.5, watchOS 26.5. A local user may be able to cause unexpected system termination or read kernel memory. | ||||
| CVE-2026-43652 | 1 Apple | 1 Macos | 2026-05-11 | N/A |
| A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Tahoe 26.5. An app may be able to access protected user data. | ||||
| CVE-2026-28941 | 1 Apple | 2 Ios And Ipados, Macos | 2026-05-11 | N/A |
| The issue was addressed with improved checks. This issue is fixed in iOS 18.7.9 and iPadOS 18.7.9, macOS Sequoia 15.7.7, macOS Tahoe 26.5. Processing a maliciously crafted file may lead to a denial-of-service or potentially disclose memory contents. | ||||
| CVE-2026-42050 | 1 Imagemagick | 1 Imagemagick | 2026-05-11 | 5.5 Medium |
| ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to 7.1.2-21 and 6.9.13-46, a malicious MIFF file could trigger an overflow when a user opens it in the display tool and right-clicks a tile to invoke the Load / Update menu item. This vulnerability is fixed in 7.1.2-21 and 6.9.13-46. | ||||
| CVE-2026-28918 | 1 Apple | 5 Ios And Ipados, Macos, Tvos and 2 more | 2026-05-11 | N/A |
| An out-of-bounds access issue was addressed with improved bounds checking. This issue is fixed in iOS 26.5 and iPadOS 26.5, macOS Tahoe 26.5, tvOS 26.5, visionOS 26.5, watchOS 26.5. Parsing a maliciously crafted file may lead to an unexpected app termination. | ||||
| CVE-2026-28942 | 1 Apple | 5 Ios And Ipados, Macos, Tvos and 2 more | 2026-05-11 | N/A |
| A use-after-free issue was addressed with improved memory management. This issue is fixed in iOS 26.5 and iPadOS 26.5, macOS Tahoe 26.5, tvOS 26.5, visionOS 26.5, watchOS 26.5. Processing maliciously crafted web content may lead to an unexpected Safari crash. | ||||
| CVE-2026-28923 | 1 Apple | 1 Macos | 2026-05-11 | N/A |
| A logging issue was addressed with improved data redaction. This issue is fixed in macOS Sequoia 15.7.7, macOS Sonoma 14.8.7, macOS Tahoe 26.5. A malicious app may be able to break out of its sandbox. | ||||
| CVE-2026-28940 | 1 Apple | 4 Ios And Ipados, Macos, Tvos and 1 more | 2026-05-11 | N/A |
| The issue was addressed with improved memory handling. This issue is fixed in iOS 18.7.9 and iPadOS 18.7.9, iOS 26.5 and iPadOS 26.5, macOS Sequoia 15.7.7, macOS Tahoe 26.5, tvOS 26.5, visionOS 26.5. Processing a maliciously crafted image may corrupt process memory. | ||||
| CVE-2026-43653 | 1 Apple | 3 Ios And Ipados, Macos, Tvos | 2026-05-11 | N/A |
| The issue was addressed with improved memory handling. This issue is fixed in iOS 18.7.9 and iPadOS 18.7.9, iOS 26.5 and iPadOS 26.5, macOS Sonoma 14.8.7, macOS Tahoe 26.5, tvOS 26.5. An attacker on the local network may be able to cause a denial-of-service. | ||||
| CVE-2026-43874 | 1 Wwbn | 1 Avideo | 2026-05-11 | 7.2 High |
| WWBN AVideo is an open source video platform. In versions up to and including 29.0, the server-side mitigation for the YPTSocket autoEvalCodeOnHTML eval sink (from CVE-2026-40911) only strips the payload when it sits under $json['msg'], but the relay function msgToResourceId() selects the outbound message from $msg['json'] before $msg['msg']. An unauthenticated attacker can obtain a WebSocket token from plugin/YPTSocket/getWebSocket.json.php, connect to the WebSocket server, and send a message with autoEvalCodeOnHTML nested under a top-level json field — the strip branch is skipped, the relay delivers the payload verbatim to any logged-in user identified by to_users_id, and the client script runs it through eval(). Commit 9f3006f9a89a34daa67a83c6ad35f450cb91fcce contains an updated fix. | ||||
| CVE-2026-43425 | 1 Linux | 1 Linux Kernel | 2026-05-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: usb: image: mdc800: kill download URB on timeout mdc800_device_read() submits download_urb and waits for completion. If the timeout fires and the device has not responded, the function returns without killing the URB, leaving it active. A subsequent read() resubmits the same URB while it is still in-flight, triggering the WARN in usb_submit_urb(): "URB submitted while active" Check the return value of wait_event_timeout() and kill the URB if it indicates timeout, ensuring the URB is complete before its status is inspected or the URB is resubmitted. Similar to - commit 372c93131998 ("USB: yurex: fix control-URB timeout handling") - commit b98d5000c505 ("media: rc: iguanair: handle timeouts") | ||||
| CVE-2026-43371 | 1 Linux | 1 Linux Kernel | 2026-05-11 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net: macb: Shuffle the tx ring before enabling tx Quanyang observed that when using an NFS rootfs on an AMD ZynqMp board, the rootfs may take an extended time to recover after a suspend. Upon investigation, it was determined that the issue originates from a problem in the macb driver. According to the Zynq UltraScale TRM [1], when transmit is disabled, the transmit buffer queue pointer resets to point to the address specified by the transmit buffer queue base address register. In the current implementation, the code merely resets `queue->tx_head` and `queue->tx_tail` to '0'. This approach presents several issues: - Packets already queued in the tx ring are silently lost, leading to memory leaks since the associated skbs cannot be released. - Concurrent write access to `queue->tx_head` and `queue->tx_tail` may occur from `macb_tx_poll()` or `macb_start_xmit()` when these values are reset to '0'. - The transmission may become stuck on a packet that has already been sent out, with its 'TX_USED' bit set, but has not yet been processed. However, due to the manipulation of 'queue->tx_head' and 'queue->tx_tail', `macb_tx_poll()` incorrectly assumes there are no packets to handle because `queue->tx_head == queue->tx_tail`. This issue is only resolved when a new packet is placed at this position. This is the root cause of the prolonged recovery time observed for the NFS root filesystem. To resolve this issue, shuffle the tx ring and tx skb array so that the first unsent packet is positioned at the start of the tx ring. Additionally, ensure that updates to `queue->tx_head` and `queue->tx_tail` are properly protected with the appropriate lock. [1] https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm | ||||
| CVE-2026-43357 | 1 Linux | 1 Linux Kernel | 2026-05-11 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050-core: fix pm_runtime error handling The return value of pm_runtime_get_sync() is not checked, allowing the driver to access hardware that may fail to resume. The device usage count is also unconditionally incremented. Use pm_runtime_resume_and_get() which propagates errors and avoids incrementing the usage count on failure. In preenable, add pm_runtime_put_autosuspend() on set_8khz_samplerate() failure since postdisable does not run when preenable fails. | ||||
| CVE-2026-43356 | 1 Linux | 1 Linux Kernel | 2026-05-11 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: iio: imu: adis: Fix NULL pointer dereference in adis_init The adis_init() function dereferences adis->ops to check if the individual function pointers (write, read, reset) are NULL, but does not first check if adis->ops itself is NULL. Drivers like adis16480, adis16490, adis16545 and others do not set custom ops and rely on adis_init() assigning the defaults. Since struct adis is zero-initialized by devm_iio_device_alloc(), adis->ops is NULL when adis_init() is called, causing a NULL pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 pc : adis_init+0xc0/0x118 Call trace: adis_init+0xc0/0x118 adis16480_probe+0xe0/0x670 Fix this by checking if adis->ops is NULL before dereferencing it, falling through to assign the default ops in that case. | ||||
| CVE-2026-7210 | 1 Python | 1 Cpython | 2026-05-11 | N/A |
| `xml.parsers.expat` and `xml.etree.ElementTree` use insufficient entropy for Expat hash-flooding protection, which allows a crafted XML document to trigger hash flooding.\r\n\r\nFully mitigating this vulnerability requires both updating libexpat to 2.8.0 or later and applying this patch. | ||||
| CVE-2026-43318 | 1 Linux | 1 Linux Kernel | 2026-05-11 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix sync handling in amdgpu_dma_buf_move_notify Invalidating a dmabuf will impact other users of the shared BO. In the scenario where process A moves the BO, it needs to inform process B about the move and process B will need to update its page table. The commit fixes a synchronisation bug caused by the use of the ticket: it made amdgpu_vm_handle_moved behave as if updating the page table immediately was correct but in this case it's not. An example is the following scenario, with 2 GPUs and glxgears running on GPU0 and Xorg running on GPU1, on a system where P2P PCI isn't supported: glxgears: export linear buffer from GPU0 and import using GPU1 submit frame rendering to GPU0 submit tiled->linear blit Xorg: copy of linear buffer The sequence of jobs would be: drm_sched_job_run # GPU0, frame rendering drm_sched_job_queue # GPU0, blit drm_sched_job_done # GPU0, frame rendering drm_sched_job_run # GPU0, blit move linear buffer for GPU1 access # amdgpu_dma_buf_move_notify -> update pt # GPU0 It this point the blit job on GPU0 is still running and would likely produce a page fault. | ||||
| CVE-2026-6146 | 2026-05-11 | N/A | ||
| Amazon::Credentials versions through 1.2.0 for Perl uses rand to generate encryption keys. Amazon::Credentials stores credentials in an obfuscated form to prevent access to the secrets from a data dump of the object. Before version 1.3.0, the secrets were encrypted using a 64-bit key that was generated using the built-in rand function, which is predictable and unsuitable for cryptography. | ||||