Export limit exceeded: 370925 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.

Search

Search Results (370925 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2026-16243 1 Eclipse 1 Omr 2026-07-22 N/A
In Eclipse OMR versions up to 0.11, the arraycmp SIMD implementation for Z and P does not check if the number of bytes to compare is zero.
CVE-2026-63856 1 Linux 1 Linux Kernel 2026-07-22 7.8 High
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn: set no_user_fence for VCN v2.0 enc/dec rings VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences. (cherry picked from commit e2b5499fca55f1a32960a311bbb62e35891eaf73)
CVE-2026-15342 1 Plane 1 Plane 2026-07-22 6.5 Medium
Plane contains a multi‑tenant authorization flaw in its asset‑management API that allows authenticated users from one workspace to access, delete, or duplicate assets belonging to another workspace by providing only the victim workspace slug and asset ID. The affected endpoints return presigned file URLs and enable destructive or duplicative actions without verifying that the requester is a member of the targeted workspace. This enables cross‑tenant data exposure, data deletion, and persistent exfiltration of files into an attacker‑controlled workspace.
CVE-2026-28314 1 Solarwinds 1 Serv-u 2026-07-22 4.7 Medium
SolarWinds Serv-U is affected by an insecure direct object reference vulnerability that leads to an account takeover. User authentication is required. The impact is lower in Windows deployments.
CVE-2026-28313 1 Solarwinds 1 Serv-u 2026-07-22 4.7 Medium
SolarWinds Serv-U is affected by an insecure direct object reference (IDOR) vulnerability that can lead to SMTP hijacking leading to arbitrary account takeover. The impact is lower in Windows deployments.
CVE-2026-28312 1 Solarwinds 1 Serv-u 2026-07-22 4.7 Medium
SolarWinds Serv-U is affected by a privilege escalation vulnerability. This would elevate a group’s access to system administrator and allow code execution as root. The impact is lower in Windows deployments.
CVE-2026-28310 1 Solarwinds 1 Serv-u 2026-07-22 4.7 Medium
SolarWinds Serv-U is affected by a privilege escalation vulnerability that allows a domain administrator to escalate their user type to that of a system administrator. The impact is lower in Windows deployments.
CVE-2026-28309 1 Solarwinds 1 Serv-u 2026-07-22 4.7 Medium
SolarWinds Serv-U is affected by a broken access control vulnerability that allows a domain administrator to create system administrator accounts. The impact is lower in Windows deployments.
CVE-2026-16607 1 Fujitsu 2 Linux Openft, Oracle Solaris Openft 2026-07-22 7.8 High
A vulnerability in Fujitsu Software Linux openFT and Fujitsu Software Oracle Solaris openFT before version 12.1D00 allows for local privilege escalation to root of an already authenticated user on GNU/Linux or Oracle Solaris. The Fsas Technologies PSIRT obtained that intelligence internally and covers the CVE beyond its CNA scope under existing agreement with Fujitsu Germany.
CVE-2026-16606 1 Fujitsu 2 Linux Openft, Oracle Solaris Openft 2026-07-22 9.8 Critical
A vulnerability in Fujitsu Software Linux openFT and Fujitsu Software Oracle Solaris openFT before version 12.1D00 allows for unauthenticated remote code execution (pre-auth RCE) on GNU/Linux or Oracle Solaris. The Fsas Technologies PSIRT obtained that intelligence internally and covers the CVE beyond its CNA scope under existing agreement with Fujitsu Germany.
CVE-2026-16486 1 Sourcecodester 1 Class And Exam Timetabling System 2026-07-22 4.3 Medium
A vulnerability was found in SourceCodester Class and Exam Timetabling System 1.0. This affects an unknown part of the file /BSIS.php. Performing a manipulation of the argument day results in cross site scripting. The attack may be initiated remotely. The exploit has been made public and could be used.
CVE-2026-28308 1 Solarwinds 1 Serv-u 2026-07-22 4.7 Medium
SolarWinds Serv-U is affected by an insecure direct object reference (IDOR) vulnerability that can lead to remote code execution. Domain administrator access is required. The impact is lower in Windows deployments.
CVE-2026-44191 1 Redhat 1 Ansible Automation Platform 2026-07-22 7.8 High
A flaw was found in the Visual Studio Code Ansible Lightspeed extension. This command injection vulnerability (CWE-78) arises from improper handling of the ansible.executionEnvironment.containerOptions and ansible.executionEnvironment.volumeMounts settings, allowing an attacker to inject shell separators. This can be triggered automatically during Language Server initialization or manually when executing a playbook. Successful exploitation leads to remote code execution (RCE) on the victim's machine with the privileges of the Visual Studio Code user, potentially resulting in a complete system compromise.
CVE-2026-28307 1 Solarwinds 1 Serv-u 2026-07-22 4.7 Medium
SolarWinds Serv-U is affected by a privilege escalation vulnerability that allows a domain user group to be elevated into an administrator group. The impact is lower in Windows deployments.
CVE-2026-63888 1 Linux 1 Linux Kernel 2026-07-22 9.8 Critical
In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.
CVE-2026-63892 1 Linux 1 Linux Kernel 2026-07-22 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: thunderbolt: property: Reject dir_len < 4 to prevent size_t underflow On the non-root path, __tb_property_parse_dir() takes dir_len from entry->length (u16 widened to size_t). Two distinct OOB conditions follow when entry->length < 4: 1. The non-root path begins with kmemdup(&block[dir_offset], sizeof(*dir->uuid), ...) which always reads 4 dwords from dir_offset. tb_property_entry_valid() only enforces dir_offset + entry->length <= block_len, so a crafted entry with dir_offset close to the end of the property block and entry->length in 0..3 passes that gate but lets the UUID copy run off the block (e.g. dir_offset = 497, dir_len = 3 in a 500-dword block reads block[497..501]). 2. After the kmemdup, content_len = dir_len - 4 underflows size_t to ~SIZE_MAX, nentries becomes SIZE_MAX / 4, and the entry walk runs OOB on each iteration until an entry fails validation or the kernel oopses on an unmapped page. Reject dir_len < 4 on the non-root path *before* the UUID kmemdup, which closes both holes. Also move INIT_LIST_HEAD(&dir->properties) up to immediately after the dir allocation so the new error-return path (and the existing uuid-alloc failure path) calling tb_property_free_dir() sees a walkable list rather than the zero-initialized NULL next/prev that list_for_each_entry_safe() would oops on.
CVE-2026-63898 1 Linux 1 Linux Kernel 2026-07-22 7.0 High
In the Linux kernel, the following vulnerability has been resolved: USB: serial: mct_u232: fix memory corruption with small endpoint The driver overrides the maximum transfer size for a specific device which only accepts 16 byte packets for its 32 byte bulk-out endpoint. Make sure to never increase the maximum transfer size to prevent slab corruption should a malicious device report a smaller endpoint max packet size than expected.
CVE-2026-63943 1 Linux 1 Linux Kernel 2026-07-22 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: Input: xpad - fix out-of-bounds access for Share button xpadone_process_packet() receives len directly from urb->actual_length and uses it to index the share-button byte at data[len - 18] or data[len - 26]. Since both len and data[0] are under the device's control, a broken controller can send a GIP_CMD_INPUT packet with actual_length < 18 (e.g. 5 bytes) and reach this code path, causing accesses beyond the actual array. Fix this by calculating the offset and checking bounds against the packet length.
CVE-2026-63950 1 Linux 1 Linux Kernel 2026-07-22 7.8 High
In the Linux kernel, the following vulnerability has been resolved: mm/rmap: initialize nr_pages to 1 at loop start in try_to_unmap_one Initialize nr_pages to 1 at the start of each loop iteration, like folio_referenced_one() does. Without this, nr_pages computed by a previous folio_unmap_pte_batch() call can be reused on a later iteration that does not run folio_unmap_pte_batch() again. mmap a 64K large folio with MAP_ANONYMOUS | MAP_DROPPABLE, then call madvise(MADV_FREE), then make the last page device-exclusive via HMM_DMIRROR_EXCLUSIVE. Trigger node reclaim through sysfs. Now, in try_to_unmap_one(), we will first clear the first 15 out of 16 entries mapping the lazyfree folio. This will set nr_pages to 15. In the next pvmw walk, this nr_pages gets reused on a device-exclusive pte, thus potentially corrupting folio refcount/mapcount. At the moment, I have a userspace program which can make the kernel spit out a trace, but the blow up is in folio_referenced_one(), because there are existing bugs in the interaction between device-private and rmap (which too I am investigating). I did a one liner kernel change to avoid going into folio_referenced_one(), and the kernel blows up at folio_remove_rmap_ptes in try_to_unmap_one which is what I wanted. Note that the bug is there not since file folio batching but lazyfree folio batching, since device-exclusive only works for anonymous folios. Userspace visible effect is simply kernel crashing somewhere due to refcount/mapcount corruption.
CVE-2026-9499 1 Qt 1 Qt 2026-07-22 N/A
An out-of-bounds read (buffer over-read) vulnerability exists in QTextCodec::codecForName() in Qt. When the function is called with a QByteArray that is not NUL-terminated (for example, one created with QByteArray::fromRawData()), the codec-name matching routine reads past the end of the supplied buffer. In most cases this results in an incorrect text codec being selected; in the worst case, if the over-read reaches unmapped memory, the process crashes (denial of service). The over-read is bounded by the length of the longest codec-name candidate, and the out-of-bounds bytes are only compared internally against Qt's fixed list of codec names, so no data is disclosed to an attacker. Applications that do not pass non-NUL-terminated QByteArrays to QTextCodec::codecForName() are not exposed. The affected code resides in the Qt5Compat module from Qt 6.0.0 onward, and in Qt Core (qtbase) in Qt 4.x and Qt 5.x.