Export limit exceeded: 12739 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (12739 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-12097 | 2026-06-02 | 9.8 Critical | ||
| Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Boceksoft Informatics E-Travel allows SQL Injection. This issue affects E-Travel: before 15.12.2024. | ||||
| CVE-2026-44420 | 1 Freerdp | 1 Freerdp | 2026-06-02 | 8.8 High |
| FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.26.0, a malicious RDP client can trigger a heap-buffer-overflow write in FreeRDP's server-side clipboard (cliprdr) channel by sending a CB_CLIP_CAPS PDU with a too-small capabilitySetLength. This can crash the server process (remote DoS) and may be exploitable for code execution because it corrupts heap memory. This vulnerability is fixed in 3.26.0. | ||||
| CVE-2026-44825 | 1 Apache | 1 Solr | 2026-06-01 | 8.1 High |
| Hardcoded credentials in the Basic Authentication setup tool (bin/solr auth enable) in Apache Solr versions 9.4.0 through 9.10.1 and 10.0.0 allows a remote attacker to gain full administrative access to the cluster via publicly known default credentials installed silently alongside the user-specified account. As an immediate workaround without upgrading, delete the template users (superadmin, admin, search, index) from security.json or change their passwords. The future, not yet released, versions 9.11.0 and 10.1.0 will not be vulnerable, and it will be enough to upgrade to solve the issue. Not affected: * Clusters where bin/solr auth enable was not used to bootstrap BasicAuth * Clusters where template users have been assigned strong passwords after bootstrap | ||||
| CVE-2026-44421 | 1 Freerdp | 1 Freerdp | 2026-06-01 | 8.8 High |
| FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.26.0, a malicious RDP server can trigger a heap-buffer-overflow write in the FreeRDP client by sending crafted RDPGFX PDUs. The bug is in gdi_CacheToSurface: it validates a destination rectangle that is clamped to UINT16_MAX, but then performs the copy using the original cacheEntry->width/height. This can cause a large out-of-bounds heap write and may lead to client crashes or code execution. This bug is reachable from a malicious RDP server, but only when the client has RDPGFX enabled. This vulnerability is fixed in 3.26.0. | ||||
| CVE-2026-44422 | 1 Freerdp | 1 Freerdp | 2026-06-01 | 7.5 High |
| FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.26.0, FreeRDP's RDPEAR NDR parser accepts one non-null NDR pointer ref-id for multiple logical pointer fields without tracking the pointed object's expected NDR type or ownership. When the same ref-id is reused across two pointer fields, the parser assigns the same heap object to both output fields. The generic destructor later walks each field independently and destroys/frees both pointers. This causes a malicious-server-triggerable heap use-after-free / double-free in the FreeRDP client's RDPEAR authentication-redirection path. This vulnerability is fixed in 3.26.0. | ||||
| CVE-2026-31676 | 1 Linux | 1 Linux Kernel | 2026-06-01 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test. | ||||
| CVE-2026-23394 | 1 Linux | 1 Linux Kernel | 2026-06-01 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: af_unix: Give up GC if MSG_PEEK intervened. Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection. When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC. Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC. Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run. This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily. Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls. | ||||
| CVE-2026-23141 | 1 Linux | 1 Linux Kernel | 2026-06-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: send: check for inline extents in range_is_hole_in_parent() Before accessing the disk_bytenr field of a file extent item we need to check if we are dealing with an inline extent. This is because for inline extents their data starts at the offset of the disk_bytenr field. So accessing the disk_bytenr means we are accessing inline data or in case the inline data is less than 8 bytes we can actually cause an invalid memory access if this inline extent item is the first item in the leaf or access metadata from other items. | ||||
| CVE-2025-68823 | 1 Linux | 1 Linux Kernel | 2026-06-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ublk: fix deadlock when reading partition table When one process(such as udev) opens ublk block device (e.g., to read the partition table via bdev_open()), a deadlock[1] can occur: 1. bdev_open() grabs disk->open_mutex 2. The process issues read I/O to ublk backend to read partition table 3. In __ublk_complete_rq(), blk_update_request() or blk_mq_end_request() runs bio->bi_end_io() callbacks 4. If this triggers fput() on file descriptor of ublk block device, the work may be deferred to current task's task work (see fput() implementation) 5. This eventually calls blkdev_release() from the same context 6. blkdev_release() tries to grab disk->open_mutex again 7. Deadlock: same task waiting for a mutex it already holds The fix is to run blk_update_request() and blk_mq_end_request() with bottom halves disabled. This forces blkdev_release() to run in kernel work-queue context instead of current task work context, and allows ublk server to make forward progress, and avoids the deadlock. [axboe: rewrite comment in ublk] | ||||
| CVE-2022-49822 | 1 Linux | 1 Linux Kernel | 2026-06-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: cifs: Fix connections leak when tlink setup failed If the tlink setup failed, lost to put the connections, then the module refcnt leak since the cifsd kthread not exit. Also leak the fscache info, and for next mount with fsc, it will print the follow errors: CIFS: Cache volume key already in use (cifs,127.0.0.1:445,TEST) Let's check the result of tlink setup, and do some cleanup. | ||||
| CVE-2026-23254 | 1 Linux | 1 Linux Kernel | 2026-06-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: gro: fix outer network offset The udp GRO complete stage assumes that all the packets inserted the RX have the `encapsulation` flag zeroed. Such assumption is not true, as a few H/W NICs can set such flag when H/W offloading the checksum for an UDP encapsulated traffic, the tun driver can inject GSO packets with UDP encapsulation and the problematic layout can also be created via a veth based setup. Due to the above, in the problematic scenarios, udp4_gro_complete() uses the wrong network offset (inner instead of outer) to compute the outer UDP header pseudo checksum, leading to csum validation errors later on in packet processing. Address the issue always clearing the encapsulation flag at GRO completion time. Such flag will be set again as needed for encapsulated packets by udp_gro_complete(). | ||||
| CVE-2026-0826 | 1 Hp Inc. | 3 Poly Trio 8300, Poly Trio 8500, Poly Trio 8800 | 2026-06-01 | N/A |
| In certain scenarios when the admin has enabled Interactive Connectivity Establishment (ICE), a buffer overflow could enable remote code execution on Poly Voice products on the Linux platform. | ||||
| CVE-2024-12144 | 2026-06-01 | 9.8 Critical | ||
| Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Finder Fire Safety Finder ERP/CRM (Old System) allows SQL Injection. This issue affects Finder ERP/CRM (Old System): before 18.12.2024. | ||||
| CVE-2024-12146 | 2026-06-01 | 7.5 High | ||
| Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Finder Fire Safety Finder ERP/CRM (New System) allows SQL Injection. This issue affects Finder ERP/CRM (New System): before 18.12.2024. | ||||
| CVE-2024-12914 | 1 Akinsoft | 1 Qr Menu | 2026-06-01 | 4.3 Medium |
| Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Akınsoft QR Menü allows Cross-Site Scripting (XSS). This issue affects QR Menü: from s1.05.05 before v1.05.12. | ||||
| CVE-2024-12924 | 1 Akinsoft | 1 Qr Menu | 2026-06-01 | 6.3 Medium |
| URL Redirection to Untrusted Site ('Open Redirect') vulnerability in Akınsoft QR Menü allows Forceful Browsing, Phishing. This issue affects QR Menü: from s1.05.05 before v1.05.12. | ||||
| CVE-2024-12925 | 1 Akinsoft | 1 Qr Menu | 2026-06-01 | 7.3 High |
| Improper Validation of Certificate with Host Mismatch vulnerability in Akınsoft QR Menü allows HTTP Response Splitting. This issue affects QR Menü: from s1.05.05 before v1.05.12. | ||||
| CVE-2024-12970 | 2026-06-01 | 3.9 Low | ||
| Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in TUBITAK BILGEM Pardus OS My Computer allows OS Command Injection. This issue affects Pardus OS My Computer: before 0.7.2. | ||||
| CVE-2024-13147 | 2026-06-01 | 9.8 Critical | ||
| Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Merkur Software B2B Login Panel allows SQL Injection. This issue affects B2B Login Panel: before 15.01.2025. | ||||
| CVE-2025-11234 | 1 Redhat | 4 Enterprise Linux, Openshift, Rhel E4s and 1 more | 2026-06-01 | 7.5 High |
| A flaw was found in QEMU. If the QIOChannelWebsock object is freed while it is waiting to complete a handshake, a GSource is leaked. This can lead to the callback firing later on and triggering a use-after-free in the use of the channel. This can be abused by a malicious client with network access to the VNC WebSocket port to cause a denial of service during the WebSocket handshake prior to the VNC client authentication. | ||||