Export limit exceeded: 96503 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (96503 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-19625 | 1 Quarkus | 1 Oidc | 2026-09-02 | 8.7 High |
| A flaw was found in Quarkus OIDC. A shared token-introspection cache can be exploited by a remote attacker to bypass authentication across different tenants. This allows unauthorized access to resources or data, leading to a cross-tenant authentication bypass. | ||||
| CVE-2026-18672 | 1 Progress | 1 Telerik Ui For Asp.net Ajax | 2026-09-02 | 7.5 High |
| In Progress® Telerik® UI for AJAX prior to v2026.3.812, insufficient validation of client-supplied state in RadImageEditor may allow an attacker to influence which file is returned by the control's image cache, potentially exposing file contents outside the intended image directories. | ||||
| CVE-2026-19219 | 1 Progress | 1 Telerik Ui For Asp.net Ajax | 2026-09-02 | 8.1 High |
| In Progress® Telerik® UI for AJAX prior to v2026.3.812, insufficient integrity protection of dialog request parameters used by the RadEditor file browser may allow an attacker who has obtained certain application encryption key material to alter the folders the file browser reads from, writes to, and uploads into, potentially resulting in remote code execution. | ||||
| CVE-2026-81289 | 2 Sonaar, Wordpress | 2 Mp3 Audio Player For Music, Radio & Podcast, Wordpress | 2026-09-02 | 7.1 High |
| Unauthenticated Cross Site Scripting (XSS) in MP3 Audio Player for Music, Radio & Podcast by Sonaar <= 5.13.1 versions. | ||||
| CVE-2026-73702 | 2 Arubanetworks, Hewlett Packard Enterprise (hpe) | 2 Fabric Composer, Fabric Composer | 2026-09-02 | 8.8 High |
| A privilege escalation vulnerability exists in the API of HPE Networking Fabric Composer. Successful exploitation could allow an authenticated low privilege operator user to escalate their permissions to those of an administrative user, leading to complete system compromise. | ||||
| CVE-2026-73703 | 2 Arubanetworks, Hewlett Packard Enterprise (hpe) | 2 Fabric Composer, Fabric Composer | 2026-09-02 | 8.8 High |
| A vulnerability in the web-based management interface of HPE Networking Fabric Composer could allow an unauthenticated adjacent attacker to conduct a stored cross-site scripting (XSS) attack against a user of the interface. A successful exploit could allow an attacker to execute arbitrary script code in a victim's browser in the context of the affected interface. | ||||
| CVE-2026-73706 | 2 Arubanetworks, Hewlett Packard Enterprise (hpe) | 2 Fabric Composer, Fabric Composer | 2026-09-02 | 8.6 High |
| A vulnerability in the API of HPE Networking Fabric Composer could allow an unauthenticated remote attacker to obtain limited system information and to change the state of certain settings of a vulnerable system. Successful exploitation could allow an attacker to gain insight into internal services and workflows and to make unauthorized changes that may disrupt the normal operation of the affected service. | ||||
| CVE-2026-73707 | 2 Arubanetworks, Hewlett Packard Enterprise (hpe) | 2 Fabric Composer, Fabric Composer | 2026-09-02 | 8.5 High |
| Privilege escalation vulnerabilities exist in the API of HPE Networking Fabric Composer. Successful exploitation could allow an authenticated low privilege operator user to complete state-changing actions that should not be allowed by their current level of authorization on the platform, including changes to the configuration of systems managed by the affected product. | ||||
| CVE-2026-73708 | 2 Arubanetworks, Hewlett Packard Enterprise (hpe) | 2 Fabric Composer, Fabric Composer | 2026-09-02 | 8.3 High |
| A business logic vulnerability exists in the API of HPE Networking Fabric Composer. Successful exploitation could allow an authenticated low privilege operator user to obtain elevated privileges and modify settings beyond what is authorized by the user's existing privilege level on a vulnerable system. | ||||
| CVE-2026-73709 | 2 Arubanetworks, Hewlett Packard Enterprise (hpe) | 2 Fabric Composer, Fabric Composer | 2026-09-02 | 8.3 High |
| A vulnerability in the underlying operating system of HPE Networking Fabric Composer could allow an unauthenticated adjacent attacker to run arbitrary commands on the underlying host if certain preconditions outside of the attacker's control are met. Successful exploitation could allow an attacker to execute arbitrary commands on the underlying operating system. | ||||
| CVE-2026-73713 | 2 Arubanetworks, Hewlett Packard Enterprise (hpe) | 2 Fabric Composer, Fabric Composer | 2026-09-02 | 7.8 High |
| Local privilege-escalation vulnerabilities have been discovered in HPE Networking Fabric Composer. Successful exploitation of these vulnerabilities could allow a local attacker to achieve arbitrary code execution with root privileges on the underlying operating system of the affected system. | ||||
| CVE-2026-73720 | 2 Arubanetworks, Hewlett Packard Enterprise (hpe) | 2 Fabric Composer, Fabric Composer | 2026-09-02 | 7.2 High |
| Insecure file operations in the API of HPE Networking Fabric Composer could allow an authenticated remote attacker to achieve remote code execution. Successful exploitation could allow an attacker to execute arbitrary commands as a privileged user on the underlying operating system. | ||||
| CVE-2026-73721 | 2 Arubanetworks, Hewlett Packard Enterprise (hpe) | 2 Fabric Composer, Fabric Composer | 2026-09-02 | 7.2 High |
| Vulnerabilities in the API of HPE Networking Fabric Composer could allow an authenticated remote attacker to conduct SQL injection attacks against the HPE Networking Fabric Composer instance. An attacker could exploit these vulnerabilities to obtain and modify sensitive information in the underlying database potentially leading to complete compromise of the HPE Networking Fabric Composer host. | ||||
| CVE-2026-73722 | 2 Arubanetworks, Hewlett Packard Enterprise (hpe) | 2 Fabric Composer, Fabric Composer | 2026-09-02 | 7.2 High |
| Command injection vulnerabilities in the web-based management interface of HPE Networking Fabric Composer could allow an authenticated remote attacker to perform command injection against the affected system. Successful exploitation could allow an attacker to execute arbitrary commands as a privileged user on the underlying operating system. | ||||
| CVE-2026-64054 | 1 Linux | 1 Linux Kernel | 2026-09-02 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: net: shaper: reject duplicate leaves in GROUP request net_shaper_nl_group_doit() does not deduplicate NET_SHAPER_A_LEAVES entries. When userspace supplies the same leaf handle twice, the same old-parent pointer lands twice in old_nodes[]. The cleanup loop double frees the parent. Of course the same parent may still be in old_nodes[] twice if we are moving multiple of its leaves. Note that this patch also implicitly fixes the fact that the i >= leaves_count path forgets to set ret. | ||||
| CVE-2026-64057 | 1 Linux | 1 Linux Kernel | 2026-09-02 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: afs: Fix the locking used by afs_get_link() The afs filesystem in the kernel doesn't do locking correctly for symbolic links. There are a number of problems: (1) It doesn't do any locking around afs_read_single() to prevent races between multiple ->get_link() calls, thereby allowing the possibility of leaks. (2) It doesn't use RCU barriering when accessing the buffer pointers during RCU pathwalk. (3) It can race with another thread updating the contents of the symlink if a third party updated it on the server. Fix this by the following means: (0) Move symlink handling into its own file as this makes it more complicated. (1) Take the validate_lock around afs_read_single() to prevent races between multiple ->get_link() calls. (2) Keep a separate copy of the symlink contents with an rcu_head. This is always going to be a lot smaller than a page, so it can be kmalloc'd and save quite a bit of memory. It also needs a refcount for non-RCU pathwalk. (3) Split the symlink read and write-to-cache routines in afs from those for directories. (4) Discard the I/O buffer as soon as the write-to-cache completes as this is a full page (plus a folio_queue). (5) If there's no cache, discard the I/O buffer immediately after reading and copying if there is no cache. | ||||
| CVE-2026-64058 | 1 Linux | 1 Linux Kernel | 2026-09-02 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: netfs: Fix netfs_read_folio() to wait on writeback Fix netfs_read_folio() to wait for an ongoing writeback to complete so that it can trust the dirty flag and whatever is attached to folio->private (folio->private may get cleaned up by the collector before it clears the writeback flag). | ||||
| CVE-2026-64063 | 1 Linux | 1 Linux Kernel | 2026-09-02 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: netfs: Fix streaming write being overwritten In order to avoid reading whilst writing, netfslib will allow "streaming writes" in which dirty data is stored directly into folios without reading them first. Such folios are marked dirty but may not be marked uptodate. If a folio is entirely written by a streaming write, uptodate will be set, otherwise it will have a netfs_folio struct attached to ->private recording the dirty region. In the event that a partially written streaming write page is to be overwritten entirely by a single write(), netfs_perform_write() will try to copy over it, but doesn't discard the netfs_folio if it succeeds; further, it doesn't correctly handle a partial copy that overwrites some of the dirty data. Fix this by the following: (1) If the folio is successfully overwritten, free the netfs_folio struct before marking the page uptodate. (2) If the copy to the folio partially fails, but short of the dirty data, just ignore the copy. (3) If the copy partially fails and overwrites some of the dirty data, accept the copy, update the netfs_folio struct to record the new data. If the folio is now filled, free the netfs_folio and set uptodate, otherwise return a partial write. Found with: fsx -q -N 1000000 -p 10000 -o 128000 -l 600000 \ /xfstest.test/junk --replay-ops=junk.fsxops using the following as junk.fsxops: truncate 0x0 0 0x927c0 write 0x63fb8 0x53c8 0 copy_range 0xb704 0x19b9 0x24429 0x79380 write 0x2402b 0x144a2 0x90660 * write 0x204d5 0x140a0 0x927c0 * copy_range 0x1f72c 0x137d0 0x7a906 0x927c0 * read 0x00000 0x20000 0x9157c read 0x20000 0x20000 0x9157c read 0x40000 0x20000 0x9157c read 0x60000 0x20000 0x9157c read 0x7e1a0 0xcfb9 0x9157c on cifs with the default cache option. It shows folio 0x24 misbehaving if the FMODE_READ check is commented out in netfs_perform_write(): if (//(file->f_mode & FMODE_READ) || netfs_is_cache_enabled(ctx)) { and no fscache. This was initially found with the generic/522 xfstest. | ||||
| CVE-2026-64044 | 1 Linux | 1 Linux Kernel | 2026-09-02 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ovpn: respect peer refcount in CMD_NEW_PEER error path ovpn_nl_peer_new_doit()'s error path calls ovpn_peer_release() directly rather than ovpn_peer_put(), bypassing the kref. The accompanying comment ("peer was not yet hashed, thus it is not used in any context") holds for UDP but not for TCP. For UDP, the ovpn_socket union uses the .ovpn arm and never points back at a peer; UDP encap_recv looks up peers via the not-yet-populated hashtables, so the new peer is unreachable until ovpn_peer_add() publishes it. For TCP, ovpn_socket_new() sets ovpn_sock->peer and ovpn_tcp_socket_attach() publishes ovpn_sock via rcu_assign_sk_user_data(). From that moment until ovpn_socket_release() detaches in the error path, the TCP fd is fully wired: userspace recvmsg / sendmsg / close / poll on the fd, as well as the strparser-driven ovpn_tcp_rcv() path, can reach the peer through sk_user_data -> ovpn_sock->peer and bump its refcount via ovpn_peer_hold(). ovpn_tcp_socket_wait_finish() (called inside ovpn_socket_release()) drains strparser and the tx work, but does not synchronize with userspace syscall callers that already hold a peer reference. If ovpn_nl_peer_modify() or ovpn_peer_add() returns an error while such a caller is in flight - notably an ovpn_tcp_recvmsg() blocked in __skb_recv_datagram() on peer->tcp.user_queue - the direct ovpn_peer_release() destroys the peer while the caller still holds the reference, and the eventual ovpn_peer_put() from that caller operates on freed memory. Replace the direct destructor call with ovpn_peer_put() so the kref correctly defers destruction until the last reference is dropped. In the common case where no concurrent user is present, behaviour is unchanged: the kref hits zero immediately and ovpn_peer_release_kref() runs the same destructor. With this conversion ovpn_peer_release() has no callers outside peer.c - ovpn_peer_release_kref() in the same translation unit is the only remaining user - so make it static and drop its declaration from peer.h. | ||||
| CVE-2026-64045 | 1 Linux | 1 Linux Kernel | 2026-09-02 | 8.4 High |
| In the Linux kernel, the following vulnerability has been resolved: ovpn: tcp - use cached peer pointer in ovpn_tcp_close() ovpn_tcp_close() loads the ovpn_socket via rcu_dereference_sk_user_data() under rcu_read_lock(), takes a reference on sock->peer, caches the peer pointer in a local, and drops the read lock. It then passes sock->peer (rather than the cached local) to ovpn_peer_del(), re-dereferencing the ovpn_socket after the RCU read section has ended. Unlike ovpn_tcp_sendmsg(), which uses the same "load under RCU, use after unlock" pattern but is protected by lock_sock() held across the function, ovpn_tcp_close() runs without the socket lock: inet_release() invokes sk_prot->close() without taking lock_sock first. ovpn_socket_release() can therefore complete its kref_put -> detach -> synchronize_rcu -> kfree(sock) sequence concurrently, in the window after ovpn_tcp_close() drops rcu_read_lock() but before it dereferences sock->peer. The synchronize_rcu() in ovpn_socket_release() protects readers that use the dereferenced pointer inside the RCU read section, not those that escape the pointer to a local and use it afterwards. A reproducer follows the pattern of commit 94560267d6c4 ("ovpn: tcp - don't deref NULL sk_socket member after tcp_close()"): trigger a peer removal (keepalive expiration or netlink OVPN_CMD_DEL_PEER) at the same moment userspace closes the TCP fd. That commit fixed the detach-side of the same race window; this one fixes the close-side at a different victim. Tighten the entry block to read sock->peer exactly once into the cached peer local, and route all subsequent uses (the hold check, the ovpn_peer_del() call, and the prot->close() invocation) through that local. sock->peer is only ever written once in ovpn_socket_new() under lock_sock(), before rcu_assign_sk_user_data() publishes the ovpn_socket, and is never reassigned afterwards - but the previous multi-read pattern made that invariant implicit rather than explicit. The same multi-read shape exists in ovpn_tcp_recvmsg(), ovpn_tcp_sendmsg(), ovpn_tcp_data_ready() and ovpn_tcp_write_space(); those will be cleaned up via a dedicated helper in a follow-up net-next series. | ||||